Amazon Route 53 DNS Service Examined

Amazon has announced a new authoritative DNS service – Route 53.

Sign up is straightforward – click a few buttons on aws.amazon.com, and a few moments later, you’ll have an email confirming your access to the service. If you dig into the Getting Started Guide, you’ll note that “Part of the sign-up procedure involves receiving a phone call and entering a PIN using the phone keypad,” however, that wasn’t necessary for me. Perhaps it’s only for new AWS accounts?

There is no user interface in the AWS Console although there are indications one is on its way. The Route 53 developer tools are fairly bare-bones at this point – four Perl scripts. Those scripts require relatively uncommon Perl modules, not included in the default Ubuntu (Lucid) repositories, although they are available through CPAN.

However, the third-party Boto Python interface to Amazon Web Services already includes support, and presumably other tools are also rapidly adding support, if they don’t have it already.

Using the Perl tools, I created a zone for an example domain – gearlister.org – and was given four name servers:

ns-1945.awsdns-51.co.uk (205.251.199.153)
ns-39.awsdns-04.com (205.251.192.39)
ns-690.awsdns-22.net (205.251.194.178)
ns-1344.awsdns-40.org (205.251.197.64)

The cross-section of TLDs increase the likelihood that a glue record for one of the Route 53 name servers will be returned with a query to the TLD name servers, reducing latency for clients:

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> @d0.org.afilias-nst.org gearlister.org
; (2 servers found)
;; global options:  printcmd
;; Got answer:
;; >>HEADER<<- opcode: QUERY, status: NOERROR, id: 51176
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; QUESTION SECTION:
;gearlister.org.                        IN      A

;; AUTHORITY SECTION:
gearlister.org.         86400   IN      NS      ns-39.awsdns-04.com.
gearlister.org.         86400   IN      NS      ns-1945.awsdns-51.co.uk.
gearlister.org.         86400   IN      NS      ns-1344.awsdns-40.org.
gearlister.org.         86400   IN      NS      ns-690.awsdns-22.net.

;; ADDITIONAL SECTION:
ns-1344.awsdns-40.org.  86400   IN      A       205.251.197.64

;; Query time: 161 msec
;; SERVER: 199.19.57.1#53(199.19.57.1)
;; WHEN: Mon Dec  6 12:13:30 2010
;; MSG SIZE  rcvd: 184

While all name servers are in 205.251.192.0/18, there appear to be separate routing table entries for each /23 containing a name server. Further, the servers appear to be anycast to different locations around the world:

traceroute to 205.251.199.153 (205.251.199.153), 30 hops max, 40 byte packets
 1  swiCS5-V108.switch.ch (130.59.108.5)  0.355 ms  0.429 ms  0.546 ms
 2  swiZH2-10GE-3-1.switch.ch (130.59.36.138)  0.437 ms  0.515 ms  0.610 ms
 3  swiIX1-10GE-1-3.switch.ch (130.59.36.129)  6.300 ms  6.391 ms  6.486 ms
 4  zch-b1-geth3-1.telia.net (213.248.79.189)  0.345 ms  0.348 ms  0.347 ms
 5  ffm-bb2-link.telia.net (80.91.249.115)  11.914 ms  11.963 ms  11.991 ms
 6  ffm-b10-link.telia.net (80.91.251.250)  11.846 ms  11.834 ms ffm-b10-link.telia.net (80.91.251.126)  11.834 ms
 7  xe-4-2-0.edge4.Frankfurt1.level3.net (4.68.63.121)  11.960 ms  11.972 ms  11.961 ms
 8  vlan99.csw4.Frankfurt1.Level3.net (4.68.23.254)  20.991 ms vlan89.csw3.Frankfurt1.Level3.net (4.68.23.190)  12.241 ms  12.220 ms
 9  ae-82-82.ebr2.Frankfurt1.Level3.net (4.69.140.25)  13.459 ms  12.333 ms ae-92-92.ebr2.Frankfurt1.Level3.net (4.69.140.29)  12.699 ms
