What is CNAME flattening and how it helps redirecting the apex domain

A and CNAME records

The primary purpose of DNS is to translate a domain name to an IP address. It works by sending back an A record with the IP so that the client knows where to connect. This works great when you have a server with a fixed IP that hosts your website. The browser contacts the name server, gets the IP, then downloads the page from your server.

Things get more complicated when the server is hosted by someone else. There might still be an IP address, but hardcoding that makes it hard for the hosting provider to change it.

This is where CNAME records help. They are a pointer to another domain and tells the browser to look up that and use the resulting A record. The hosting provider can give you a domain instead of an IP address and with this setup it is free to change the A records without prior notice.

The problem is that while you can use CNAME records for subdomains (www.example.com), they are forbidden on the apex (example.com) by the DNS standard. While the www subdomain seems like something that is the legacy of the past, there are many cases where you need to use it.

Services with A record redirection

Certain hosting providers offer A records as well as CNAMEs. For example, GitHub Pages provides 4 IP addresses in case you want to use the apex domain. But also notice that they provide that as the third option.

Similarly, Netlify also documents an IP address that you can use. This time it's only 1 IP.

Note that by providing these IP addresses, these services give up some flexibility. Now that many sites depend on them they can't change these records easily. It's also harder to add more addresses, for example for load balancing.

Services with only CNAME redirection

On the other hand, other services don't provide an IP address to use in an A record. For example, to host an S3 bucket website on a custom domain you can only use a CNAME record as AWS does not provide a stable pool of IPs.

Similarly, CloudFront provides only a domain name of the distibution and no dedicated IP address to use for DNS. You can easily set up a subdomain with a CNAME record pointing to the distribution's domain, but this can not be done for the apex.

Of course, every DNS resolution results in a set of A records:

;; ANSWER SECTION:
dpfigmh81ohnl.cloudfront.net. 55 IN     A       143.204.201.51
dpfigmh81ohnl.cloudfront.net. 55 IN     A       143.204.201.15
dpfigmh81ohnl.cloudfront.net. 55 IN     A       143.204.201.21
dpfigmh81ohnl.cloudfront.net. 55 IN     A       143.204.201.111

But don't be tempted to hardcode them for the apex domain. By not having them documented, they can change without prior notice and that breaks your site. And they do change:

;; ANSWER SECTION:
dpfigmh81ohnl.cloudfront.net. 60 IN     A       13.224.194.34
dpfigmh81ohnl.cloudfront.net. 60 IN     A       13.224.194.94
dpfigmh81ohnl.cloudfront.net. 60 IN     A       13.224.194.54
dpfigmh81ohnl.cloudfront.net. 60 IN     A       13.224.194.31

CNAME at root

Fortunately, some DNS services started coming up with a solution to this problem. CNAME flattening from Cloudflare was probably the first to support redirecting the apex. After that, other providers started implementing solutions under slightly different names, such as ALIAS and ANAME.

For example, a Cloudflare domain can be configured with a CNAME on the apex:

Under the hood, Cloudflare dynamically resolves the A records for the target domain. When someone queries the domain, only A records are returned, which is in-line with the DNS spec:

;; ANSWER SECTION:
myawsexperiments.com.   57      IN      A       52.222.174.138
myawsexperiments.com.   57      IN      A       52.222.174.224
myawsexperiments.com.   57      IN      A       52.222.174.173
myawsexperiments.com.   57      IN      A       52.222.174.159

Cloudflare also makes sure to respect the TTLs of the records it used to get to the IP addresses. This way they are automatically refreshed and kept synchronized with the target.

Unfortunately, there is no standards-based support for CNAMEs@root. All the above are workarounds implemented by the DNS providers but this functionality is far from being the norm. And as far as I know, there is no movement on making a standardized solution. Because of this, you need to know what your DNS provider supports.

Because of the lack of standardization when a provider supports ALIAS/ANAME/CNAME flattening you need to check if that is the same as what you think it is. For example, Route53 supports ALIAS records but that only works for AWS services and it is not a general solution.