Question about DDNS

[Kevin Darcy]

news at lpmd.org wrote:

> I am presently arguing with "the powers" about how to support the
> upcoming Active Directory project. Of course, they want this
> AD-integrated DNS from Microsoft, and I am pushing for BIND. I am
> looking through a document prepared from a study "they" funded that
> reads:
>
> "...[In a traditional BIND environment], DDNS updates cannot be made
> if the primary DNS server fails..." The argument goes that in AD-DNS,
> any domain can update the DNS. Therefore, they seem to argue, it
> doesn't matter if the primary server fails, because next time the
> directory gets sync'ed, the new entry will be propagated.
>
> >From what I know about BIND/DDNS, an updater (that is allowed to
> update the zone) will fetch the zone's NS records. Then it will send
> the update to the selected server. If that server is not actually
> primary for the zone, it will forward that update request on up. So
> assuming I am somewhat correct and on the right track, I have a couple
> of questions:
>
> o Assuming first of all, I would only allow my DHCP server to update
> on client's behalf... Once the updater fetches NS records for the
> zone, how does it select to which name server to send the update?

By default, the client should attempt to update the NS which is mentioned
in the MNAME field of the SOA record. But the RFC allows for a local
override.

> o If the master the update eventually makes its way to is down, is
> that update dropped on the floor, ie, is there any queuing mechanisim
> in place.

If the master is down, the client will never get an acknowledgement that
the update failed or succeeded. It should then (after an appropriate
timeout period, of course) try other NS'es, but of course they are all
either a) dead themselves, b) configured to refuse update forwarding, or
c) unable to contact the master, since it's dead. So that won't work
either. On its face, then, Dynamic Update would appear to inherently have
a Single Point of Failure.

This is not to say, though, that you couldn't rapidly reconfigure one of
the slaves to be a master if the regular master fails. This should be
eminently scriptable/automatable.

There is an ultimate tradeoff to be made here between consistency and
availability. Multi-master setups like Microsoft's are great for
availability, but what happens if two clients make conflicting updates on
different masters? One of them wins and one of them loses, is what
happens. So one client that legitimately *thinks* it made an particular
update may discover that the update was never actually made. Ick. This
is, I think, one of the reasons Microsoft clients do all sorts of
redundant adds, deletes, re-adds, re-deletes, etc., i.e. because they can
never be quite sure that any given Dynamic Update actually "took".

Single-master-with-fast-switchover may result in slight delays when the
switchover is actually occurring (which should be a tiny percentage of
the time), but at least it gives a guarantee of consistency.


- Kevin