Reject of W2K gc._msdcs...

Tim Maestas tmaestas at
Thu Mar 2 05:09:31 UTC 2000

> Distributing the Forest Wide Locator Records
> Each domain controller in the forest registers two sets of locator records:
> a set of domain-specific records that end in <DNS-domain-name>, and a set of
> forest-wide records that end in _msdcs.<DNS-forest-name>. The forest-wide
> records are interesting to clients and domain controllers from all parts of
> the forest. For example, the global catalog locator records, and the records
> used by the replication system to locate replication partners, are included
> in the forest-wide records.

Craig, one thing to keep in mind is the root of your AD Forest.  In the
example I gave you, if is the root of your forest, and is a child domain of, the DC's in will attempt to dynamically update records into (not as many as they put into, but a few
nonetheless) for the reasons stated by Microsoft above (being able to
locate the global catalogue server, among other things). In this case, the
Win2k DC's will need to be allow-update'd in as well as sales. In the setup I have done, and
are both served off of the same bind server.  I'm not sure what would
happen if they are on seperate servers. Presumebly, the DC's would get the
SOA record for and attempt to update to the server in the
MNAME field (the server name that comes after @ IN SOA).  This is why it
is important that the servername in that field is correct, otherwise the
clients have no way to find out who is the master server for a given
domain.  If MS implements this lookup on the client side correctly, there
should be no problem, but since I'm serving both zones off the same
server, I can't speak from experience.

BTW, does anyone know when the Dynamic Update Bugs mentioned in the
INSTALL file of the BIND 8.2.2-p5 source will be fixed? (Specifically the
ability to update to slaves, which would then propogate to masters, and
the destroying delgation to child domains bug.)


More information about the bind-users mailing list