CNAME Flattening and Similar Techniques

By Jack Sauriol 

What is a CNAME?

CNAME records map a label to a label. Basically, they act as an alias for one name to another, allowing you to map the convenient and readable ​​to the less convenient but more unique ​​They’re also commonly used with cloud services, CDNs, and DDoS protection. A CNAME can be pointed at a load balancer or the CDN service, allowing a hostname to be resolved from a pool of addresses.

A number of potential problems exist with CNAMEs. When combined with records that also point to names (CNAME, MX, NS, PTR), there’s potential for complex redirects and loops that can expose bugs in resolvers, leading to failures in resolution. Additionally, CNAMEs can stomp other records. RFC 1034 specifies that if resolution for a record fails, the record set should be checked for CNAMEs that correspond to the same type. In that same section, RFC 1034 also specifies that if a CNAME is present for a label, no other resource records should be present.

What is CNAME Flattening?

CNAME flattening is a clever way around the above limitation. It’s a method of allowing CNAMEs for A or AAAA records as the apex domain. Traditionally, if you wanted to serve content from the apex domain, you’d have to create an A record pointing to the IP address of the web server and manually update it on change. Replacing this A record with a CNAME would be more convenient but is, as previously stated, disallowed by RFC 1034 and will break most DNS servers. CNAME flattening is a technique of allowing CNAMES at the apex domain by implementing custom record types, dynamically resolving aliases, and other provider-specific methods.

Why is CNAME Flattening Necessary?

RFC 1912 specifies “A CNAME record is not allowed to coexist with other data”. DNS servers that follow the standard will encounter a CNAME and fail to process any other records for that label. This will result in your domain not having any NS or MX records.

Problems with CNAME Flattening

Depending on implementation, CNAME flattening can cause a number of problems. If the CNAME resolves to a DNS-based load balancer, a regional response could be cached and returned to a resolver based in a different region, resulting in an incorrect response and slower load times for the end user. It also decreases visibility for end users. If a CNAME is flattened

into an A record, clients will only see the A record, making it difficult for them to understand where their traffic is being routed and why. Additionally, if the target record has an unusually high TTL, the target records may be cached according to that TTL, resulting in outdated data being served for longer than necessary. Despite the issues, CNAME flattening is highly desired by many customers of cloud-based DNS providers because it allows customers to serve content from whatever domain they want while still having functional email and the ability to make use of load balancers and cloud-based hosting services.

How is CNAME Flattening Implemented?

Many different DNS providers implement CNAME flattening (or a similar technique which accomplishes the same thing) in a variety of slightly different ways.

Cloudflare (CNAME Flattening)

Cloudflare’s DNS servers resolve the CNAME and cache the response. The TTLs are respected, meaning the record has to be resolved at regular intervals. The would-be-CNAME record at the root is replaced with the resolved IP address, making it appear as if the CNAME record was just an A (or AAAA) record.

This method functions basically the same as a regular DNS resolver. The information contained in the cache might not be the most up-to-date, but as long as the target TTLs are respected, there won’t be a problem.

DNSimple (ALIAS)

DNSimple runs a custom, erlang-based DNS server which supports ALIAS records. ALIAS records are a custom record type which supports resolution of the record every time the CNAME is requested. If it is successfully resolved, the answer is returned and entered into a cache. If resolution fails, the cache is checked. If the record is present, it is returned from the cache. If not, resolution fails and nothing is returned.

The fact that resolution runs on every request means that there’s up to 100% overhead for every ALIAS record. However, it also means that the response returned is always up to date.


easyDNS, like DNSimple, provides a custom record type that functions like a CNAME but is valid at the domain root. This ANAME record is implemented by flattening it into an A or AAAA record. This record type is implemented by constantly monitoring the target for change and reloading the zone when one is detected.

Depending on how it’s implemented, constantly monitoring a target record for change has the potential to add a lot of overhead to the backend of the DNS server. However, flattening the ANAME to an A record behind the scenes effectively removes any overhead when resolving.

DNS Made Easy (ANAME)

DNS Made Easy also implements a custom ANAME record. Like DNSimple, the record is resolved on request and entered into a cache. If resolution fails, the response is pulled from the cache.

Amazon (ALIAS)

AWS’ Route 53 provides Route 53 specific ALIAS records. These records let you route traffic to AWS resources. Like the other implementations, ALIAS records can be implemented at a zone root. When an ALIAS record is queried, Route 53 responds with the appropriate value. For example, if the record is pointed at an AWS load balancer, Route 53 returns one or more of the addresses of the load balancer. If it’s pointed at another Route 53 record in the same zone, Route 53 responds as if the query was for the target record. AWS also handles integration of all of these resources – if the IP address of the target resource changes, Route 53 automatically recognizes this without any need to query for the new value.

ALIAS records are only of any use if you’re all-in on AWS, but the fact that they can resolve AWS resources instead of simply records is incredibly convenient.


Prince, Matthew. “Cloudflare.” Cloudflare (blog). Cloudflare, April 2, 2014. t/.

“How Does CNAME Flattening Work?” DNS Made Easy, DNS Made Easy, 25 Sept. 2018,

[RFC1912] Barr, D., “Common DNS Operational and Configuration Errors”, RFC 1912, February 1996.

[RFC1034] Mockapetris, P., “Domain names – concepts and facilities”, STD 13, RFC 1034, November 1987.

[RFC2181] Elz, R. and R. Bush, “Clarifications to the DNS Specification”, RFC 2181, July 1997.

“Differences Among A, CNAME, ALIAS, and URL Records.” DNSimple Help.

“Understand and Configure CNAME Flattening.” Cloudflare Help Center. Flattening.

“What’s an ALIAS Record?” DNSimple Help.

Carletti, Simone. “Technical Reasons Behind the ALIAS Record.” DNSimple Blog. n.d.

“ANAME – CNAME Your Domain Root.” EasyDNS: Simple DNS, Domain Registration, and Website Hosting – Power & Freedom.

Cutler, Brad. “ANAME Records Now Support IPv6.” EasyDNS: Simple DNS, Domain Registration, and Website Hosting – Power & Freedom (blog). January 3, 2016.

“ANAME Records.” DNS Made Easy.

“CDN’s Love ANAME Records.” DNS Made Easy Blog.

“Choosing Between Alias and Non-alias Records.” AWS – Amazon Route 53. ias-non-alias.html.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s