A practical approach to Active Directory Domain Services, Part 2: Active Directory and the Domain Name System

For readers who have returned to this blog after understanding the basics of Active Directory (AD) in part 1 of this series, welcome back!

For all new readers: Hello! Get ready to jump into the world of AD. It would be good to take a quick peek at what was covered in Part 1 before you continue. Be sure to read through part 1 as it will be your guide to:

• The fundamentals of AD.

• Some basic AD definitions.

• The benefits any enterprise can get from having an AD setup.

 Part 2 of this series aims to introduce the interrelation of AD with the Domain Name System (DNS).

 What is DNS?

DNS, in a general sense, is a means to resolve the host or domain names into the corresponding IP addresses.

In the context of AD, the DNS service maintains a working namespace of DNS domains and subdomains that primarily help in the lookup process. It helps identify and find the various resources in any private AD environment.

DNS servers function cohesively in AD domains and sites to enable name resolution of users and computers, among other functionalities. In most cases, no single DNS server can perform all the essential services, so DNS servers are logically grouped together in a hierarchical network to enable seamless DNS servicing in AD networks.

 How does AD use the services of DNS? 

 AD’s dependency on DNS can be understood through the following topics:

• DC locator process

• DNS resource records

• DNS zones and zone files

• DNS and LDAP

 DC locator process

A domain controller (DC) is the primary authentication and authorization server in an AD environment. It is the server that has the AD DS server role installed.

To use the core services of AD—i.e., to look up, authenticate, and authorize user accesses and modify any AD object, such as users, groups, or computers—DNS servers are utilized to “locate” the DCs available in the respective AD sites.

Here is a brief description of how DCs are located: 

• The DNS protocol, which is part of the application layer of the TCP/IP protocol suite, is used to locate and contact the nearest DC.

• The client computer sends a DNS query to the DNS server for DNS resolution. The DNS server is identified using the TCP/IP configuration settings on the client computer.

• The DNS server responds to this request with the list of DNS records that match the request. It usually contains the list of all DCs available in the requested domain.

• The client computer validates this response (called a SRV record, which is explained in the next section) and selects one DC based on the priority and weight assigned to the record.

• The client sends out a second DNS query, requesting the DNS server provide the IP address of the selected DC.

• The DNS server checks the A record (also explained in the next section) and responds to the client request with the corresponding IP address.

• With this information, the client contacts the DC and initiates the communication.

DNS resource records

The DNS server is responsible for maintaining various types of data records in the DNS database.

Of the many resource records saved in the DNS database, for the DC locator process, service location records (SRV records) are of prime importance.

As introduced briefly in the section above on the DC locator process, the client computer sorts through multiple SRV records provided by the DNS server as a response to its first DNS query. Each record has an associated server hostname potentially offering the service required by the client.

There may be a case where multiple SRV records, from across all AD sites, are offered to a client at any given domain for a required service. In such cases, the weight and priority information associated with each service record is checked, and the record with a lower priority assigned to it is chosen.

For records with the same priority, the one with a lower relative weight is selected to allow for load balancing by administrators.

The client computer uses the host server name associated with this selected SRV record to proceed with the next step of obtaining the IP address of the chosen DC.

Once a suitable DC has been selected, a second DNS query from the client computer requests for an A record (host record) to be sent by the DNS server with the IP information of the selected DC. Thus, A records are the other crucial resource records maintained by DNS for the DC locator process.

DNS zones and zone files

SRV records and A records are not the only resource records maintained on the DNS server. There are nearly 90 official resource records stored in the DNS server database, of which many are beneficial for AD functionalities as well. Before any other resource records are introduced here, it will come in handy to learn about DNS zones and zone files so you understand how the records are stored in the server.

DNS zones are administrative derivatives of the DNS namespace that are managed and controlled by the AD administrator, and they are used to store and replicate modifiable DNS data. Active Directory-integrated DNS zones are sections of the AD database directory partition called the application partition.

In the physical sense, these zones contain data or DNS-related information in the form of text files, or “zone” files. DNS data records for the domains and subdomains represented by the DNS zone are stored on these text files.

In the logical AD architecture, these zones represent groups of container objects with multiple other AD objects contained within them. Every unique name stored in AD is identified by a unique DNS node object. DNS records are multi-valued attributes assigned to these objects.

DNS zones may be categorized as:

• Primary zones that store the master copies of zone data.

• Secondary zones that store a read-only copy of zone data.

• Stub zones containing only limited resource records to identify authoritative servers.

• AD-DNS integrated zones that have DNS data stored in the AD database and use AD’s replication model to modify DNS data on any particular DC and thus have it reflected across all the DCs in the AD forest.

 In conclusion, the DC locator process, DNS resource records, and DNS zones and zone files are linked in the following manner: 

• Consider the DNS server role installed on the DC in a sample AD environment, ad.practice.com.

• Two AD-integrated primary DNS zones are created. These are called forward lookup zones.

• In the case of the above-mentioned sample AD setup, two forward lookup zones get created by default, namely _msdcs.ad.practice.com and ad.practice.com. Both are created in the application partition of the AD directory database.

• These zones contain information in the form of resource records that enable many AD-DNS functionalities, including the DC locator process, identification of AD sites, and name resolution during object search.

• These zone files have multiple types of resource records. The SRV records used in the DC locator process are found in these zone files to locate DCs that offer services like the Netlogon service.

• The other important records used are the A records, which are host records that contain the IP address of the selected DC and are sent as a response by any client computer as a DNS query.

• Canonical name records, or CNAME records, are other important records maintained in the zone files. Aliases for servers and other connected network resources such as printers can be set up as a substitution of another domain or hostname.

More on how AD data is retrieved and modified is discussed next. This section is solely to understand how the Lightweight Directory Access Protocol (LDAP) is used to communicate with AD services and how LDAP is dependent on DNS.

DNS and LDAP

Every AD object is identified by unique naming standards.

The resolution of these distinguished names (DNs) to IP addresses takes place with the help of LDAP. This protocol is used in AD environments to search for each of the AD objects and modify or manage communication with the directory service without necessarily knowing the exact location or the IP address of the resources. This is possible because of the integration of AD services with DNS.

The LDAP authentication process uses DNS entries stored in the LDAP server database, which is called the directory system agent, or DSA. In two stages of authentication, the DN and then the password are resolved and verified. If the provided credentials match those stored in the LDAP database, the server authenticates and authorizes the user to access the various network resources.

You can see that the interdependencies of AD on DNS are quite extensive. The workings of AD are built exhaustively on the DNS framework. The sections above highlight some of the areas of this interrelationship in practical terms, but you can study this topic even further.

DNS data is highly prone to security threats. AD-integrated DNS zones are susceptible to various security infiltration attempts. Denial-of-service attacks, DNS spoofing, and DNS hijacking are some of the many ways that cyberattackers compromise an organization’s DNS server. Active Directory should be monitored carefully, and the AD-DNS integration should be carried out effectively to ensure security. An attack on AD-DNS architecture, if not prevented or at least effectively managed, can be severely detrimental to an organization’s security posture.