Secondary Master
John Wingenbach
bind at wingenbach.org
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 e1b.org 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
>>
>> https://help.ubuntu.com/8.04/serverguide/dns-configuration.html
> 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 https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
More information about the bind-users
mailing list