Secondary Master

John Wingenbach bind at
Fri May 11 17:38:16 UTC 2012

The concept of a "secondary" master is sound.  It basically provides for 
a healthy means of handling the situation where your primary master is 
unusable.  To enable and support a primary/backup dns master, the backup 
master is initially setup as noted as a slave server.  Any other slave 
servers for the primary master also need to be pre-configured to treat 
the secondary master as a master.  Thus, when the primary master is 
unavailable, the task is simply to reconfigure the secondary master as a 
true master and to temporarily break the link between the primary and 
secondary.  Upon recovery, you would have to convert the original 
primary master as a slave to get updates from the secondary and then 
re-enable it as the primary.

This is a relatively simply explanation of what can be done to support a 
primary/secondary master.  Obviously, there's a lot of work to support 
the flipping of masters which requires intelligent scripting to make it 
failure resistant.

It would be nice if bind natively supported the concept.  However, until 
such time, manual / scripting means are needed.

On 05/11/2012 11:27 AM, WBrown at wrote:
> John  wrote on 05/11/2012 11:05:58 AM:
>> I found this article about setting up a secondary master.
>> This may be useful as we are bringing up a disaster recovery site.
>> The author explains that the zone type should be ?slave?? so it can
>> receive db updates from the normal master.
>> Seems like that makes it a slave instead of a master for that zone?
>> We are also looking at the app rsync for db transfers so we will
>> have mirrored masters, IP traffic separated by routers.
>> Thanks
> What they describe is a typical slave server.  I wonder if they are
> misusing the term master for authoritative.
> They are correct that more than one server "is needed in order to maintain
> the availability of the domain should the Primary become unavailable."
> It's a good idea to make sure that your DNS servers are physically
> separated so a network failure does not block access to all of them.
> I would just let zone transfers take care of keeping things in sync
> instead of using rsync and a bunch of custom procedures to so it.
> Confidentiality Notice:
> This electronic message and any attachments may contain confidential or
> privileged information, and is intended only for the individual or entity
> identified above as the addressee. If you are not the addressee (or the
> employee or agent responsible to deliver it to the addressee), or if this
> message has been addressed to you in error, you are hereby notified that
> you may not copy, forward, disclose or use any part of this message or any
> attachments. Please notify the sender immediately by return e-mail or
> telephone and delete this message from your system.
> _______________________________________________
> Please visit to unsubscribe from this list
> bind-users mailing list
> bind-users at

More information about the bind-users mailing list