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.flagthis.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 flagthis provides addresses in the following format. HOSTNAME.TWITTERHANDLE.dynamic.flagthis.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.flagthis.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.