bind at wingenbach.org
Thu May 8 19:00:22 UTC 2014
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
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
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
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.
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
> 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.)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bind-users