W2K multi-master features

[Simon Waters]

"Michael E. Hanson" wrote:
> 
> > >In the event of a conflict (two servers recording changes to the
> > >same DNS entry between replication cycles), the record with the newer
> > >timestamp "wins" and the older change is discarded.
> >
> >       The result of this will be the discarding of an otherwise valid
> > update.
> 
> Not true.  One of the two must be discarded.  Note that this is not simply a
> change to the same zone but a change to a specific entry, such as the A
> record for a particular host.  If two servers in a multi-master zone both
> update the same A record, then the most recent one will be kept and the
> older one discarded.  How else would you do it?

Hmm, DDNS updates are distinctly unpleasant to try and do in a
multimaster replication, but I think SOA will be easy to ensure
they end up consistent when replication has finished. 

That SOA serial will not map to a unique state of the zone is a
given, so trying to play with such data with a system using IXFR
is probably theoretically doomed, but since a properly designed
schema will converge, as long as you design to increment the SOA
with updates then AXFR could still be made to work after a
fashion. You might temporarily have records flit in and out of
existence as AXFR is done against different masters, but
ultimately the answer given would not be significantly worse
than with querying any other master in the system, althoug
perhaps slightly less timely.

I think the conflict issue applies in theory to all DDNS, as
there is no guarantee in the BIND model, that the primary
receives or distributes updates in a timely fashion, so a client
might ask to delete it's old record again, even though the
master has already done it, but the slave hasn't caught up for
some reason.

If two updates for A->B and A->C are sent in BIND the first to
reach the master will win, in Microsoft DNS presumably they
ultimately specify a server priority for certain types of
conflict, so in some cases the first to reach the highest
priority server will win, not necessarily the earlier or later
query, and the case where the time stamp is the same at the
resolution of the local timer also needs to be catered for when
doing timestamp based replication.

I need to think this area through as I seem to remember some
special cases appear in multimaster replication of relational
databases, and it will be interesting to see if any can apply to
DNS. It is just possible one applies to the SOA serial number,
but I'll read up.