How Domain Controllers Are Located in Windows

Overview[1] #

How Domain Controllers Are Located in Windows describes the Discovery Mechanism used by Windows to locate a Domain Controller in a Microsoft Active Directory based AD DOMAIN.

Ldapwiki provide the How To details of the process of locating a domain by its DNS-style name vs the its flat-style (NetBIOS) name.

Ldapwiki also have some details on Getting information on Domain Controllers.

The Sequence #

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 an remote procedure call (RPC) to the local Netlogon service. The Locator DsGetDcName Application Programming Interface (API) call is implemented by the Netlogon service.

The Netlogon service on the client uses the collected information to look up a Domain Controller for the specified domain.

For a Domain Name System (DNS) name, Netlogon service 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 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 (ie Domain Controller) by querying DNS SRV Records for a record of the form:


When a client logs on or joins the network, it must be able to locate a domain controller. Therefore, clients find a Domain Controller by querying DNS for a record of the form:


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. After the client locates a domain controller, the Domain Controller entry is cached.

After the client locates a Domain Controller, it establishes communication by using LDAP to gain access to Microsoft Active Directory. The client establishes an LDAP connection to the Domain Controller using a LDAP ping and retrieves the Netlogon attribute. The Client determines if the Domain Controller is appropriate for starting the Windows Logon using the Windows Client Authentication Architecture

Active Directory Site #

As part of the negotiation, the Domain Controller identifies which Active Directory Site of 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 closet (most optimal) site, the Domain Controller returns the name of the client's site (ClientSiteName). 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 ClientSiteName. The Domain Controller uses some of the directory service information for identifying sites and subnets.

NOTE: A client does not know and does not determine which site is to be used. The Active Directory Site information is provided by the Domain Controller and the client writes the information to the client's registry for future reference.

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 Active Directory Site as the client.

More Information #

There might be more information for this subject on one of the following: