CNAME Flattening: RFC-compliant support for CNAME at the root

As of March 31 2014, CloudFlare provides automatic CNAME Flattening at the zone apex (or root) for our customers. All customers with CNAME records at the root will have DNS requests safely processed without being limited by the DNS specifications (RFCs).

We shared more background and customer stories in this blog post.

Note: CNAME Flattening does not apply for domains signed up through a hosting partner or using CNAME setup. In those cases, the root domain and full zone are not using CloudFlare DNS, and cannot benefit from CNAME Flattening.

How CNAME Flattening works

CloudFlare uses CNAME Flattening to present a CNAME as an A record. The CloudFlare server generating the response follows the CNAME chain so that the response to the request from the client (for example, the browser) contains only non-CNAME data -- usually, an IP address. This effectively creates an A or an AAAA record. Without flattening, CloudFlare would serve the CNAME record directly to the recursor (the DNS resolver that translates the domain name to an IP address).

CNAMEs can cause confusion when you wish to have a CNAME for a domain (for example, a CNAME from example.com to example.herokuapp.com) but also wish to have another type of DNS record at the root, for example MX records for mail delivery. The RFC requires CNAMEs to be exclusive to a DNS zone when present and the example presented may cause problems when receiving email, since the RFC also requires an MX record to map to an A record and not a CNAME. CNAME Flattening ensures email delivery because the CNAME is translated to an A record.

Some other DNS providers call similar functionality (without RFC compliance) ALIAS or ANAME records.

Before CNAME Flattening

When you select the "orange cloud" option in CloudFlare DNS Settings, CloudFlare protects the identity of the CNAME and returns the IP addresses of the CloudFlare proxy servers.

$ dig example.com

;; QUESTION SECTION:
;example.com.   IN   A

ANSWER SECTION:
example.com.   0   IN   CNAME   cf-ssl00000-protected.example.com.
cf-ssl00000-protected.example.com.   299   IN   A   162.159.253.115
cf-ssl00000-protected.example.com.   299   IN   A   162.159.252.116
cf-ssl00000-protected.example.com.   299   IN   A   162.159.254.115
cf-ssl00000-protected.example.com.   299   IN   A   162.159.253.116
cf-ssl00000-protected.example.com.   299   IN   A   162.159.255.115

After CNAME Flattening

In this example, the CNAME, example.com is associated with each A record of the proxy servers. Note that they are the same A records as above.

$ dig example.com

QUESTION SECTION:
;example.com.   IN   A

;; ANSWER SECTION:
example.com.   299   IN   A   162.159.255.115
example.com.   299   IN   A   162.159.254.115
example.com.   299   IN   A   162.159.252.116
example.com.   299   IN   A   162.159.253.116
example.com.   299   IN   A   162.159.253.115

CNAME Flattening also works when only DNS is active, if the record is "grey cloud" (CloudFlare proxy disabled for the record in CloudFlare DNS Settings).

Flattening non-root records

Customers wanting to use CNAME Flattening for their non-root records should contact CloudFlare support and request CNAME Flattening for the entire zone.

RFC (Request For Comments)

The specifications which govern using a CNAME at the root within DNS are some of the earliest decisions about the internet, including before the web was available:

Related:

More about CloudFlare's Free DNS services