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 126.96.36.199 cf-ssl00000-protected.example.com. 299 IN A 188.8.131.52 cf-ssl00000-protected.example.com. 299 IN A 184.108.40.206 cf-ssl00000-protected.example.com. 299 IN A 220.127.116.11 cf-ssl00000-protected.example.com. 299 IN A 18.104.22.168
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 22.214.171.124 example.com. 299 IN A 126.96.36.199 example.com. 299 IN A 188.8.131.52 example.com. 299 IN A 184.108.40.206 example.com. 299 IN A 220.127.116.11
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:
- http://tools.ietf.org/html/rfc1034 November, 1987
- http://tools.ietf.org/html/rfc1035 November, 1987
- http://tools.ietf.org/html/rfc1912 February, 1996
More about CloudFlare's Free DNS services