DNS in Active Directory: The Service Locator That Everything Depends On

Blog 9 of "Mastering Active Directory — Simplified" and the first blog of Module 3. Modules 1 and 2 covered AD architecture, Windows authentication, NTLM, and Kerberos. Module 3 covers DNS, LDAP, and how AD clients find and communicate with services - the layer that enumeration and attacks operate through. Read in order for the best experience.

Active Directory does not work without DNS. Not "works better with DNS" or "performs well when DNS is configured correctly." It simply does not function. A Domain Controller with broken DNS is a Domain Controller that cannot be found, cannot authenticate users, and cannot replicate with other DCs. Every authentication request, every Kerberos ticket, every LDAP query, every Group Policy download starts with a DNS lookup.

This makes DNS one of the most important protocols to understand in any AD security discussion, both from an attack and a defense perspective. Attackers who understand how AD uses DNS can enumerate network topology, inject malicious records that redirect traffic, and set up credential capture scenarios that would not be possible without it. Defenders who understand AD DNS can detect those injections, monitor for suspicious record registrations, and lock down a default configuration that is surprisingly permissive.

This blog covers how Active Directory uses DNS, how clients find Domain Controllers, what AD-integrated DNS zones are, and why the default behavior that lets any authenticated user register DNS records creates a real and frequently exploited attack surface.

Why Active Directory Is Completely Dependent on DNS

When a Windows machine joins a domain, the first thing it needs to do is find a Domain Controller to authenticate against. It does not have the DC's IP address hardcoded anywhere. It finds the DC using DNS, specifically through a type of DNS record called an SRV record.

Before Kerberos can issue a ticket, the client needs to find the KDC. It queries DNS. Before a machine can download Group Policy, it needs to contact a DC. It queries DNS. Before two Domain Controllers can replicate with each other, they need to resolve each other's hostnames. DNS again.

Remove DNS from an Active Directory environment and the entire fabric collapses. Users cannot log in. Services cannot authenticate. Replication stops. This is not an exaggeration. It is the architectural reality, and it is why AD DNS is both critical infrastructure and a meaningful attack surface.

How Clients Find Domain Controllers: The DC Locator Process

The process a Windows client uses to find a Domain Controller is called DC Locator. It runs automatically whenever a machine needs to contact a DC, at startup, at login, and periodically during normal operation to ensure the client is still using an optimal DC. Understanding DC Locator step by step explains exactly which DNS records matter and why they need to exist.

When a client needs to find a DC, it constructs a DNS SRV query based on the domain name and the service it needs. For standard LDAP access to a DC in the same site, the query looks like this:

_ldap._tcp.dc._msdcs.<domainname>

_ldap._tcp.dc._msdcs.<domainname>

For finding a DC in a specific site:

_ldap._tcp.<sitename>._sites.dc._msdcs.<domainname>

_ldap._tcp.<sitename>._sites.dc._msdcs.<domainname>

For finding the PDC Emulator specifically:

_ldap._tcp.pdc._msdcs.<domainname>

_ldap._tcp.pdc._msdcs.<domainname>

The DNS server responds with one or more SRV records pointing to DCs that can handle the request. Each SRV record contains the hostname of the DC, a port number, and priority and weight values used to select between multiple DCs when several are available. The client picks the highest-priority response, resolves the hostname to an IP address using a standard A record query, and connects.

After connecting, the DC performs a Netlogon ping to confirm it can serve the client's domain and site. If the DC confirms it is suitable, the client caches that DC's details in the registry and uses it for subsequent requests. If not, the client tries the next SRV record in the response.

The entire process is automatic and invisible to end users. But for attackers and defenders, every step of it creates relevant data. The SRV records in DNS reveal every Domain Controller in the environment by hostname. The A records for those hostnames reveal their IP addresses. Site-specific SRV records reveal which DCs serve which network segments. All of this is queryable by anyone on the network with access to the DNS server.

AD-Integrated DNS Zones: Why AD DNS Is Different

Most organizations use Active Directory Integrated DNS zones rather than standard primary DNS zones, and this choice has security implications worth understanding.

A standard DNS zone stores its data in a flat zone file on the DNS server. Changes are made on a primary DNS server and replicated to secondary servers through zone transfers. Managing this in a large environment with multiple DNS servers requires manual coordination and creates potential inconsistencies.

AD-integrated DNS zones store their data directly inside Active Directory as objects in the domain naming context. This means DNS records replicate automatically alongside all other AD replication, using the same multi-master replication topology that keeps Domain Controllers synchronized. Any DC running the DNS role can accept changes and those changes replicate to every other DNS-capable DC in the domain.

The security implications split into two areas.

On the positive side, AD-integrated zones support fine-grained access control on DNS records through standard AD ACLs. Records can be restricted to specific users or groups. Secure dynamic updates can be enforced, meaning only authenticated domain accounts can register or update DNS records. Replication is encrypted and authenticated through the existing AD replication channel rather than relying on DNS-specific zone transfer security.

On the negative side, the default configuration of AD-integrated DNS is more permissive than most administrators realize, which leads directly to the attack surface discussed in the next section.

ADIDNS: The Default That Creates an Attack Surface

ADIDNS stands for Active Directory Integrated DNS. The specific behavior that creates a security concern is this: by default, any authenticated domain user can create new DNS records in an AD-integrated zone.

