DR bind

[Michael Milligan]

Sandy Mackenzie wrote:
> Hi,
> 
> I was wondering if anyone see any issues with the following scenario?  
> 
> DNS1 primary
> DNS2 secondary
> 
> In the event we lose the site where DNS1 exists permanently.
> 
> Can we simply convert the DNS2 configuration file to a become a primary for the zones it was set to be a secondary for, to ensure the zones do not become stale?  

You can, but there are likely bigger issues at play.

> 
> I am trying to think of some implications.
> 

Do you have a DR site?  Is DNS2 at the DR site?  I'm keying off your
subject line... If so, you should re-think where the primary is.  When
there is a DR site in the picture, I often deploy the DNS primary server
at the DR site, after all, it is supposed to go live ("hot") should you
lose one of the sites it is DR for.  This, of course, only works if the
DR site is "warm" (or even "hot"), i.e., online all the time.  If the DR
site is "cold" and offline most of the time, or as is sometimes the
case, has servers and LAN segments duplicated from the live sites,
addressing and all, then you can't put a live primary there.  You have
to work out some out-of-band backup and transport of the live primary
zone files to the DR site DNS server.

The other benefit of having the primary at the DR site is you haven't
lost your "seat of administration" during a DR event, and don't have to
worry about converting a secondary to a primary and reconfiguring other
secondaries to get it back...  you are in all likelihood going to need
to make a bunch of emergency DNS changes to get everything online and
working with the DR site.  Makes it easy if the primary is already at
the DR facility.

This also doesn't interfere much when you do DR failover tests as the
secondaries will be resilient to connectivity loss to the primary.
About the only thing you have to worry about is dynamic updates during
those times, but those are usually re-tried later (typically from DHCP
servers or Microsoft DCs).

Some food for thought.

Regards,
Mike

-- 
Michael Milligan                                   -> milli at acmeps.com