How Domain Controllers Are Located in Windows

This article describes the mechanism used by Windows to locate a domain controller in a Windows-based domain.

This article applies to Windows 2000. Support for Windows 2000 ends on July 13, 2010. The Windows 2000 End-of-Support Solution Center is a starting point for planning your migration strategy from Windows 2000. For more information, see the Microsoft Support Lifecycle Policy.

Original product version: В Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: В 247811

Summary

This article details the process of locating a domain by its DNS-style name and its flat-style (NetBIOS) name. The flat-style name is used for backward compatibility. In all other cases, DNS-style names should be used as a matter of policy. This article also addresses troubleshooting the domain controller location process.

More information

This sequence describes how the Locator finds a domain controller:

On the client (the computer that is locating the domain controller), the Locator is initiated as a remote procedure call (RPC) to the local Netlogon service. The Locator DsGetDcName application programming interface (API) call is implemented by the Netlogon service.

The client collects the information that is needed to select a domain controller and passes the information to the Netlogon service by using the DsGetDcName call.

The Netlogon service on the client uses the collected information to look up a domain controller for the specified domain in one of two ways:

For a DNS name, Netlogon queries DNS by using the IP/DNS-compatible Locator—that is, DsGetDcName calls the DnsQuery call to read the Service Resource (SRV) records and «A» records from DNS after it appends the domain name to the appropriate string that specifies the SRV records.

A workstation that is logging on to a Windows-based domain queries DNS for SRV records in the general form:

Active Directory servers offer the Lightweight Directory Access Protocol (LDAP) service over the TCP protocol. Therefore, clients find an LDAP server by querying DNS for a record of the form:

