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 (188.8.131.52) ns-39.awsdns-04.com (184.108.40.206) ns-690.awsdns-22.net (220.127.116.11) ns-1344.awsdns-40.org (18.104.22.168)
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 22.214.171.124 ;; Query time: 161 msec ;; SERVER: 126.96.36.199#53(188.8.131.52) ;; WHEN: Mon Dec 6 12:13:30 2010 ;; MSG SIZE rcvd: 184
While all name servers are in 184.108.40.206/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 220.127.116.11 (18.104.22.168), 30 hops max, 40 byte packets 1 swiCS5-V108.switch.ch (22.214.171.124) 0.355 ms 0.429 ms 0.546 ms 2 swiZH2-10GE-3-1.switch.ch (126.96.36.199) 0.437 ms 0.515 ms 0.610 ms 3 swiIX1-10GE-1-3.switch.ch (188.8.131.52) 6.300 ms 6.391 ms 6.486 ms 4 zch-b1-geth3-1.telia.net (184.108.40.206) 0.345 ms 0.348 ms 0.347 ms 5 ffm-bb2-link.telia.net (220.127.116.11) 11.914 ms 11.963 ms 11.991 ms 6 ffm-b10-link.telia.net (18.104.22.168) 11.846 ms 11.834 ms ffm-b10-link.telia.net (22.214.171.124) 11.834 ms 7 xe-4-2-0.edge4.Frankfurt1.level3.net (126.96.36.199) 11.960 ms 11.972 ms 11.961 ms 8 vlan99.csw4.Frankfurt1.Level3.net (188.8.131.52) 20.991 ms vlan89.csw3.Frankfurt1.Level3.net (184.108.40.206) 12.241 ms 12.220 ms 9 ae-82-82.ebr2.Frankfurt1.Level3.net (220.127.116.11) 13.459 ms 12.333 ms ae-92-92.ebr2.Frankfurt1.Level3.net (18.104.22.168) 12.699 ms 10 ae-24-24.ebr2.London1.Level3.net (22.214.171.124) 24.591 ms ae-21-21.ebr2.London1.Level3.net (126.96.36.199) 26.136 ms ae-22-22.ebr2.London1.Level3.net (188.8.131.52) 25.632 ms 11 ae-22-52.car2.London1.Level3.net (184.108.40.206) 20.163 ms 20.064 ms 19.870 ms 12 AMAZONCOM.car2.London1.Level3.net (220.127.116.11) 19.840 ms 19.868 ms 20.107 ms 13 * * *
Tracing the route to 18.104.22.168 1 vl-51.uonet1-gw.uoregon.edu (22.214.171.124) [AS 3582] 0 msec 0 msec 0 msec 2 3.xe-1-3-0.uonet10-gw.uoregon.edu (126.96.36.199) [AS 3582] 0 msec 0 msec 0 msec 3 vl-3.uonet9-gw.uoregon.edu (188.8.131.52) [AS 3582] 0 msec 0 msec 0 msec 4 eugn-car1-gw.nero.net (184.108.40.206) [AS 3701] 4 msec 0 msec 0 msec 5 eugn-core1-gw.nero.net (220.127.116.11) [AS 3701] 0 msec 0 msec 0 msec 6 eugnor1wce1-gige7-0.wcg.net (18.104.22.168) [AS 3356] 16 msec 8 msec 8 msec 7 ae-32-52.ebr2.Seattle1.Level3.net (22.214.171.124) [AS 3356] 20 msec 8 msec 16 msec 8 ae-2-2.ebr2.Denver1.Level3.net (126.96.36.199) [AS 3356] 48 msec 40 msec 36 msec 9 ae-1-100.ebr1.Denver1.Level3.net (188.8.131.52) [AS 3356] 44 msec 36 msec 36 msec 10 ae-4-4.car1.StLouis1.Level3.net (184.108.40.206) [AS 3356] 56 msec 52 msec 56 msec 11 ae-11-11.car2.StLouis1.Level3.net (220.127.116.11) [AS 3356] 52 msec 56 msec 52 msec 12 AMAZONCOM.car2.StLouis1.Level3.net (18.104.22.168) [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.
Thanks for this investigation. Are you moving your production zones to Route 53?
AWS confirmed it is an anycast network: https://forums.aws.amazon.com/message.jspa?messageID=208721#208721
Looks really nice 🙂
@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…
Interesting investigation. I’ve started a tool that does some of what you’ve mentioned:
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!