10  ae-24-24.ebr2.London1.Level3.net (4.69.148.197)  24.591 ms ae-21-21.ebr2.London1.Level3.net (4.69.148.185)  26.136 ms ae-22-22.ebr2.London1.Level3.net (4.69.148.189)  25.632 ms
11  ae-22-52.car2.London1.Level3.net (4.69.139.99)  20.163 ms  20.064 ms  19.870 ms
12  AMAZONCOM.car2.London1.Level3.net (212.187.193.2)  19.840 ms  19.868 ms  20.107 ms
13  * * *
Tracing the route to 205.251.199.153

  1 vl-51.uonet1-gw.uoregon.edu (128.223.51.2) [AS 3582] 0 msec 0 msec 0 msec
  2 3.xe-1-3-0.uonet10-gw.uoregon.edu (128.223.3.10) [AS 3582] 0 msec 0 msec 0 msec
  3 vl-3.uonet9-gw.uoregon.edu (128.223.3.9) [AS 3582] 0 msec 0 msec 0 msec
  4 eugn-car1-gw.nero.net (207.98.68.181) [AS 3701] 4 msec 0 msec 0 msec
  5 eugn-core1-gw.nero.net (207.98.64.161) [AS 3701] 0 msec 0 msec 0 msec
  6 eugnor1wce1-gige7-0.wcg.net (64.200.134.197) [AS 3356] 16 msec 8 msec 8 msec
  7 ae-32-52.ebr2.Seattle1.Level3.net (4.68.105.62) [AS 3356] 20 msec 8 msec 16 msec
  8 ae-2-2.ebr2.Denver1.Level3.net (4.69.132.54) [AS 3356] 48 msec 40 msec 36 msec
  9 ae-1-100.ebr1.Denver1.Level3.net (4.69.132.37) [AS 3356] 44 msec 36 msec 36 msec
 10 ae-4-4.car1.StLouis1.Level3.net (4.69.132.181) [AS 3356] 56 msec 52 msec 56 msec
 11 ae-11-11.car2.StLouis1.Level3.net (4.69.132.186) [AS 3356] 52 msec 56 msec 52 msec
 12 AMAZONCOM.car2.StLouis1.Level3.net (4.53.162.66) [AS 3356] 56 msec 56 msec 56 msec
 13  *  *  * 

Adapting the Getting Started Guide, I created two A records for “gearlister.org” and “www.gearlister.org”. For reasons I wasn’t able to track down – or reproduce – adding the “gearlister.org” A record failed the first time, although I was able to add it later.

Update 12/7/2010: I received an email from Amazon earlier today explaining the failed A record add:

Here’s what happened. In our “Getting Started Guide” we incorrectly provided an example ChangeResourceRecordSets request that showed a single element that included multiple elements. This was a mistake. In reality, only one element is permitted per element. Our API accepted this request as valid, but silently only processed one of the elements. We have now fixed both the documentation and the configuration API to enforce the proper semantics.

Record changes propagated quickly, although the zone serial number did not increment. Given the lack of support for connecting secondary servers to Route 53 and the API support for checking whether a change has propagated, this may matter little in practice, although it is certainly odd.

Although there is no direct support for secondary servers using Route 53 as primary DNS – or for using Route 53 as a secondary to a non-Amazon primary – the BIND conversion scripts hint that it should be straightforward to have a master script update Route 53 and non-Route 53 zone configuration simultaneously. Also, while Route 53 does support AAAA records (ironic, given that you cannot use IPv6 to address EC2 instances), it does not yet support DNSSEC.

At $1/domain/month and $0.50/millon queries, pricing is extremely low for anycast DNS. However, given the lack of integration with some of Amazon’s other products, such as Elastic Load Balancing – apparently forthcoming – and the limited tools for managing zones, uptake will probably be limited initially. Some heavy AWS users may be hesitant to put their DNS on the same service provider as the rest of their infrastructure – although ultimately, as Amazon adds features, the benefits of Route 53 may outweigh the risks.

Advertisement

3 comments

  1. Andy

    @Jurg – thanks for posting the anycast confirmation.

    I haven’t moved anything production to Route 53 yet, and I don’t know that I’d host a zone entirely in Route 53 – it’s a lot easier to recover from a provider ceasing to provide service to you (for whatever reason) if all your DNS infrastructure isn’t with them too.

    That means I’d need to write a tool to manage BIND and Route 53; I’m thinking of using Boto and dnspython together maybe…

  2. barnybug

    Interesting investigation. I’ve started a tool that does some of what you’ve mentioned:
    http://github.com/barnybug/cli53

    It can import / export bind format.

    To be able to maintain sync it shouldn’t be too hard to add ‘diff’ of route53 against a zone file and apply the necessary changes.

    Would be interested in what you think!