W2K multi-master features

Michael E. Hanson MEHanson at GryphonsGate.com
Fri Aug 16 15:22:14 UTC 2002


In order to run M$ Win2K DNS in Multi-Master mode, you have to run it in
Active Directory Integrated mode.  In that mode, the zone doesn't really
keep a serial number in the manner we're used to.  All changes are
identified by the server ID, a server change sequence number, and a
timestamp.  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 traditional serial
number is NOT a player until a DNS server that's not in the Win2K domain
requests a zone transfer.  At that time, if the DNS database has changed
since the last time a zone transfer was performed, the serial number is
incremented.  However, if your domain/zone is AD integrated, there should
not be any DNS servers acting as standard secondaries, they should all be AD
Integrated.

Running a single DNS on anything but a very small unimportant network is a
mistake IMHO.  Without DNS, your Win2K and WinXP clients will not be able to
locate the Domain Controller and will not be able to logon.  A minimum of
two DNS servers is recommended, more if you have multiple subnets and sites.
_______________
Michael E. Hanson
President, Gryphon Consulting  Services
(http://www.GryphonsGate.com)
P.O. Box 1151
Bellevue, NE  68005-1151
(402) 871-9622

MEHanson at GryphonsGate.com (primary)
Gryphons_Master at yahoo.com
----- Original Message -----
From: "Barry Finkel" <b19141 at achilles.ctd.anl.gov>
To: <bind-users at isc.org>
Sent: Friday, August 16, 2002 9:53 AM
Subject: Re: W2K multi-master features


> I wrote:
>
> >> My conclusion is that in a multi-master
> >> setup, the handling of zone serial numbers is very complex.
>
> Simon Waters <Simon at wretched.demon.co.uk> replied to me:
>
> >Since, to a first approximation at least, this is a
> >monotonically increasing number, it should be easy to replicate
> >in a multimaster database. Just take the biggest of your current
> >value and the update.
>
> Take this scenario.  There is one zone, xyz, on a multi-master
> MS W2k DNS with Domain Controllers DC1 and DC2.  Assume that the copies
> of the zone on DC1 and DC2 are identical and have serial number 1000.
> Now let two different machines send at the same time DDNS updates for
> the xyz zone.  After the updates, each DC has a copy of the zone, and
> each has serial number 1001.  But the contents of the zone are
> different.  (Here I am assuming that the AD synchronization has not yet
> taken place; I have no idea how it works and what is the timeframe for
> making the synchronizations.)
>
> When the synchronizations take place, what should be the serial number
> of the zone?  I claim it can not really be 1001, as 1001 has already
> been used for two different copies of the zone.  Should it be 1002?
> What if another DDNS update comes in to DC2 during the synchronization
> process.  If that synch produces serial 1002, and DC2 still has the old
> serial 1001 (the synch of the new serial number has not yet completed
> on DC2), then this new DDNS to DC2 will produce serial number 1002.
>
> The issue is that the DDNS update, the incrementing of the serial
> number, and the AD synchronization are not one atomic operation (such
> as a "compare and swap" instruction on some CPUs for handling testing
> and setting of control block flags in one non-interruptable atomic
> operation).  While these three events are occurring, another DDNS
> update can arrive independently.
>
> It is to avoid this situation that I run the MS W2k DNS on only ONE
> Domain Controller.
> ----------------------------------------------------------------------
> Barry S. Finkel
> Electronics and Computing Technologies Division
> Argonne National Laboratory          Phone:    +1 (630) 252-7277
> 9700 South Cass Avenue               Facsimile:+1 (630) 252-4601
> Building 222, Room D209              Internet: BSFinkel at anl.gov
> Argonne, IL   60439-4828             IBMMAIL:  I1004994
>
>
>



More information about the bind-users mailing list