Windows/BIND integration [was: Combined master + forward zone]

[Michael Milligan]

> and Michael Milligan <milli at acmeps.com> replied:
>> And don't forget to set a group policy on all DCs to not update the A
>> records in the apex zone.  Otherwise the DCs will complain in the Event
>> logs forever... this assumes the BIND servers are authoritative for
>> example.com, in this example.
>>
>> See http://support.microsoft.com/kb/246804 for Windows 2000
>>
>> See http://support.microsoft.com/kb/267855 for Windows 2003 and later,
>> specifically under "Netlogon fix" and tell it not to register the
>> LdapIPAddress.
>>
>> (There is also more information there on preventing all the DCs from
>> creating NS records in the zone, which becomes problematic when there
>> are more than about 10 DCs.  I had one customer with 100s of DCs, and
>> each one put in an NS record in the zone for itself...  ugh.  With a
>> little magic, dropped that back to a handful of DCs at big data centers.)
> 
> 
> It is not as simple as that.  There are a number of Windows registry
> setting in this area;

Actually, it is, for Windows 2003 SP2 and later...

All these registry settings come from various Windows 2000 and 2003 SPs,
and are in my opinion the result of several failed attempts to "get it
right".  They have made a mess of things at this point.  But I'm glad
what you have is (mostly) working for you.

If you run Windows 2003 SP2 or later, the best solution I have found is
to ignore all the earlier registry hacking you referenced and leave them
all at their default settings.  The only two things you generally need
to change in the scenario outlined is to tell the DCs not to add their
own IPs as A records at the apex domain (example.com), which as outlined
in KB2678555, is controlled by adding a new REG_MULTI_SZ registry key
DnsAvoidRegisterRecords with the string "LdapIpAddress" in it, and then
if you have more than 10 DCs, tell all of the DCs which DCs can register
NS records for which zones.  This is to keep the NS record set under
about 10 (which goes back to DNS payload size... keep it under 512
bytes).  That's done using dnscmd.exe with the
/AllowNSRecordsAutoCreation switch and a list of IPs, per zone, also as
outlined in KB2678555.

Microsoft tries too hard to make it (too) easy, don't they?

As a quick aside, the NS record set size problem does not often come up
as an issue since the Microsoft DCs (also running DNS) are in most cases
used as the resolving infrastructure for internal clients and Microsoft
documentation encourages admins to AD-integrate zones and replicate to
*every* DC, thus the NS record set size isn't an issue.  But it will
cause problems (i.e., TCP connections and thus higher load) if/when you
try to scale it better or add other non-MS DNS servers to the resolving
infrastructure or otherwise have to talk to the MS servers to resolve
names.  It's also an issue if you try to move DNS off Microsoft.

But the iceberg is even bigger, and gets off topic (DHCP).

> is a BIND forum, not a MS forum):

I apologize as well, but reply anyway for completeness.  It's all DNS
after all and problems we all likely have to deal with.  :-/

Regards,
Mike

-- 
Michael Milligan                                   -> milli at acmeps.com