BIND 8 with DYNUPDATE capabilities

[Kevin Darcy]

What you call a "problem" I call a difference in design philosophy. Multi-master
replication raises the ugly problem of replication conflicts and how to resolve
them. Traditionally, DNS has avoided this problem by instead adopting single-master
replication in the context of a hierarchical delegation-and-referral model, which
allows different servers to be master and/or slaves for different parts of the
namespace. Now, if all the new applications using Dynamic Update to add DNS objects
were flexible enough to fallback to another *zone* when the primary zone master was
down, we wouldn't even be having this discussion, since that variety of
"multi-master replication" works just fine in DNS and has done so for eons. But
that's not the model that these applications prefer, apparently.

One feature of DNS that should not be underestimated is the fact that within the
DNS database itself, there is very little distinction made between masters and
slaves (NS records do not distinguish). So if a master for a particular zone fails,
it is fairly trivial to reconfigure a slave to become the new master, and this
change is virtually transparent to all read-only clients and only slightly
inconvenient for update clients. It's slightly *less* trivial to then
"fall-forward" when the original master comes back into service, but not too
terribly painful either. With some clever scripting, this could probably be
automated.

I'm not aware of any multi-master DNS proposals to IETF from Microsoft or anyone
else. It could be argued, I suppose, that single-master replication is so integral
to DNS that a multi-master name service would require a separate protocol entirely,
with different port assignments, etc. We probably wouldn't call it "DNS".


- Kevin

Johnny Fribert Lauridsen wrote:

> Yes,
> well-known problem.  Is anyone other than Microsoft trying to do something about
> this problem with DNS.  Maybe it has not been such a hot problem up till now,
> but with Win2000 and DDNS, it IS a problem with the single-primary....
> Has Microsoft proposed multimaster DNS to IETF?
> Johnny
>
> At 00:01 01/03/2000 +0000, Jim Reid wrote:
> > >>>>> "Jeff" == Wilde, Jeff <Jeff.Wilde at westgroup.com> writes:
> >
> >     Jeff> I know that windows 2000's dns it is integrated into the
> >     Jeff> active directory so that you can basically have two primary
> >     Jeff> name servers and replications is always taking place because
> >     Jeff> of the AD.  If one name server fails, the other name server
> >     Jeff> will automaticaly keep on receiving dynamic updates and the
> >     Jeff> replications will take place once the failed server comes
> >     Jeff> back into service.  I currently have bind 8 set up as a
> >     Jeff> master/slave configuration.  If my master was to fail, the
> >     Jeff> dynamic updates wouldn't be handled by my slave the way I
> >     Jeff> have it configured.  Is there a way to have either
> >
> >     Jeff> a) two primary servers that replicate zones to each other
> >
> >No. A master name server - primary is OLD jargon - is the definitive
> >source of DNS data for some zone. By definition it has nowhere else to
> >get that information other than from the zone file (or equivalent)
> >that it loads. If the server is master for some zone, it knows that
> >by implication nothing else should be master for that zone too.
> >
> >     Jeff> b) have master/slave setup with the higher soa value being
> >     Jeff> replicated to the other server.
> >
> >No. A name server that is master for some zone will NEVER EVER
> >"replicate" that zone by retrieving a copy of the zone from some slave
> >server. See the answer to your previous question.
> >
> >W2K has its own replication protocol for Active Directory and for
> >ensuring that its multiple master name servers keep in sync with each
> >other. IIUC this protocol is proprietary to Microsoft.
> >
> >     Jeff> My other question is, is there a timeout on the dynamic
> >     Jeff> updates to cancel old stale data?
> >
> >No. How can the name server tell what data is old and what isn't? The
> >responsibility for removing stale data from the zone rests with
> >whatever put it there: a DHCP server, hostmaster, etc.