Monitoring Zonefiletransfer

Tue Feb 25 22:35:31 UTC 2014

Hmmm, so that explains what I'm seeing in my logs of my nameservers
getting hammered by AD.

Should I be worried?  Is there anything that could be done on my end to
help reduce the impact?

----

On our campus, we have always allowed delegation of subdomains to
department nameservers, with the requirement that we be secondary to
them.  Some departments also have other domains on their nameservers,
again have us as their secondary (and often we're the only published
nameservers for these domains.)

But, AD was different...they did their own thing.

Except there's this problem now with their authoritative servers also
being open recursive query resolvers ... exposed to the whole world.

Since they won't turn off recursion (and there's no way to limit its scope)

So, we've started pushing that they need to use us as secondaries.

Right now it has only been tested with Central AD, where I'm seeing one
DC sending updates ranging from a few minutes to a few hours.  While the
other DC is trying at intervals of 2-9 minutes, but its N-1....

Though when they were first trying to get it going...they had some
trouble, which turned out that it thought the IP space of my nameservers
belonged to it and that my nameservers were not part that space.

Namely, one of my DNS vlans is 129.130.254.0/28 (ns-1.ksu.edu lives
here, ns-2.ksu.edu/ns-3.ksu.edu live in the other one)...where some
other portion of the /24 is a vlan that they have servers in.

Hmmm, I noticed in the dump of ads.ksu.edu, it has A records for my
nameservers....is that a problem?

On 02/25/14 03:10, Markus Weber wrote:
> Hey guys,
> 
> sorry for the delay, i urgently had to take some days off last week.
> Anyways, thanks for all your help, i appreciate this a lot.
> 
> I will now try to use only one DC as a master.
> a last question, Do you also run monitoring software on bind? and if so,
> what or how do you monitor?
> 
> 
> 
> Am 19.02.2014, 20:33 Uhr, schrieb Barry S. Finkel <bsfinkel at att.net>:
> 
>>> 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
>> _______________________________________________
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>>
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator
For: Enterprise Server Technologies (EST) -- & SafeZone Ally