DR friendly DNS administration tool

[Howell]

I am looing for a tool to help me with my external DNS administration and reconciliation between HQ and DR. At HQ my domain names are associated with the IP block at HQ but in a disaster the servers will migrate to the colo and domain names need to be reassociated with the IP block down at DR. I’m looking for a tool that will help me with the change management aspect of keeping the zone files up to date. Even better if the same tool would help swap out the zone files when the time comes.

 

[Mercutio]

Why aren't you just setting up the DR's DNS servers as a secondary zone so that you have something on-hand to edit when the time comes? Presumably then it's just a matter of editing a record with your registrar to get to something usable.

Am I missing something about your configuration?

 

[Howell]

I can define how quickly my DNS changes propogate to the world with the SOA record; but I can not control how quickly a registrar makes changes. Plus it is a manual process. I currently have the primary DNS server at DR with secondary DNS services provided by my circuit provider. I have a system designed but not completely implemented that will take a standby set of record files for DR and replace the HQ set of files. The big downside is that I have to maintain two sets of records. I would not turn up my nose at a service that would accomplish these goals plus get my primary into the cloud. Technical solutions overcoming political roadblocks, if you will.


My goal is to have the DNS records synced with the secondaries and propogating to the internet in less than an hour. Today I'm within 15 minutes but its a more manual process than I'd like.

 

[Mercutio]

DNS is pretty cloud-y to begin with and for the most part it's completely manual. It sounds like you'd just be moving around a single point of failure but moreover by the nature of DNS, you're not going to have any control over the speed of propagation
regardless.

What about something like a dynamic DNS provider like DynDNS? You can pay them a small amount of money and run an updater client with access that would probably not be too horrible to script.

 

[Howell]

I have 15 or so domains and sub domains I need to modify with a minimum of 5 records each. It looks like I'm going to be able to get everything switched over with a combination of pre-built files and dnscmd.exe to update the serial number. Now if I could just speed up the record keeping portion of it to be less manual. Ok now I can sleep.

 

[blakerwry]

What services/applications are provided by these domains (www, email, VoIP, etc). And how seamless does the failover need to be ( instant/completely transparent, couple minutes/clients might need to refresh or restart, couple hrs/clients will need to try again later) ?

Can you provide an example zone file for a typical domain?

 

[Howell]

The scenario is to fail over the externally facing servers in a production environment to another location with a different IP block in case of catastrophy and complete loss of physical site. I would like to have the failover complete in under an hour, faster is cake. Services are a mix of HTTP/S, FTP, EDI, MX, DNS. Each zone file is a mix of records that need to change and some that don't. Changes are made to any one of the domains/records about twice a month.

 

[blakerwry]

All of the applications you mentioned should honor DNS TTLs. You can reasonably set your zones' TTLs to 30min, giving you an average failover time of 15 min, 30 min worst case.

If you can use cnames on the 15 zones pointing back to a single zone, this would simplify the failover process: 1 zone to update instead of 15. I often leave records commented out so they can later be activated or reactivated, this may be a solution, or as mentioned completely separate backup/alt files.

You mentioned MX, but didn't say POP/IMAP. One thing to be aware of is that mail clients will typically perform a DNS lookup when started and that's it. The do not refresh DNS info or honor TTLs. If you're using DNS as a failover mechanism, these clients will need to be restated. It sounds like this may be acceptable though.