Monitoring Zonefiletransfer

Barry S. Finkel bsfinkel at att.net
Wed Feb 19 19:33:10 UTC 2014


> On 2014-02-19 16:06, Barry S. Finkel wrote:
>
>> >See MS KB article 282826, where MS documents the handling of zone
>> >serial numbers in an AD environment.

And Dave Warren replied:

> My experience is that it tends to work pretty well if BIND only points
> to one particular MS DNS server at a time, with a failover script that
> detects when that DNS server goes down and flips to another master (if
> you're worried about such things)
>
> That being said, even without that script and with multiple MS DNS
> masters configured in BIND at once, any issues generally work themselves
> out within 15 minutes or so, once the Active Directory serial number
> update propagates through the MS DNS infrastructure. As described in the
> article, the servers self-increment properly when a slave is detected,
> and occasionally sync up the serial numbers between MS DNS servers
> (again, only moving update).
>
> The only inconsistencies are in those recently added/modified records,
> so if you just plan for 15 minute update times for non-MS secondaries to
> sync up and ignore the periodic "serial is lower than expected"
> warnings, multi-mastering works fine in practice.
>
> -- Dave Warren


That MS KB article states that if a Domain Controller DNS Server is
not used as a master for a slave server, then the zone serial number
is irrelevant.  But if the Server is used as a master, then the serial
number is relevant.  Assume one zone that is "mastered" on two DCs, and
the two serial numbers match (and the serial is N).  A dynamic update
for the zone is sent to DC1, and the serial number there is increased to
N+1.  At the same time a different dynamic update for the zone is sent
to DC2, and DC2 then has serial number N+1.  The two copies of the zone
are different, but they both have the same serial number.  When Active
Directory synchronizes the zone, what serial number can it use for the
synched zone?  It can't use N+1, because that serial has been used, and
the zone might have already been transferred to the slave server.
It can't be N+2, because, in the meantime, another dynamic update may
have come to DC1 or DC2, so serial N+2 might have already been used.

Another thing that I hinted in an earlier reply - With AD zones, the
serial number can increase unnecessarily.   In the past, when a
dynamic DNS update was sent to a DC, and that update was already in DNS
(e.g., a re-lease of a DHCP address), the Windows DNS Server code
treated the update as a no-op, except for updating an internal timestamp
in the zone.  But sometime later, MS changed the code, so that the
dynamic DNS update is no longer treated as a no-op.  This causes

1) the DNS update to be initially refused because it does not have
    TSIG authorization, and the client (or DHCP Server) has to re-send
    the update.

2) the zone serial number is updated, even when there is no update to
    the zone; this causes unnecessary zone transfers.

--Barry Finkel


More information about the bind-users mailing list