Origin of _ldap._tcp._msdcs.DNSDomainName?

  • Thread starter Thread starter Pat Coghlan
  • Start date Start date
P

Pat Coghlan

Our WinXP workstations are able to join every domain in our enterprise
except for one (domain X). Attempts to join domain X result in the
"cannot find a domain controller for the domain" error.

The help screen states that an SRV record must exist on the DNS server
called _ldap._tcp._msdcs.DNSDomainName. I can nslookup this name for
the other domains, but the lookup fails for domain X.

Why would this record be missing in the case of domain X? Do the DCs
write this to the DNS server, or is this something that needs to be
manually added?

If the DCs write it to the DNS server, how can I check whether they have
write access?
 
Why would this record be missing in the case of domain X? Do the DCs
write this to the DNS server, or is this something that needs to be
manually added?
Click to expand...


By pointing the DNS server to itself for DNS (in the properties of TCP/IP)
these records are created automatically during logon. If the DNS server is
not pointed to itself for DNS these records will not be created in DNS.
If the DC is not pointed to the AD DNS server the proper SRV records are not
registered on the DNS server. Not finding the SRV records for the domain
will cause a client to give the "cannot find domain" error. If the AD DC is
the same server as the AD DNS server, point it to itself for DNS.

The most common cause of this is users point their DNS server to their ISP's
DNS server instead of pointing it to itself.
If the DCs write it to the DNS server, how can I check whether they have
write access?
Click to expand...

See:
How to verify that SRV DNS records have been created for a domain controller

http://support.microsoft.com/default.aspx?scid=kb;en-us;816587

hth
DDS W 2k MVP MCSE
 
Nslookup tells me that domain X is a non-existent domain.

Essentially, we have 4 domains in our enterprise, and all DCs point to a
master DNS server. Workstations can join three of the domains, but not
domain X.

Clearly, some critical information for domain X is missing from the
master DNS server, but how can this be, given that all DCs - including
the one for domain X - are pointed at the master DNS server?

I believe DNS is still configured on the DC for domain X, but is not
selected as the preferred DNS server by any DC or workstation. Could
the existence of the DNS service itself be causing a problem?

I know that the DCs need write access to the master DNS server, and I
suspect that the DCs for domain X might not be on the list of servers
authorized to have write access, but our IT people tell me that they are
on the list. I have no way to verify this, though.

-Pat
 
Nslookup tells me that domain X is a non-existent domain

That's a red herring -that just means there's no reverse lookup zone -no big
deal.

Ensure that the DCs have the DHCP Client service running, are pointing to
the correct DNS servers and are configured to register in DNS. Then restart
NETLOGON.

The other problem could be that DNS is fine on the server but the clients
aren't pointing to the DNS server or are but don't have the correct DNS
suffix search list.

nltest /dsgetdc:domain-name.com
nslookup -type=srv _ldap._tcp.dc._msdcs.domain-name.com
netdiag /test:dns /d:domain-name.com

These are tests that will help you troubleshoot this.

Check the dynamic update status of the DNS and the domain that that DNS
server is in in relation to these DCs too (if it's secure only).
 
ptwilliams said:
Ensure that the DCs have the DHCP Client service running,
are pointing to the correct DNS servers and are configured
to register in DNS.
Click to expand...
Is that a good idea, Paul? I've always configured DCs with
static addresses, on the grounds that if a server ever
changes its IP address you'll have problems.

Or maybe I'm missing the point. Are you saying that the
*service* should be running, even if the *NICs* have their
IPs statically configured?

I just want to understand what you mean by this! <grin>

Cheers,

Cliff
 
Or maybe I'm missing the point. Are you saying that the *service* should
be running, even if the *NICs* have their IPs statically configured?
Click to expand...

Yes, that's exactly what I'm saying. The DHCP Client service is responsible
for the dynamic DNS registrations. NETLOGON uses the DHCP Client service to
do the registrations. If the service isn't running, the DCs won't be able
to register and then reregister the different RRs at their specified
intervals.
 
DHCP was not installed on the DC, but the service was running. Not sure
how that can be.
Click to expand...

There are two components to DHCP - Client and Server. In this instance we
are talking about the client service -not the server. The client is part of
all Windows machines and is needed to register records in DNS.

I'm not sure if this is the culprit though. The application log contains
messages from NETLOGON that no DNS servers are available, even after I
configure/authorize DHCP using the wizard. Since all DCs are using the
same master DNS server, I suspect the root cause to be one of the
following:
Click to expand...

- write access has not been granted to the DCs by the master DNS server
- network problem, such as required TCP port not being open


The fact that the _ldap._tcp.dc._msdcs.domain-name.com query fails means
that the DCs are not registering in DNS. This is the problem and the other
support tools (which you will find under \SUPPORT on your Windows/ SP CD)
will tell you the same (and more).

Ensure that the DNS zone is configured to accept dynamic updates, that the
necessary ports are open, that the DHCP **CLIENT** service is running and
that the clients are configured to register with DNS (DNS TCP/IP client
settings) and restart NETLOGON.

Or you can run netdiag /fix.

Out of curiosity, what TCP port number is used for DNS registrations?
Click to expand...

53 (UDP and TCP. UDP for queries and TCP for zone transfers and large
queries).
 
Back
Top