On 2/5/2010 5:41 PM, fddi wrote:
Hello I wanted to ask how could be possible in some way
to have 2 or more multi master name servers authoritative for one domain,
instead of the classical master slave model.
First of all, in technical terms, both masters and slaves are considered
"authoritative" for a zone, so there is in fact no distinction to be
made between "the classical master slave model" and "2 or more [...]
name servers authoritative for one domain". If you hadn't put the word
"multi" in your question, then more people would have probably pointed
that out to you.
With the word "multi" in there, however, it was obvious that there was a
genuine question lurking underneath the not-quite-technically-correct
jargon.
But, given the diverse responses to your post, it seems that different
people interpreted your question in different ways. Let me see if I can
clarify:
Interpretation #1: "multi master name servers authoritative for one
domain" = multiple BIND instances with the same zone defined as "type
master", only 1 (at most) of them allowing Dynamic Update requests from
clients
Yes, this is doable. You'd need to designate one of them as the
"primary" master, which would also be the one to allow Dynamic Updates
(if desired), then have an out-of-band mechanism (e.g. rsync, as
mentioned) for transferring the zone contents over to the other
"master"s periodically and/or whenever it changes, along with a way to
tell the receiving nameservers to reload the zone from the transferred
file (e.g. "rndc reload"). Alternatively, as one responder suggested,
and as many commercial products implement, have the updates made to
something other than a BIND instance (e.g. a relational database), and
then have a mechanism whereby the zone contents are "published" or
"pushed" from that non-BIND source to all of the BIND instances, which
are defined as "type master".
Interpretation #2: "multi master name servers authoritative for one
domain" = multiple BIND instances capable of accepting Dynamic Update
requests from clients
Interpretation #2a: not fault tolerant, i.e. the failure of a particular
BIND instance would cause all of the Dynamic Updates made for the
duration of its outage to be lost
Yes, this is also doable. Define one as "type master" and the
others as "type slave", with update forwarding enabled
Interpretation #2b: fault tolerant
Barely doable, or, arguably, not doable at all (depending on
concurrency/consistency requirements). You'd need to define them all as
"type master", allowing Dynamic Updates, and then have some sort of
"reconciliation" process to bring them all into sync with each other
periodically, bearing in mind that the updates might actually conflict
with each other (e.g. adding and deleting the same record within the
same reconciliation interval). You could resolve conflicting updates
based on something like timestamp (thus raising a requirement of tight
time synchronization between your BIND instances), on the identity of
the nameserver which received the request, the identity of the client,
or some other relevant attribute. There is, to my knowledge, no standard
governing how "inconsistent" zone contents *should* be reconciled, so
basically you can pick whatever mechanism or convention you feel is best
in your environment. Note also that if a given "master" receives a
Dynamic Update request which contains a *prerequisite*, e.g. "add this
name only if this other name exists", then you may find that the update
is spuriously rejected or accepted, because even though the prerequisite
may be satisfied *somewhere*, the data on which it bases its acceptance
or rejection, might not have sync'ed to that particular BIND instance
yet. These spurious acceptances/rejections can lead to unexpected and
perhaps undesirable behavior in the client or may be detrimental to the
cleanliness and/or consistency of your DNS data.
Theoretically, I suppose you could have something transparently redirect
Dynamic Update requests aimed at your BIND instances, to some non-BIND
backend database, which would process them and then publish/push the
results out to the BIND instances. From a BIND perspective, this would
be Interpretation #1, even though it would it would appear to clients
like Interpretation #2. In the fault-tolerant variant, you'd still have
the challenge of reconciling conflicting updates, however, but that
would be something that the non-BIND database or its supporting
software/algorithms would need to handle.
- Kevin
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
