DNS and Active Directory: SRV Records, Dynamic Updates, and Spoofing Risks

1. Introduction

DNS is the nervous system of Active Directory. Domain controllers advertise their services through DNS, clients find DCs and the nearest logon server through DNS, and replication topology depends on correct name resolution. If DNS is wrong, authentication fails; if DNS is manipulated, authentication can be redirected. Because AD-integrated DNS also allows clients to register their own records dynamically, it introduces a class of spoofing and tampering risks that directly affect who a client trusts to authenticate it. DNS security is therefore inseparable from identity security.

2. How It Works

In most domains, DNS is AD-integrated: zones are stored in the directory and replicated with AD, so every DC can be a DNS server and records are multi-master. Clients rely on SRV records to discover services:

_ldap._tcp.dc._msdcs.corp.local     --> which hosts are Domain Controllers
_kerberos._tcp.corp.local           --> where to get Kerberos tickets
_gc._tcp.corp.local                 --> Global Catalog servers

Client boots --> queries SRV records --> picks a DC --> authenticates (Kerberos)

Dynamic DNS (DDNS) updates let domain-joined machines register and update their own A/PTR records. AD-integrated zones can require secure dynamic updates, so only the object that owns a record (or an authorised principal) can change it. DNS records are themselves AD objects (dnsNode) with their own ACLs.

3. The Security Problem

Several issues arise: (1) Insecure dynamic updates — if a zone allows unauthenticated updates, anyone on the network can create or overwrite records, redirecting traffic. (2) Record takeover — because the first machine to register a name often owns its record, an attacker can claim an unregistered but expected name (e.g. a wildcard or a service alias) and receive authentication attempts. (3) Weak name-resolution fallback (LLMNR/NBT-NS) that lets attackers answer for names DNS did not resolve. (4) Over-broad DNS admin rights — the DnsAdmins group and dnsNode ACLs can be powerful. Manipulating what a name resolves to can funnel Kerberos/NTLM authentication to an attacker-controlled host, feeding relay and coercion.

4. How Attackers Abuse It

Concept: An attacker who can add or overwrite a DNS record points a frequently-requested name at their host, then collects the authentication that clients send when they try to reach “the server”. Combined with missing SMB signing or LDAP channel binding, this becomes relay. Where DNS falls back to multicast (LLMNR/NBT-NS), the attacker simply answers the query. The through-line is the same as the NTLM/SMB articles: control the destination, capture the authentication.

In an authorized test, this is validated in a lab by registering a benign record and observing redirection; the finding is “insecure updates / missing hardening”, with remediation, not an attack on production name resolution.

5. How to Detect / Troubleshoot & Audit It

Command

Resolve-DnsName -Name _ldap._tcp.dc._msdcs.corp.local -Type SRV

What it does: Resolves the SRV record clients use to locate domain controllers.

What to look for: The returned targets should be exactly your known DCs. Any unexpected hostname is a red flag — a rogue or stale DC record.

Defensive use: Confirms DC discovery is not being redirected and that no unknown host advertises DC services.

Command

nslookup -type=SRV _kerberos._tcp.corp.local

What it does: Queries the Kerberos SRV records with the classic native tool.

What to look for: Only legitimate KDC hosts should appear; verify priorities/weights are sane and no foreign host is listed.

Defensive use: Cross-checks Kerberos service discovery during audits or incident response.

Command

Get-DnsServerZone | Select-Object ZoneName, ZoneType, IsDsIntegrated, DynamicUpdate

What it does: Lists DNS zones on a DC/DNS server and, crucially, each zone’s dynamic-update setting.

What to look for: DynamicUpdate = NonsecureAndSecure (or “Nonsecure”) on an AD zone — insecure updates that should be set to Secure only. IsDsIntegrated = False for a domain zone is also worth questioning.

Defensive use: Directly identifies zones accepting unauthenticated record changes.

Command

dcdiag /test:DNS /v

What it does: Runs the built-in DC diagnostic focused on DNS health (delegation, records, resolution, SRV registration).

What to look for: Failures in SRV registration or forwarders, and warnings about missing/duplicate records — both reliability and security signals.

Defensive use: A comprehensive health check that also surfaces misconfigurations attackers could exploit.

Command

repadmin /showrepl

What it does: Shows AD replication status between DCs (AD-integrated DNS replicates with AD, so replication health affects DNS consistency).

What to look for: Replication failures that could leave DNS records inconsistent across DCs, or an unexpected replication partner.

Defensive use: Confirms DNS/AD data is converging correctly and no rogue DC is participating.

6. How to Audit the Environment

• Confirm every AD-integrated zone requires secure dynamic updates.
• Validate SRV records (_ldap, _kerberos, _gc) resolve only to known DCs.
• Review membership of DnsAdmins and ACLs on sensitive dnsNode records.
• Check for wildcard records and stale entries that could be hijacked.
• Confirm LLMNR and NBT-NS are disabled to remove fallback spoofing.
• Verify forwarders point to trusted resolvers and that zone transfers are restricted.

7. How to Fix / Harden It

• Set all AD zones to Secure only dynamic updates.
• Disable LLMNR/NBT-NS via GPO.
• Tightly control DnsAdmins membership (it is a sensitive, historically abusable group) and audit dnsNode ACLs.
• Remove wildcard and stale records; enable scavenging with sane intervals.
• Restrict zone transfers to named servers; use trusted forwarders.
• Combine with SMB signing / LDAP channel binding so redirected authentication cannot be relayed.

8. Detection & Monitoring

• Enable DNS Server audit logging (Microsoft-Windows-DNSServer/Audit) — record create/delete/update events (e.g. Event IDs 515x/516x) to catch unexpected record changes.
• Event ID 5136 on dnsNode objects — ACL or record modifications in AD-integrated zones.
• Alert on new records pointing many clients to a non-DC host, or new hosts registering DC-style SRV records.
• Behavioural: spikes in name-resolution to a single new host; LLMNR/NBT-NS responses on the wire.

9. MITRE ATT&CK Mapping

Technique	ID
Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay	T1557.001
Adversary-in-the-Middle: DHCP/DNS Spoofing	T1557
Domain Trust / Remote System Discovery	T1018
Network Service Discovery	T1046

10. Practical Lab

In an isolated lab:

1. Use Get-DnsServerZone to find a zone set to NonsecureAndSecure, then switch it to Secure-only and confirm the change.
2. Validate SRV records with Resolve-DnsName and nslookup -type=SRV against your known DCs.
3. Enable DNS audit logging and observe events when you add/modify a test record.
4. Disable LLMNR/NBT-NS via GPO and confirm clients stop emitting multicast name queries.
5. Run dcdiag /test:DNS and repadmin /showrepl to establish a healthy baseline.

11. Key Takeaways

• DNS decides who a client authenticates to — tampering with it feeds relay and coercion.
• Require secure dynamic updates on all AD zones and disable LLMNR/NBT-NS fallback.
• Validate SRV records resolve only to known DCs; watch for rogue DC-style records.
• Control DnsAdmins and dnsNode ACLs; enable DNS audit logging for record changes.
• Resolve-DnsName, nslookup, dcdiag and repadmin are your first-line audit tools.

Continue learning: Active Directory security

This guide is part of our Active Directory Security series. Related guides:

• Active Directory ACLs and Attack Paths: How Small Permissions Become Domain Admin
• Group Policy Security: SYSVOL, GPO Permissions, and the cpassword Legacy
• Active Directory Delegation: Unconstrained, Constrained, and RBCD Risks