How Domain controllers are located in windows


How do servers locate a domain controller in a Network?

One of the first major tasks a domain member computer has to do when it starts is to locate a domain controller. Generally, this task requires the use of a Domain Name System (DNS) server, which contains records for each domain controller in the domain, and the Locator, a remote procedure call to the computer’s local Netlogon service.

Starting Up

When the computer starts, its Netlogon service starts automatically (in the default configuration). Th is service implements the DsGetDcName application programming interface (API), which is used to locate a domain controller.

The computer  begins  by collecting  a number  of pieces of information that  will be used  to  locate a domain controller. This information includes the client’s local IP address, which is used to determine the client’s Active Directory site membership, the desired domain name, and a DNS server address.

Finding the Domain Controllers

Netlogon then queries the configured DNS server. Netlogon retrieves the service resource (SRV) records and host (A) records from DNS that correspond to the domain controllers for the desired domain. The general form for the queried SRV records is _service._protocol.domainname, where service is the domain service, protocol is the TCP/IP protocol, and domainname is the desired Active Directory fully qualified domain name (FQDN). For example, because Active Directory is a Lightweight Directory Access Protocol (LDAP)-compliant directory service,  clients query for  _ldap._tcp.domainname  (or  _ldap._tcp.dc._msdcs.domainname when  locating  the nearest domain controller).

Each domain controller in a domain will register its host name with the SRV record, so the client’s query results will be a list of domain controller host names. The client also retrieves the associated A records, providing the client with the IP address of every domain controller in the domain. The client then sends an LDAP search query,  via  the  User  Datagram  Protocol  (UDP),  to  each  domain  controller.  Each  domain  controller  then responds, indicating that it is operational. The Netlogon service caches all of this information so that finding a domain controller in the future won’t require a repeat of this initial process. Instead, the service can simply refer to its cache to find another domain controller.

Selecting a Domain Controller

After the client locates a domain controller, the client uses LDAP to access Active Directory on a domain controller, preferably one in the client’s own subnet. The domain contro ller uses the client’s IP address to identify the client’s Active Directory site. If the domain controller is not in the closest site, then the domain controller returns the name of the client’s site, and the client tries to find a domain controller in tha t site by querying DNS. If the client has already attempted to find a domain controller in that site, then the client will continue using the current, nonoptima domain controller. Once the client finds a domain controller it likes, it caches that domain controller’s information, and the client will continue to use that domain controller for future contacts (unless the domain controller becomes unavailable).

For more details on troubleshooting please refer below KB article


For more article updates, videos and posters join our official page in Facebook

Facebook Page:

Web Site:

Video Channel:



AD integrated DNS and Security


DNS Scenario – AD Integrated DNS and Security

Your network consists of a single Active Directory domain. All domain controllers run Windows Server 2008 R2 and are configured as DNS servers. A domain controller named DC1 has a standard primary zone for contoso. com. A domain controller named DC2 has a standard secondary zone for

You need to ensure that the replication of the zone is encrypted. You must not lose any zone data.

What should you do?

A. Convert the primary zone into an Active Directory-integrated stub zone. Delete the secondary zone.

B. Convert the primary zone into an Active Directory-integrated zone. Delete the secondary zone.

C. Configure the zone transfer settings of the standard primary zone. Modify the Master Servers lists on the secondary zone.

D. On both servers, modify the interface that the DNS server listens on.

Correct Answer: B


All non-AD integrated DNS zones are saved in a text file i.e. .dns file and it is not encrypted

Scavenging Stale Records in DNS


DNS Scenario – Scavenging Stale Resource Records

You have a single Active Directory domain. All domain controllers run Windows Server 2008 and are configured as DNS servers. The domain contains one Active Directory-integrated DNS zone.

You need to ensure that outdated DNS records are automatically removed from the DNS zone. What should you do?

  1. From the properties of the zone, modify the TTL of the SOA record.
  2. From the properties of the zone, enable scavenging.
  3. From the command prompt, run ipconfig /flushdns.
  4. From the properties of the zone, disable dynamic updates.

Correct Answer: B


The DNS Server service supports aging and scavenging features. These features are provided as a mechanism for performing cleanup and removal of stale resource records, which can accumulate in zone data over time. You can use this procedure to set the aging and scavenging properties for a specific zone.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure.

To set aging and scavenging properties for a zone using the Windows interface

  • Open DNS Manager.
  • In the console tree, right-click the applicable zone, and then click Properties.
  • On the General tab, click Aging.

  • Select the Scavenge stale resource records check box.
  • Modify other aging and scavenging properties as needed.

To know more about Aging and Scavenging read this technet article –