Internet Performance Delivered right to your inbox

The Managed DNS Carpool Lane: Dynect Platform And Amazon’s Route 53

Making Amazon Route 53’s basic DNS an overprotection option to Dynect’s advanced DNS solution

Everyone who knows about DNS understands that Dynect is the perfect DNS platform (sure, I work here but it still happens to be true).

The fact of the matter is that Dynect has been running with 100% uptime since its release in 2007 and has only become more solid since then with 17 global datacenters and a wide array of services such as Active Failover and Global Server Load Balancing (GSLB) to ensure your web site is always available and as quick as possible to respond.

Even so, it’s never bad business to overprotect yourself and often times, it is business policy to do so with a secondary DNS provider. With Amazon Route 53 entering the marketplace offering a sturdy basic DNS, it only makes sense to take advantage of it in this capacity.

The biggest barrier to entry is that the only way to access Amazon Route 53 is via an xml based REST API. In other words, it does not have out of the box capacity to handle standard DNS notify messages. That is where the scripts found here come in. Written in Python and controlled by two rather simple configuration files (explained in the setup.doc file here), you can quickly create a server which will bridge the gap between the Amazon Route 53 API and the DNS standard notify messages that Dynect issues.

The basic function of the scripts is to act as the interface for the secondary DNS server by both polling on a set time to sync Dynect fqdns down to Route 53, as well as reply to notify messages that Dynect sends to the server (the scripts are dynamic enough so that you could run either a timed sync or notify replies only as well). When a notify message is received or a timed sync begins, the scripts will check any fqdns that you have specified in the config files to see if there have been any changes since the last sync.

If there has been, it will pull the fqdn’s DNS records from Dynect and use these records to buildup the xml REST update to send over to Route 53, then update the current serial number of the the fqdn record. If the sync was initiated by a notify message, the script will reply to Dynect to let it know the notify was indeed received and has been handled. Logging is, of course, included and configurable so you can look to see the history of your DNS secondary’s syncing activity.

Since Route 53 does not support many advanced DNS services, if you use GSLB, Active Failover, CDN Manager or DNSSEC, the records are converted to their basic equivalents in Route 53 and as such you would lose that functionality. Therefore this setup wouldn’t be recommended if you are using these.

So if you have been sitting around saying “Wow, this sounds cool” (and let’s be honest, who hasn’t been saying this to themselves while reading this), why don’t you give it a try yourself? All of the scripts and the setup.doc are available here. If you aren’t a Dynect customer yet, let’s get you set up with a demo account to try this out. Just email us at sales@dyn.comand we’ll make that happen for you!


Share Now

Whois: Kevin Gray

Kevin Gray is a Sales Engineer for Dyn , the world leader in Internet Performance Solutions that delivers traffic management, message management, and performance assurance. Follow on Twitter: @tuftsmoose and @Dyn.