The other night I was trying to finish up a blog post on why AWS needs to add DNS to their services and then I get an email announcing Route 53, AWS’s DNS service. About time. Instead of saying why AWS needs it as I originally was going to, I’ll detail why this is a very important addition, which covers the same ground.
AWS is big on CNAMEs. Any place you want a “pretty domain” (or smaller too if you’re trying to cut down on the HTML response size) instead of AWS’s monster URLs you have to use a CNAME. CNAMEs work fine and it’s nice that AWS supports them for services like CloudFront and S3 (Virtual Hosting) as compared to other cloud providers… With the Elastic Load Balancing it’s required because the IP address changes. Usage of CNAMEs with AWS have a couple subtle issues, though, two of them being management and latency.
The management isn’t ultimately as big of an issue as the latency issues. Unless you need an API to the DNS, multiple identifies/accounts to manage the records, and so on then management isn’t much of a problem besides being managed by another provider.
The latency, however, can be a bigger issue. When CNAMEs are used with DNS records they don’t actually provide an answer. What they actually provide is a more of a finger-point that says “look over here for the answer.” This results in extra look-ups and extra look-ups are overhead that add latency to the requests.
Amazon’s DNS and Route 53, which is currently on UltraDNS and will eventually moved to Route 53, is rather fast because it is anycast’ed. Anycast allows servers in multiple datacenter’s to handle the request which suits UDP well since it is not connection oriented.
However, it’s likely the DNS servers for your domain isn’t anycast. It’s also possible the DNS servers aren’t geographically close to your target audience if your target audience is in a specific region such as Los Angeles. If you’re really unlucky, the randomly assigned DNS servers from the registrar could be on the east coast with your website servers and target audience on the west coast (assuming the US or anywhere). That’s latency even the fastest website servers cannot eliminate. It’s not terrible, but it’s also not as good as it could be nowadays.
Another pitfall with CNAMEs is that some (most? all? Network Solutions does) DNS servers will return the root servers in the authority and additional sections of the DNS answer pushing the UDP packet near the size limit. Keeping in mind how long the AWS CNAMEs can be too eg. my-elb-65147120.us-west-1.e lb.amazonaws.com this gets very close.
You will want to avoid exceeding the UDP packet size limit at all possible because when that happens the whole DNS resolution has to happen again over TCP (unless the resolver & server make use of the the extension mechanism for DNS EDNS) which has even more overhead than UDP. That can potentially be an added 150ms of simple DNS resolution free of charge. Not good.
Route 53 to the rescue. When AWS integrates the Elastic Load Balancer into Route 53 next year, this and zone apex redirect and hopefully the CNAME business will be done away with. Because only AWS knows what IP your ELB is currently operating as they can fill that IP into whichever record you designate avoiding the CNAME and avoiding the subsequent DNS resolutions and latency. Maybe they’ll integrate CloudFront and S3 and also do away with those CNAMEs. Combine that with the anycast low-latency, high-availability benefits of Route 53 and that is one sweet boost.