failed while receiving responses and jnl touching
b19141 at achilles.ctd.anl.gov
Tue Apr 4 14:58:06 UTC 2006
Kevin Darcy wrote in reply to my reply:
>I can follow your reasoning with respect to Dynamic Updates "corrupting"
>a zone transfer that's already in progress, although if that is the root
>cause, I think ISC should probably produce a better error message, since
>it's not obvious in the least from the error message what the cause of
>the problem is.
>However, since 95% of the "not exact" errors I see in my logs are for
>zones hosted on MSDNS servers, even though the number of such zones are
>dwarfed by the number of non-MSDNS-hosted slave zones, and even though
>client registration in those zones is *disabled* in our environment, I'd
>have to say there's at least circumstantial evidence of other
>deficiencies in MSDNS's zone-transfer code or overall design (maybe all
>of the DCs are rabidly re-registering their SRV records via Dynamic
>Update (?); if so, that's a design flaw).
When a DC is re-registering its SRV records (or a W2k workstation is
doing self-registration), the requests look like this, as I found from
some network snoop traces with W2000:
Send an unsigned DDNS request to the master server.
If the requested record is already in DNS, return OK;
nothing is done in DNS except update a refresh timer in the
record (for scavenging purposes). When W2k was first
introduced, the zone serial number was incremented, but I got
MS to stop that, as the zone has not changed.
If the requested record is not in DNS (and only secure updates are
allowed), then return REJECT, and expect the requestor to send
a signed DDNS packet.
I doubt that the logic has changed in W2003.
I have not bothered to report this "problem" to MS, because I was not
sure if it was a bug in the MS code. There are no bad effects from
this, as a full zone transfer does occur without problem after the
IXFR has failed.
More information about the bind-users