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.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
