Dynamic registration fault tolerance

Kevin Darcy kcd at daimlerchrysler.com
Wed Sep 12 23:10:50 UTC 2001


Cricket Liu wrote:

> > With BIND 9.1.1 is there a way to have two DNS servers that can be capable
> > of accepting dynamic updates for a particular zone while keeping each
> other
> > synchronized with the same information.  This would obviously be a nice
> > feature for fault tolerance (Microsoft calls this re-definition of
> standards
> > "multiple-master").
>
> No, there isn't.

The closest kludgey solution would be have the "master" be a round-robin,
pointing to the real master and one or more slaves, with the slaves normally
forwarding any updates they get, and then to quickly reconfigure one of the
slaves as master in case of a failure of the regular master. It's not
technically "multi-master" -- more like multi-fake-master-with-hot-standby --
but at least you wouldn't have to reconfigure any clients.

Note that (true) "multi-master" has an inherent problem with resolving
conflicting updates. What if one client deletes a name entirely while another
client simultaneously changes its value, adds an RR to the name, or some other
operation that presumes that the name already exists? Or what happens if one
client adds a CNAME and another client adds a record with the same name and a
different type or a different RDATA (the combination of which is of course
illegal)? When the "masters" go to replicate, they'll discover a conflict and
have to resolve it somehow (I think Win2K uses timestamps, but I still wonder
how it resolves these conflicts when the timestamps are identical). Ultimately,
whatever conflict-resolution algorithm is used, one of the updates will be
lost. So when you update a "multi-master" server, you can never really be sure
that your update "took" or not. This bothers me. I expect a master to be
telling the absolute truth when it claims to have accepted an update, not
"I think this update is okay, but I won't know for sure until I've replicated
with all of the other masters". Bleah.


- Kevin




More information about the bind-users mailing list