What is with the reccommendation to use `www` domain on GitHub Pages?

Question

If you look at the documentation for GitHub pages, it has a pretty strong reccommendation to use a www domain for your custom domain site hosted on GitHub Pages.

From here: https://help.github.com/en/articles/about-supported-custom-domains#www-subdomains

A www subdomain is the most commonly used type of subdomain, in which the www stands for World Wide Web. For example, www.example.com is a www subdomain because it contains the subdomain part www.

We strongly recommend that you use a www subdomain for these reasons:

• It gives your GitHub Pages site the benefit of our Content Delivery Network.
• It is more stable because it is not affected by changes to the IP addresses of GitHub's servers.
• Pages will load significantly faster because Denial of Service attack protection can be implemented more efficiently.

Does this mean if I do not use a www domain I will not get the benefits of a CDN or DDOS Attack Protection?

What is the technical reason why there is a difference between a www and non-www domain here?

Answer 1

The difference lies in how you point the site to GitHub's servers in DNS.

The simplest use of DNS is to point a domain name, at whatever level, at an IP address, using an A record. The same address will be used by all users, and can be changed only by the owner of the "zone" where the A record was added - in this case you, configuring the zone of your custom domain.

A smarter way is to alias a particular domain name to a different zone - in this case one managed by GitHub - using a CNAME record. The owners of that zone can then change the IP address as needed, and can even give different answers to different users based on their location (which is where the CDN reference comes from).

The key restriction however is that you can't use a CNANE as the root of a zone. See this Server Fault question for the technical details.

If you own "example.com", you can point an A record for the root of that domain at one GitHub IP address (or a few, selected essentially at random by visitors), but will give GitHub more freedom to route the traffic if you point a CNAME for a sub-domain, like "www.example.com".

Some DNS providers offer tools to work around this limitation by adding a fake record for the root of the domain that looks like a CNAME, but may be labelled differently (e.g. ANAME, ALIAS). When asked for the root A record, the DNS provider looks up the actual A records for that domain and returns those. This is useful for records which change over time, but because the address is being looked up by your DNS provider not the actual visitor, it may still prevent GitHub serving the best address for that visitor.

Answer 2

DNS does not provide a reliable mechanism for forwarding on apex/root records (e.g. example.com) but does for subdomains (CNAME). In practice this means that while you can point an A record to a single IP address corresponding to a node on Github's infrastructure, they aren't able to route DNS lookups for your apex record to other IP addresses that are closer to the request (CDN) or use DNS to mitigate the effects of a (D)DoS attack.

Some DNS providers do offer synthetic records (ALIAS, ANAME) that mimic the behavior of a CNAME record with apex domains (e.g. dnsimple), but they're not widely available, introduce additional complexity and latency, and don't provide the same level of geographic routing opportunities to Github et al.