This is not a bug. It is a design decision made to support dynamic DNS registration. When a workstation joins the domain and gets an IP address from DHCP, it registers its own A record in DNS so other machines can find it by hostname. This self-registration requires write access to the DNS zone. Rather than granting each machine specific targeted permissions, the default configuration grants all authenticated users the ability to create new records in the zone.

The attack this enables is called ADIDNS record injection. An attacker with any valid domain user account can create a DNS A record pointing an arbitrary hostname to an IP address they control. If they choose a hostname that machines on the network are likely to query, such as a hostname referenced in scripts, configuration files, or network shares that does not currently have a DNS record, machines that query that hostname will receive the attacker's IP address in response and connect to it.

When those machines connect and attempt to authenticate, they use NTLM because they are connecting by IP address from their perspective after the DNS resolution. The NTLM authentication they send goes to the attacker. The attacker captures Net-NTLMv2 responses or relays them to other targets.

This is a highly reliable credential capture and relay setup. It does not require the attacker to be on the same network segment as the victim. It does not require poisoning live traffic. It requires only a valid domain user account and knowledge of a hostname that machines are likely to query but that does not currently resolve.

The technique is sometimes called DNS takeover or wildcard DNS abuse when used with a wildcard record that captures all unresolved queries in a domain. Inveigh and similar tools automate the detection of queryable hostnames and the injection of records.

DNS Record Types That Matter in Active Directory

Not all DNS record types are equally relevant in an AD context. These are the ones that come up during both normal operations and security assessments.

A records map hostnames to IPv4 addresses. Every Domain Controller, every domain-joined machine, and every domain service needs an A record. During enumeration, resolving A records for DC hostnames discovered through SRV records gives you IP addresses without needing to scan the network.

SRV records are the service location records that make DC Locator work. They follow the format described earlier and tell clients where to find specific services in the domain. Enumerating SRV records gives a complete picture of every DC and their roles.

PTR records provide reverse DNS lookups, mapping IP addresses back to hostnames. In AD environments, PTR records are often automatically created alongside A records. They are useful during enumeration when you have IP addresses and want to resolve them to hostnames without port scanning.

CNAME records are aliases pointing one hostname to another. They appear in AD environments for services accessed through friendly names that are redirected to actual server hostnames.

NS records identify which servers are authoritative for a DNS zone. In AD environments, NS records point to Domain Controllers running the DNS role. Enumerating NS records reveals which DCs are also DNS servers.

Defensive Controls Around AD DNS

Understanding the attack surface created by default AD DNS configuration is the first step. The defenses are specific and achievable.

The most impactful change is tightening the permissions on the DNS zone object in AD. Instead of allowing all authenticated users to create records, the zone ACL should be modified to allow only the DNSAdmins group and the Domain Controllers computer group to create new records. This removes the ability for arbitrary domain users to inject records while preserving the ability for machines to register their own records through the DC on their behalf.

Monitoring for unexpected DNS record creation is also valuable. Event ID 4662 on Domain Controllers captures object creation in AD when auditing is configured correctly, and new DNS record objects fall under this. A sudden burst of new DNS records created by a user account rather than a machine account or the DNS service itself is a meaningful detection signal.

Disabling LLMNR and NBT-NS as fallback name resolution protocols across the domain removes the companion attack surface that works alongside DNS injection. When both ADIDNS injection and LLMNR/NBT-NS poisoning are available, the attacker has multiple paths to the same outcome. Removing LLMNR and NBT-NS makes the environment depend entirely on DNS, which is both cleaner and more auditable.

A Real-World Scenario: DNS Enumeration to Credential Capture

A red team has gained a low-privileged domain user account through a phishing email. Before running any noisy tools, they start with passive DNS enumeration using the domain user's credentials against the DNS server.

They query the SRV records for the domain and get back four entries pointing to four Domain Controllers. They resolve the A records for each DC hostname and have four IP addresses. They query the NS records and confirm all four DCs are also running the DNS role. They query the PDC Emulator SRV record and identify which DC holds that FSMO role, making it the primary target for any authentication-focused attacks later.

With a complete DC inventory built entirely through DNS queries and no port scanning, no LDAP queries, no BloodHound collection, they move to the next phase.

They check the DNS zone for recently created records and find a hostname called backup-files that was registered three weeks ago by a user account rather than a machine account. The hostname points to a server IP that is no longer responding. They inject a new DNS A record for a different hostname, hr-portal, which they identified in an internal email attachment that referenced the URL but which currently returns NXDOMAIN when queried.

Within four hours, three machines have queried hr-portal.corp.local, received the attacker's IP, connected to the listener, and sent NTLM authentication. Two of the three Net-NTLMv2 responses crack overnight. One of the cracked accounts belongs to a member of the IT Helpdesk group. That is enough to start the next phase of the engagement.

The entire setup required a domain user account, a DNS query tool, and one injected record. No exploits, no scanners, no elevated privileges.

Cheat Sheet: AD DNS Quick Reference

Up Next

Blog 10 covers LDAP: what it is, why Active Directory uses it as its primary query interface, how LDAP Distinguished Names map onto the AD object hierarchy, the search filter syntax that enumeration tools use to query the directory, and what anonymous LDAP binds expose in environments where they are still permitted.

Follow the series on Medium to stay in order.

This blog is part of "Mastering Active Directory — Simplified" by w0lfstrong. Aligned with CRT-P, CRTP, red team engagements, and internal penetration testing. Read more at medium.com/@w0lfstrong