Providing Dynamic DNS over “Amazon Route 53” ( a hackathon )

On hindsight, yesterday’s “Route 53” announcement was not completely unexpected. Amazon is an IAAS provider and its in their own interest to automate infrastructure as much as possible. After tackling monitoring and cloudfront features, DNS was one of the more obvious targets for improvement.

So when I was trying to pick a challenge for this morning’s hackathon, I picked one around “Amazon Route 53”  service. At the end of the day I had a almost functional public dynamic DNS service using “Route 53” as the DNS service and Twitter’s oauth service for authentication. The final hack is up here http://www.XXXXXXX.com/. You are most welcome to play with it and/or use it.

After the initial creation of user in the system (with a little help from twitter’s oauth), the end user is free to use the browser based web application or  lynx or curl based REST interface to add/create/update host records. The current version only supports “A” records, but it would be expanded to other records if there is enough interest.

A one line script in cron is all you need to make sure all your DHCP based services are always publically addressable over the internet.

The current version of XXXXXXX provides addresses in the following format. HOSTNAME.TWITTERHANDLE.dynamic.XXXXXXX.com

Here are some of my other observations, as I tried to use Route 53 for the first time today.

• I was forced to install some CPAN modules on my ec2 instance which sucked up a lot of time.
• There are two scripts you really need from Amazon’s code library to learn the basics of the service “route53zone.pl” and “dnscurl.pl”. The first one helps you create the XML file which in turn creates new “zones”. And the second script is what gets used to upload and execute new requests using XML files.
• “dnscurl.pl” requires your secret and key in a file in home directory with 600 as the permission of the file.
• Once the basic commands started working, I focused on more complex requests like “update” and “delete”
• Thats when I figured out that there is no concept of “update” in Route 53. If you want to update a record you have to send out a “delete” and “create” request. To avoid disrupting a live system, they recommend the deletion and creation happen in the same request (acts like an atomic transaction)
• Another thing I realized is that the only way to delete an old record is to have complete information about that request from when it was created. For example lets say you created an entry “xyz.XXXXXXX.com” A 10.10.10.10 with 1400 as the TTL, then you have to send all of this information again at deletion time (including the TTL) to delete it. This was slightly frustrating.
• At the end of the day I couldn’t figure out a quick way to list all the hosts in a zone, or search for details of a particular record in a zone. This is next on my list. The way I got around this step is by using “dig” to get all that information using DNS protocol instead of HTTP based API.
• Every change request submitted has a 10 to 15 character request ID associated with it. A client can poll the status of this request ID anytime. Since I was playing with small number of changes, most of them completed within a second of submission. While the change is happening, the status of the request is set to “PENDING” and it switches to “INSYNC” as soon as the change is complete.

Folks who have been using S3/SimpleDB as a datastore for service registry should strongly consider using “Route 53” for the same thing. And if you are still running your own DNS servers on EC2 I think its time for you to question yourself if its time to move on.