One of the most important uses of DNS in an Active Directory environment is that of locating domain controllers. Remember that one of the goals of moving to a DNS-based name resolution process was to reduce or eliminate our dependence on NetBIOS broadcast technology. On a network that consists of only Windows 2000/Windows Server 2003 (or newer) computers, NetBIOS and WINS traffic can be completely eliminated.
Since finding a domain controller is critical to the process of logging in, let's take a closer look at the process.
1. First, the client runs a process called the Locator, which initiates a DsGetDcName query at the local Netlogon service. This is done through a Remote Procedure Call (RPC) that passes information about the client's configuration (domain membership and IP configuration) to the Netlogon service.
2. The Netlogon service uses this information to look up a domain controller for the specified domain. This can be done in a couple of different ways, depending upon the type of name submitted—DNS or NetBIOS.
♦ If the name presented to the Netlogon process is a NetBIOS name, the older name resolution process is used. This allows backwards compatibility in environments that have not yet upgraded to Active Directory. In this case, either a broadcast is performed or, if configured, a WINS server is queried. In either event, this is not the process we prefer—remember, we're trying to get rid of NetBIOS-based procedures!
♦ If the name presented to the Netlogon process is a DNS host name, then the Netlogon service queries the DNS server for SRV and A records for the appropriate domain. The query takes the following format:
♦ Since Active Directory services utilize the Lightweight Directory Access Protocol (LDAP) services over TCP, the query identifies that service and protocol:
3. After receiving a list of domain controllers from the DNS server, the Netlogon service sends a datagram to each domain controller.
4. The domain controllers respond by sending their operational status to the Netlogon service on the client computer. This information is cached by the Netlogon service so that the process will not be required on subsequent requests. (This helps to ensure the consistent use of the same domain controller.)
5. The client establishes an LDAP session with a domain controller. As part of that process, the domain controller identifies which AD site the computer belongs to (based upon the IP subnet of the client). If the domain controller is in the same site as the client, authentication begins. If not, the client again queries DNS, looking for a domain controller in its site. That query follows the format:
The bottom line here is that the client uses DNS to find a list of domain controllers for its domain. Part of the process attempts to locate a domain controller "near" the client, using AD site information (which is based upon IP subnetting). Once an appropriate domain controller has been located, communication has been established, and any secure channels have been created, the logon and authentication processes can begin.
Was this article helpful?