For a NetBIOS name, Netlogon performs domain controller discovery by using the Microsoft Windows NT version 4.0-compatible Locator (that is, by using the transport-specific mechanism (for example, WINS).

In Windows NT 4.0 and earlier, «discovery» is a process for locating a domain controller for authentication in either the primary domain or a trusted domain.

The Netlogon service sends a datagram to the computers that registered the name. For NetBIOS domain names, the datagram is implemented as a mailslot message. For DNS domain names, the datagram is implemented as an LDAP User Datagram Protocol (UDP) search. (UDP is the connectionless datagram transport protocol that is part of the TCP/IP protocol suite. TCP is a connection-oriented transport protocol.)

Each available domain controller responds to the datagram to indicate that it is currently operational and returns the information to DsGetDcName.

UDP allows a program on one computer to send a datagram to a program on another computer. UDP includes a protocol port number, which allows the sender to distinguish among multiple destinations (programs) on the remote computer.

• Each available domain controller responds to the datagram to indicate that it is currently operational and returns the information to DsGetDcName.
• The Netlogon service caches the domain controller information so that subsequent requests need not repeat the discovery process. Caching this information encourages consistent use of the same domain controller and a consistent view of Active Directory.

When a client logs on or joins the network, it must be able to locate a domain controller. The client sends a DNS Lookup query to DNS to find domain controllers, preferably in the client’s own subnet. Therefore, clients find a domain controller by querying DNS for a record of the form:

After the client locates a domain controller, it establishes communication by using LDAP to gain access to Active Directory. As part of that negotiation, the domain controller identifies which site the client is in based on the IP subnet of that client. If the client is communicating with a domain controller that is not in the closest (most optimal) site, the domain controller returns the name of the client’s site. If the client has already tried to find domain controllers in that site (for example, when the client sends a DNS Lookup query to DNS to find domain controllers in the client’s subnet), the client uses the domain controller that is not optimal. Otherwise, the client performs a site-specific DNS lookup again with the new optimal site name. The domain controller uses some of the directory service information for identifying sites and subnets.

After the client locates a domain controller, the domain controller entry is cached. If the domain controller is not in the optimal site, the client flushes the cache after fifteen minutes and discards the cache entry. It then attempts to find an optimal domain controller in the same site as the client.

After the client has established a communications path to the domain controller, it can establish the logon and authentication credentials and, if necessary for Windows-based computers, set up a secure channel. The client then is ready to perform normal queries and search for information against the directory.

The client establishes an LDAP connection to a domain controller to log on. The logon process uses Security Accounts Manager. Because the communications path uses the LDAP interface and the client is authenticated by a domain controller, the client account is verified and passed through Security Accounts Manager to the directory service agent, then to the database layer, and finally to the database in the Extensible Storage engine (ESE).

Troubleshooting the Domain Locator Process

To troubleshoot the domain locator process:

Check Event Viewer on both the client and the server. The event logs may contain error messages indicating that there is a problem. To view Event Viewer, click Start, point to Programs, point to Administrative Tools, and then click Event Viewer. Check the System log on both the client and the server. Also, check the Directory Service logs on the server and DNS logs on the DNS server.

Check the IP configuration by using the ipconfig /all command at a command prompt.

Use the Ping utility to verify network connectivity and name resolution. Ping both the IP address and the server name. You may also want to ping the domain name.

Use the Netdiag tool to determine whether networking components are working correctly. To send detailed output to a text file, use the following command:

netdiag /v >test.txt
Review the log file, looking for problems, and investigate any implicated components. This file also contains other network configuration details.

To fix minor problems, use the Netdiag tool with the following syntax: netdiag /fix .

Use the nltest /dsgetdc:domainname command to verify that a domain controller can be located for a specific domain.

Use the NSLookup tool to verify that DNS entries are correctly registered in DNS. Verify that the server host records and GUID SRV records can be resolved.

For example, to verify record registration, use the following commands:
nslookup servername. childofrootdomain. rootdomain.com
nslookup guid._msdcs. rootdomain.com

If either of these commands does not succeed, use one of the following methods to reregister records with DNS:

• To force host record registration, type ipconfig /registerdns.
• To force domain controller service registration, stop and start the Netlogon service.

To detect domain controller problems, run the DCdiag utility from a command prompt. The utility runs a number of tests to verify that a domain controller is running correctly. Use this command to send the results to a text file: dcdiag /v >dcdiag.txt

Use the Ldp.exe tool to connect and bind to the domain controller to verify appropriate LDAP connectivity.

If you suspect that a particular domain controller has problems, it may be helpful to turn on Netlogon debug logging. Use the NLTest utility by typing this command: nltest /dbflag:0x2000ffff . The information is then logged in the Debug folder in the Netlogon.log file.

If you still have not isolated the problem, use Network Monitor to monitor network traffic between the client and the domain controller.

References

For more information, see the Windows Resource Kit, Chapter 10, «Active Directory Diagnostic, Troubleshooting, and Recovery.»

Best practices for DNS client settings in Windows 2000 Server and in Windows Server 2003

This article describes best practices for the configuration of Domain Name System (DNS) client settings. The recommendations in this article are for the installation of Windows 2000 Server or Windows Server 2003 environments where there is no previously defined DNS infrastructure.

Original product version: В Windows Server 2012 R2
Original KB number: В 825036

Domain controller with DNS installed

On a domain controller that also acts as a DNS server, Microsoft recommends that you configure the domain controller’s DNS client settings according to these specifications:

If the server is the first and only domain controller that you install in the domain, and the server runs DNS, configure the DNS client settings to point to that first server’s IP address. For example, you must configure the DNS client settings to point to itself. Do not list any other DNS servers until you have another domain controller hosting DNS in that domain.

During the DCPromo process, you must configure additional domain controllers to point to another domain controller that is running DNS in their domain and site, and that hosts the namespace of the domain in which the new domain controller is installed. or if using a 3rd-party DNS to a DNS server that hosts the zone for that DC’s Active Directory domain. Do not configure the domain controller to utilize its own DNS service for name resolution until you have verified that both inbound and outbound Active Directory replication is functioning and up to date. Failure to do so may result in DNS «Islands».
For more information about a related topic, click the following article number to view the article in the Microsoft Knowledge Base:

275278 DNS Server becomes an island when a domain controller points to itself for the _msdcs.ForestDnsName domain

After you’ve verified that replication has completed successfully, DNS may be configured on each Domain Controller in either of two ways, depending on the requirements of the environment. The configuration options are:

• Configure the Preferred DNS server in TCP/IP properties on each Domain Controller to use itself as Primary DNS Server.
  • Advantages: Ensures that DNS queries originating from the Domain Controller will be resolved locally if possible. Will minimize impact of Domain Controller’s DNS queries on the network.
  • Disadvantages: Dependent on Active Directory replication to ensure that DNS zone is up to date. Lengthy replication failures may result in an incomplete set of entries in the zone.
• Configure all Domain Controllers to use a centralized DNS server as their Preferred DNS Server.
  • Advantages:
    • Minimizes the reliance on Active Directory replication for DNS zone updates of Domain Controller locator records. It includes faster discovery of new or updated Domain Controller locator records, as replication lag time isn’t an issue.
    • Provides a single authoritative DNS server, which may be useful when troubleshooting Active Directory replication issues
  • Disadvantages:
    • Will more heavily use the network to resolve DNS queries originating from the Domain Controller
    • DNS name resolution may depend on network stability. Loss of connectivity to the Preferred DNS server will result in failure to resolve DNS queries from the Domain Controller. It may result in apparent loss of connectivity, even to locations that aren’t across the lost network segment.

A combination of the two strategies is possible, with the remote DNS server set as Preferred DNS server, and the local Domain Controller set as Alternate (or vice versa). While this strategy has many advantages, there are factors that should be considered before making this configuration change:

• The DNS client does not utilize each of the DNS servers listed in TCP/IP configuration for each query. By default, on startup the DNS client will attempt to use the server in the Preferred DNS server entry. If this server fails to respond for any reason, the DNS client will switch to the server listed in the alternate DNS server entry. The DNS client will continue to use this alternate DNS server until:
  • It fails to respond to a DNS query, or:
  • The ServerPriorityTimeLimit value is reached (15 minutes by default).

Only a failure to respond will cause the DNS client to switch Preferred DNS servers; receiving an authoritative but incorrect response does not cause the DNS client to try another server. As a result, configuring a Domain Controller with itself and another DNS server as Preferred and Alternate servers helps to ensure that a response is received, but it does not guarantee accuracy of that response. DNS record update failures on either of the servers may result in an inconsistent name resolution experience.

• Don’t configure the DNS client settings on the domain controllers to point to DNS servers of your Internet Service Provider (ISP). If you configure the DNS client settings to point to your ISP’s DNS servers, the Netlogon service on the domain controllers doesn’t register the correct records for the Active Directory directory service. With these records, other domain controllers and computers can find Active Directory-related information. The domain controller must register its records with its own DNS server.

To forward external DNS requests, add the ISP’s DNS servers as DNS forwarders in the DNS management console. If you don’t configure forwarders, use the default root hints servers. In both cases, if you want the internal DNS server to forward to an Internet DNS server, you also must delete the root «.» (also known as «dot») zone in the DNS management console in the Forward Lookup Zones folder.

• If the domain controller that hosts DNS has several network adapters installed, you must disable one adapter for DNS name registration.

For more information about how to configure DNS correctly in this situation, click the following article number to view the article in the Microsoft Knowledge Base:

292822 Name resolution and connectivity issues on a Routing and Remote Access Server that also runs DNS or WINS

To verify your domain controller’s DNS client settings, type the following command at a command prompt to view the details of your Internet Protocol (IP) configuration: ipconfig /all
To modify the domain controller’s DNS client configuration, follow these steps:

Right-click My Network Places, and then select Properties.

Right-click Local Area Connection, and then select Properties.

Select Internet Protocol (TCP/IP), and then select Properties.

Select Advanced, and then select the DNS tab. To configure the DNS information, follow these steps:

1. In the DNS server addresses, in order of use box, add the recommended DNS server addresses.
2. If the For resolution of unqualified names setting is set to Append these DNS suffixes (in order), Microsoft recommends that you list the Active Directory DNS domain name first (at the top).
3. Verify that the DNS Suffix for this connection setting is the same as the Active Directory domain name.
4. Verify that the Register this connection’s addresses in DNS check box is selected.
5. Select OK three times.

If you change any DNS client settings, you must clear the DNS resolver cache and register the DNS resource records. To clear the DNS resolver cache, type the following command at a command prompt: ipconfig /flushdns
To register the DNS resource records, type the following command at a command prompt: ipconfig /registerdns

To confirm that the DNS records are correct in the DNS database, start the DNS management console. There should be a host record for the computer name. (This host record is an «A» record in Advanced view.) There also should be a Start of Authority (SOA) record and a Name Server (NS) record that points to the domain controller.

Domain controller without DNS installed

If you do not use Active Directory-integrated DNS, and you have domain controllers that do not have DNS installed, Microsoft recommends that you configure the DNS client settings according to these specifications:

• Configure the DNS client settings on the domain controller to point to a DNS server that’s authoritative for the zone that corresponds to the domain where the computer is a member. A local primary and secondary DNS server is preferred because of Wide Area Network (WAN) traffic considerations.
• If there’s no local DNS server available, point to a DNS server that’s reachable by a reliable WAN link. Up-time and bandwidth determine reliability.
• Don’t configure the DNS client settings on the domain controllers to point to your ISP’s DNS servers. Instead, the internal DNS server should forward to the ISP’s DNS servers to resolve external names.

Windows 2000 Server and Windows Server 2003 member servers

On Windows 2000 Server and Windows Server 2003 member servers, Microsoft recommends that you configure the DNS client settings according to these specifications:

• Configure the primary and secondary DNS client settings to point to local primary and secondary DNS servers (if local DNS servers are available) that host the DNS zone for the computer’s Active Directory domain.
• If there are no local DNS servers available, point to a DNS server for that computer’s Active Directory domain that can be reached through a reliable WAN link. Up-time and bandwidth determine reliability.
• Don’t configure the client DNS settings to point to your ISP’s DNS servers. If you do so, you may experience issues when you try to join the Windows 2000-based or Windows Server 2003-based server to the domain, or when you try to log on to the domain from that computer. Instead, the internal DNS server should forward to the ISP’s DNS servers to resolve external names.