This is a repost of the article I wrote for the 2016 Performance Calendar on PerfPlanet. The original article is here: https://calendar.perfplanet.com/2016/root-domain-cdn-performance/.
Nowadays it is not uncommon to publish your site on the root domain (aka 'naked domain' or 'domain apex'). Instead of using www.awesomesite.com you go for awesomesite.com. Looks good, right? Yeah.
Running the whole site through a CDN is also the modern thing to do and can help give your users an excellent experience. The CDN will give you an endpoint to point to in DNS and now you run into a roadblock: you can't use a CNAME on the root domain (per RFC2181). Now what?
Luckily for you, there are DNS providers that have a solution, usually called ANAME or ALIAS, allowing you to point to the CDN endpoint on the root domain.
NS1, DNS Made Easy, Constellix, DNSimple and Cloudflare have this ANAME/ALIAS solution. AWS Route 53 has it too, but you can only use it with their own CDN (CloudFront).
So you pick one of these DNS providers, set things up and be done with it, right? Not so fast.
The problem
The ANAME/ALIAS is resolved by your DNS provider's nameserver instead of by a recursive resolver (ISP, Google Public DNS, OpenDNS or other) and this may lead to end users being routed to a far-away CDN node and consequently getting a poor experience.
Let's take a look at how ANAME/ALIAS resolution works:
Imagine Thailand is an important market for your company, awesomesite.com. Logically, you work with a CDN that has a POP in Thailand. Your authoritative DNS provider has POPs in Hong Kong and Singapore, but not in Thailand.
The DNS server of an ISP in Thailand sends a query for awesomesite.com to your DNS provider and that query is routed to their Hong Kong POP. The authority's nameserver in Hong Kong now resolves the ANAME/ALIAS, by sending a query to the CDN's DNS server.
You can probably guess what happens: the CDN's DNS server sees a query coming in from Hong Kong and it hands out the IPs for the CDN POP in Hong Kong. As a result, people in Thailand visiting awesomesite.com get the content from the CDN in Hong Kong (100 ms RTT) instead of from Thailand (30 ms RTT).
So far, this is just theory. Let's see this in action in the real world!
SwiftServe CDN has POPs in Thailand (TH) and Hong Kong (HK). NS1 has POPs in Asia, including in HK and SG, but not in TH. For this test, I set up our domain startrender.com in NS1, pointing to the SwiftServe endpoint (edge.conversant.swiftserve.com) with an ALIAS record on the root domain and with a normal CNAME on www.startrender.com.
What happens for users in HK and TH on Google Public DNS and OpenDNS? Both open resolvers support EDNS-Client-Subnet which means they send part of the client IP in the query to the CDN's DNS server, so that server can make a more informed decision and hand out the IP addresses for the best POP.
We use the free tool TurboBytes Pulse (DNS, HTTP and Traceroute diagnostics from 80+ machines around the globe - now offline) to first see what the IPs are of the SwiftServe POPs. We need this later as a reference.
Next, we run tests on the Pulse agents located in HK and TH to find out what happens in both cases: www.startrender.com (CNAME) and startrender.com (ALIAS). Guess what?
| Domain | User location | CDN POP location |
|---|---|---|
| www.startrender.com | HK | HK |
| www.startrender.com | TH | TH |
| startrender.com | HK | SG |
| startrender.com | TH | GB |
As the table shows, using Google Public DNS and OpenDNS from HK and TH, www.startrender.com resolves to the desired CDN POPs. However, for startrender.com, users on Google Public DNS and OpenDNS in HK will end up hitting the SwiftServe POP in SG (not so bad) and users on those resolvers in TH are routed to the SwiftServe POP in London (ugh!)
The impact of this problem really depends on where your users are and where the POPs of your DNS and CDN providers are. If you only care about US, you're probably in the clear. Asia, LATAM, Middle East, Russia? Assume this problem exists for you.
Any solutions to this problem? Yes!
Solution A: DNS providers do a better job
The authoritative DNS provider for your domain should be smarter when resolving the ANAME/ALIAS from their nameservers, by 'doing the EDNS-Client-Subnet thing': send part of the IP address of the originating query source in its query to the CDN's DNS server.
If your authoritative DNS provider received the query from OpenDNS or Google Public DNS, it should pass along the client IP address subnet. If the query came from an ISP resolver, the authority server should send the /24 subnet of that resolver's IP in the query to the CDN's DNS server.
I'm quite sure NS1, DNS Made Easy/Constellix and DNS Simple don't send EDNS-Client-Subnet queries when resolving ANAME/ALIAS. I don't know why these DNS providers don't do this. Maybe it's because this would require caching much more responses, as responses can now be different for different recursive/client IP subnets.
Solution B: get integrated authoritative DNS and CDN
AWS, Akamai and CDNetworks are companies that operate a global CDN and provide authoritative DNS services. They can be smart and have their authoritative DNS and CDN work together, meaning the auth DNS always knows what the best CDN IPs are for whatever query comes in. Bye bye root domain problem.
AWS Route 53/CloudFront is doing this smart thing today. Akamai and CDNetworks: I'm not sure but likely.
Note: Fastly and NS1 have a special integration so that's an option too.
Solution C: use an Anycast CDN
Highwinds. Tata. CacheFly. MaxCDN (without their Flex POPs). Cloudflare. These are CDNs that use Anycast for routing users to the best POP. All POPs globally have the same IP address and users are 'magically' routed to the POP that is closest from a network topology perspective (shortest network path). For example, www.cloudflare.com points to 198.41.{214,215}.162 everywhere.
Since all POPs have the same IP address, the root domain problem does not exist.
Note: Fastly does not use Anycast for most customers, but can provide Anycast IP addresses if you must use their service on the root domain.
Note: Edgecast (now Edgio) uses Anycast too but per region (Americas, EMEA, APAC) so there still is a chance, although small, of suboptimal routing.