Multi-master (HA)

[John Wingenbach]

I wouldn't say we migrated in that direction due to anything other then 
lack of good options.  What BIND is missing is the concept of an update 
master.

Augment BIND with the following:

  * Each master is aware of the other masters.
  * One master is defined as an update master (rndc control?)
  * Each master knows all the configurations necessary to act as a slave
    to the update master
  * Each master knows all the configurations necessary to be the update
    master.


With the above, it would become relatively trivial to simply issue a 
directive and have the servers change their roles.  If the update master 
is isolated, the directive must be able to be accepted at one of the 
other masters so that it can become the update master.  When the 
isolation ends, the update master must realize it's new state and demote 
itself cleanly.

I am doing this manually by having the zone configurations hold the 
masters list as well as update policies.  To convert, the only lines 
that get changed are the "type", "masters" and "update-policy" stanzas.  
They get (un)commented as appropriate and then bind reloaded. The one 
trick I had to pay attention to is that when making the update master a 
slave master, I needed to touch all the zone files to prevent bind from 
immediately expiring them.  It is also necessary to issue rndc refresh 
commands to the new slave to force it to perform SOA checks against the 
new update master.  Otherwise, in the case of isolation, it won't bother 
to update it's zones until the next refresh cycle ends.

-- John

On 5/8/2014 7:32 AM, Tony Finch wrote:
> A few thoughts...
>
> The DNS protocol is already pretty good at replicating zone data - see for
> instance John Wingenbach's message in which he describes how their
> deployment gradually converged on a fairly standard architecture :-)
>
> I think multi-master makes most sense if the primary master uses DNS
> UPDATE for zone edits (and use raw file format), to minimize the
> differences between the primary and the secondaries.
>
> You probably want to ensure update forwarding is allowed, so that update
> clients do not have to worry so much about finding the current primary
> master.
>
> When a secondary takes over as primary it will need to update the SOA
> MNAME to point to itself so updates go to the right place.
>
> Most of the problem is actually one of remote configuration management:
> promoting a secondary to a primary is not all that different from setting
> up the secondary in the first place or making other co-ordinated changes.
> For instance it would be nice to be able to set up a zone once on the
> primary and have it automatically provisioned on the secondaries.
>
> I like Phil Mayers' zone-template idea, which might make it easier to flip
> from secondary to primary, as well as reducing the size and ensuring the
> consistency of large configs.
>
> Metazones are a tempting idea but the details get yucky the more of BIND's
> features you want to support. Also I am rather wary about the idea of
> putting secrets in a DNS zone; if you have an out-of-band way of
> distributing them it makes sense to use the same channel for the rest of
> the configuration.
>
> (http://ci.nii.ac.jp/naid/110007502948 - Vixie's metazones paper.)
>
> Tony.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20140508/0325d287/attachment.html>