Utilizing a CNAME in places like the apex of a zone has quickly become one one of the most common design questions I’m asked as an engineer. It’s amazing that a technology once known only to a circle of DNS geeks has, in a short few years, become a demand from business executives. How did we get here?!
In order to understand the problem and solutions of putting a CNAME at the apex, we will cover what the apex of a zone is, why it is special, and then what happens when you use a CNAME. We will then explore what the most popular options in industry are today, at Dyn and elsewhere, to understand the current environment.
What’s so special about the apex (root)?
When the concept of domains began starting in the late 80s, domains contained lots of different services that were all vying for dominance. You might have a domain of foo.com, but knew to use mail.foo.com for mail, ftp.foo.com for transferring files, vpn.foo.com for VPN connection, etc. At that time, all simple A records to IPv4 addresses to services on your own network. The apex (foo.com) itself didn’t really represent anything that special, just that foo was an entity in the .com namespace. So as a person, you really didn’t have the need to go to the apex in the first place.
Mechanically speaking however, there was something very special about this particular domain name. This is where some important records were designed to sit. Nameserver (NS) records provide the resolver with the nameservers that should be used, and the Start of Authority (SOA) record provides configuration information for the zone as a whole. By design these can only live at the apex for them to function.
As the internet gained popularity in the public sphere, the world wide web began to pick up speed. This was a service which was more accessible than many other services used in computer science, and individuals that didn’t really understand computers could turn one on, use a browser, and access an internet domain. They began to associate “foo.com” with the visual representation on their webpage. This holds today, If I say Dyn.com you think of the pretty webpage our marketers put together with case studies and solutions on our products right? Never mind the fact that there are a dozen records on that same host doing all sorts of other things:
;; QUESTION SECTION: ;dyn.com. IN ANY ;; ANSWER SECTION: dyn.com. 2187 IN TXT "google-site-verification=bVRc6gkGGrDswxAG2572YkZETdRoBASiYBBOw7yCovc" dyn.com. 2187 IN TXT "google-site-verification: VRIuHYFo0s9aWRVZxlAPyReiMYiKsMfWduASFCCyDlI" dyn.com. 2187 IN TXT "v=spf1 ip4:188.8.131.52/21 ip4:184.108.40.206/24 ip4:220.127.116.11/32 ip4:18.104.22.168/32 ip4:22.214.171.124 include:mktomail.com ip4:126.96.36.199/22 include:_spf.google.com " "ip4:188.8.131.52/24 ip4:184.108.40.206/20 ip4:220.127.116.11 ip4:18.104.22.168 ip4:22.214.171.124 ip4:126.96.36.199 ip4:188.8.131.52 ip4:184.108.40.206 ip4:220.127.116.11 ip4:18.104.22.168 " "ip4:22.214.171.124 ip4:126.96.36.199 ip4:188.8.131.52 ip4:184.108.40.206 ip4:220.127.116.11 ip4:18.104.22.168 include:spf1.veinteractive.biz include:spf.dynect.net include:stspg-customer.com include:_spf.salesforce.com ~all" dyn.com. 2187 IN TXT "google-site-verification=K_ybzxaPfdlKzbSeYfXYPxZbe-lkCqOe5v4mYo_D15o" dyn.com. 75 IN A 22.214.171.124 dyn.com. 282 IN AAAA 2600:2001:0:3::106 dyn.com. 146052 IN MX 20 alt2.aspmx.l.google.com. dyn.com. 146052 IN MX 10 aspmx.l.google.com. dyn.com. 146052 IN MX 20 alt1.aspmx.l.google.com. dyn.com. 62356 IN NS ns1.p01.dynect.net. dyn.com. 62356 IN NS ns3.p01.dynect.net. dyn.com. 62356 IN NS ns2.p01.dynect.net. dyn.com. 62356 IN NS ns4.p01.dynect.net.
So in short, the apex started to get put into browsers and used by people because it was associated with a service and easier than typing out the www.
So What’s the Big Deal with CNAMEs?
At the same time domains were getting defined and sorted, records were being defined. Amongst them was the lowly CNAME, defined in RFC 1035 as “the canonical name for an alias” which means you would use it to refer to something else as being the source of truth. This makes it convenient if two hosts both point to the same IP resource. You could put a CNAME on one, and now you only need to manage the other, which makes things convenient.
Strictly speaking you can’t (and shouldn’t) add a CNAME itself at the apex of a domain. If you think back to my dyn.com example, you would saying that for any of those records, (MX? NS? Gasp!) you should so search out the target of the CNAME for the response. That is just waiting for security headaches such as cache poisoning.
Ok… you can’t put a CNAME on the apex. So why are we all trying to?
Enter: CNAME at the Apex
Somewhere along the line while we were busy starting to associate domains with their web presence, a commercial industry started to form to enable groups without the hardware to build their own website. When this started, you would be allocated an IP where your service now lived, and you’d throw this in DNS as a simple A record which could live happily everywhere. The problem was that if a provider wanted to change that resource at all, they would have to reach out to the customer using that resource and coordinate a cutover. This has the unfortunate effect of locking the vendor into resources because it is such a management nightmare to change anything.
Then somewhere along the line somebody got a great idea. What if the resource was managed in DNS by the vendor? You could operate a management zone like vendor.com and have specific resources for the customer off them like www.client1.com.vendor.com. Now the vendor can change the resource on the host whenever they want, and all the client would need to do is CNAME from the host they’re using (www.client1.com) to the host that contains the resource (www.client1.com.vendor.com). Volia! Modern vendor domain management is born.
There was only one snag… what about that apex? You still can’t put one of those CNAMEs there. As soon as the problem arose, vendors met to answer the problem.
When you find yourself in a CNAME at the Apex scenario, you really have two options: go around the problem, or muscle through it. Both have pros and cons, which we will address below.
The first way brands began tackling this situation was to bring the CNAME out of conflict with the apex in the first place. If you put the CNAME on the www host, which is fair game, you just need to get anyone who typed the domain’s apex onto that www. The solution becomes to use a redirect, using a number of methods perfected in the website management business.
Here is an example:
Apex of facebook.com resolves to proxy:
$ dig facebook.com +short 126.96.36.199
Proxy serves a 301 to WWW:
$ curl -I -k https://188.8.131.52/ HTTP/1.1 301 Moved Permanently Location: http://www.facebook.com/ Content-Type: text/html X-FB-Debug: 3LKsYXkTTeQRdojOZtBVFGmZ712UGPyT4rWPrHfPRvjvYxjOZWvVlmNHBRuQ6mxganNWa/2MMXnl0JdccMZJZg== Date: Mon, 19 Dec 2016 11:05:10 GMT Connection: keep-alive Content-Length: 0
WWW uses CNAME to internal Cloud service
$ dig www.facebook.com +short star-mini.c10r.facebook.com. 184.108.40.206
This makes a ton of sense as it gets users off the apex and using the CNAME that the network designers want them to. There also is no alteration of the scope of the CNAME (as we shall see later), so if that CNAME could route to thousands of resources, you still have the full breadth of your network. On the downside, you are stuck with the un-sexy www node rather than the minimalist apex. Also, you forced some users to experience a redirect, which eats into your total page load time. Still, over time your users will adapt to the www node and will hit the redirect less, if at all. Go look at your bookmark for Facebook, I’ll bet you it was for the www host.
The other method on the market today is to get rid of the CNAME itself by flattening it to an A record. This is performed as a service by your DNS provider, such as Cloudflare, NS1, Dyn, or integrated into the cloud solution itself like AWS. In this system, the edge of the DNS network will resolve the target host (or will know it internally in the case of AWS) and hands out the resulting IP at the designated location of the Alias record or service. Great! I can use the apex and use a cloud provider! For most applications that will work just fine.
Times when this is not the case however, are when you’re dealing with something with many hundreds of possible IP addresses like a CDN. Rather than take advantage of a full network, you are relying on the vantage points your DNS provider is observing at (18 global locations at major internet peering exchange locations in Dyn’s case) reducing your overall footprint from your hosting/CDN provider to that of the vantage of your DNS vendor.
Additionally, if you’re thinking about using multiple DNS providers, this could get complicated. There is, at current, no RFC defined standards compliant way to perform this function and define the metadata of which host the alias should point to. All the DNS providers seem to be writing their own way of performing it as optimized for their customers’ goals. This works fine in a primary configuration, because the vendor’s code knows how to interpret the specially crafted metadata, but pass that zone to a secondary and they’ll have no idea. This is true across the industry, if you’re thinking about using multiple DNS providers it would be wise to think about the redirect method.
CNAME flattening isn’t all just doom and gloom when it comes to performance however. There are times when you’re dealing with multiple lookups in a CNAME chain which take so long that they can trigger a user timeout before even connecting to the resource. We see this most in the more disconnected areas of the Internet, such as Africa which must usually come up to Europe for resolution, or China which must come through the Great Firewall. In these cases, it may be beneficial to use a flattened CNAME in an alias. Even if it is a reduced network presence, if you’re timing out before the http connection it’s certainly better to have sub-par than none at all! Here at Dyn, you can also include Alias records in a Traffic Director, so you may pick and choose their application depending on your own business decisions.
There is a lot of confusion in the market when it comes to using CNAMEs at the apex. While it might be tempting to want to put a real CNAME wherever you’d like, there are practical performance and security reasons to refrain, and enterprise grade solutions such as Dyn have built tools to enable the modern network architect to have multiple tools at their disposal corresponding to their own business needs.