W2K multi-master features

[Josh Littlefield]

Simon Waters wrote:
> "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?

Actually, conflict resolution must occur when any RR on a name is changed on 
2 DC's between replications, not just when the change affects the same type. 
  This is because AD stores all RRs for a name on a single attribute (or did 
last time I checked).

> 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.

Yes, assuming the zone data reaches a stable state (no changes for an entire 
replication interval), the same serial number should map to the same zone 
contents within one replication (if 2 servers are involved).  But the zone 
may never be stable for an entire replication interval, so the serial number 
may not stabilize.

> 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.

Yes, IXFR won't work if serial number identity is violated, unless each 
secondary only talks to one master, or requests an AXFR when talking to a 
different master than it talked to before.

> 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.

DNS Update provides prerequisite support and a guarantee of atomicity to 
avoid such problems.  If the client cares whether a record is present as a 
condition of an update, it can assert as much in the prerequisites of the 
update packet.  Unfortunately, AD's multi-master approach violates the 
atomicity requirements and means that such prerequisites can only be tested 
locally.  Two clients which use prerequisites to avoid performing 
conflicting actions can still get the wrong result if talking to different 
masters in AD.  This cannot happen in the single-master case, for example, 
with BIND.

> 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 don't think there is any server priority.  Conflicts are resolved by the 
object sequence number, which is a replicated part of the object.  The 
highest sequence number wins (the copy which was updated the most since the 
last replication).  If the sequence numbers match, the timestamp is a 
tie-breaker.  If the timestamp matches, I don't know who wins.

> 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.

AD is not a database.  Database instances are normally tightly coupled, 
though in single master cases slaves may run a bit behind.  AD is loosely 
coupled and non-transactional.  Replication happens infrequently (I think 
the default is once per hour, and the minimum time I recall being able to 
set was once every 15 minutes).

-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
joshl at cisco.com                                      250 Apollo Drive
tel: 978-497-8378  fax: same               Chelmsford, MA  01824-3627