multi master primary nameserver.

[Kevin Darcy]

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