Why Amazon Route 53 (DNS) is Important in AWS

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.

This entry was posted in Amazon Web Services, Cloud, Server, Web and tagged , , , . Bookmark the permalink.

9 Responses to Why Amazon Route 53 (DNS) is Important in AWS

  1. Bernardo Roubach says:

    Hi Rob! Interesting post.. I’ve been reading posts regarding Route 53 since its release..

    But I came up with a doubt.. you say “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.”..

    Why not use one of the Elastic IPs offered by AWS and assign them to one of our running instances? Then we could use a regular A record in whatever DNS server..

    • Rob Olmos says:

      Hey Bernardo,

      Thank you. I may have not been entirely clear. Elastic IPs only work for EC2 instances and they do not work for services like Elastic Load Balancing, S3, CloudFront, etc. For these services, you have to use a CNAME if you want to use a pretty URL like “images.mysite.com” instead of “images.mysite.com.s3.amazonaws.com”.

      When using Elastic Load Balancing you have to use an Elastic IP for “mysite.com” (due to DNS limitations) and have an EC2 instance redirect the user to “www.mysite.com” which is CNAME’ed to the ELB.

      Ultimately, I was trying to say that when Route 53 fully integrates all of the services we can do away with the CNAMEs because it will be able to serve the correct IP address.

      • Bernardo Roubach says:

        “Elastic IPs only work for EC2 instances and they do not work for services like Elastic Load Balancing, S3, CloudFront, etc.”..

        Didn’t know that! Thank you for the information.. I’m only playing with the EC2 so far… :)

  2. Ian says:

    Anycast and abstracted management are great, but let’s assume for a second those aren’t a priority for some folks. In that case, are there any other benefits of doing DNS with Route 53 instead of spinning up two/three/four EC2 instances and running bind on your own?

    • Rob Olmos says:

      At this point, without those two features, there isn’t any add-on benefit because without anycast or the management/API layer they really are just bind servers. When AWS integrates the IPs of various services such as ELB and CF into Route 53 there will be the benefit of no longer needing to use CNAMEs eliminating their potential extra overhead.

      Depending on your DNS volume and number of zones you you’re looking to manage, the other non-add-on benefit I can think of for Route 53 is price. With three Micro instances you’re looking at about $45 dollars ($30 reserved) plus any cost to manage the instances. With five zones on Route 53 you’re looking at about $8 dollars. If you have 100+ zones to manage then you’re looking at $100+ dollars in which case the Micros are the better choice assuming you don’t need the R53 features.

  3. David Collantes says:

    Do you know of a way to add a CNAME that will cover domain.com (without the www). on Route53?

    • Rob Olmos says:

      The root domain is typically referred to as the “apex” and that cannot have a CNAME so it’s unfortunately not natively possible unless there’s a special script to monitor the ELB IP and update the apex record. Assuming EC2, the straight forward way is setup an Elastic IP and have the server redirect the browser from domain.com to http://www.domain.com with www CNAME’ed to the ELB. This is until Route 53 adds integration with ELB which is scheduled to happen but unknown when, my guess is 2Q 2011.

  4. Dns.im says:

    Hi all,

    I am one of the developer of DNS30. This is a web based UI for Amazon route 53. This will help you to manage, create Hosted Zones and add/delete resource records to your created hosted zone.

    regards -


Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>