Active Directory DNS Failures: dcdiag, SRV Records, Scavenging, and Forwarder Fixes

DNS is the foundation of an Active Directory domain: every logon, LDAP bind, Kerberos ticket request, Group Policy refresh, and SYSVOL lookup begins with an SRV or host (A) record query. When a DC’s DNS goes bad, users do not see “DNS error” — they see logon failures, GPO processing taking 20 minutes, and printers disappearing. This guide covers the specific checks and repairs that resolve AD-integrated DNS problems on Windows Server 2022/2025, using dcdiag, Repadmin, DNSLint-style zone checks, and PowerShell DNS cmdlets. If you are standing up a fresh domain controller, the Windows Server hosting configurations we describe elsewhere include the static-IP and DNS-client settings you need before promotion.

Layer 1: The Domain Member’s DNS Client Configuration

Before touching the DNS server, prove the client resolves correctly. On every member server, the NIC must have exactly one or two DNS servers, both of which are domain controllers (or a DNS server that hosts an AD-integrated copy of the zone). The most common fault is a domain member whose DNS points at a public resolver such as 8.8.8.8 or 1.1.1.1 — SRV records for _ldap._tcp.dc._msdcs.contoso.com do not exist there.

• Run ipconfig /all and confirm the DNS servers listed are DC IPs.
• Check that no third-party VPN client or “smart DNS” shim has overwritten the interface DNS list.
• Clear the cache with ipconfig /flushdns, then ipconfig /registerdns.

From the member, resolve each of the following and confirm each returns a DC address, not a timeout:

• nslookup -type=SRV _ldap._tcp.dc._msdcs.contoso.com
• nslookup -type=SRV _kerberos._tcp.dc._msdcs.contoso.com
• nslookup -type=SRV _kpasswd._tcp.contoso.com
• nslookup -type=A dc01.contoso.com

If those resolve but logon is still slow, the fault is not resolution but the ordering of the returned DC list, which is covered in layer 3.

Layer 2: dcdiag and the Replication Health of the Zone

In an AD-integrated zone, the DNS data is replicated through the same directory partition that carries the domain objects. If replication is broken, a DC will answer queries with stale or missing records — it holds the zone but not the current contents.

Run on each DC, from an elevated prompt:

• dcdiag /test:dns /v /e — the verbose DNS test checks connectivity to the forwarder, AD-integrated zone presence, SRV record registration, and dynamic update capability for every DC in the enterprise. The summary section at the end lists PASS/FAIL/WARN per DC per category.
• dcdiag /test:advertising — confirms each DC is advertising itself in DNS for LDAP.
• repadmin /replsummary — shows largest delta and replication failures per DC pair.
• repadmin /showrepl — per-partition last replication success time.

A common pattern: dcdiag /test:dns reports “The DNS server did not record the SRV record” for a DC. That means netlogon registration failed. Fix it with:

net stop netlogon
net start netlogon

# Force immediate reregistration of all records
nltest /dsregdns
Get-DnsServerResourceRecord -ZoneName contoso.com | Measure-Object

# Verify SRV records are back
Resolve-DnsName -Name _ldap._tcp.dc._msdcs.contoso.com -Type SRV

The reasons netlogon fails to register are narrow: the DC’s NIC is pointing at a public DNS server or at itself in a way that produces a loop, the zone is not AD-integrated on that DC, or the DC has been unable to reach a writable DC to put the record in.

Layer 3: Zone Contents, Scavenging, and Stale Records

Duplicate A records are a classic cause of intermittent LDAP failures. When a DC is re-imaged or has its IP changed, the old A record can persist because dynamic update created it with a timestamp, but scavenging is not enabled.

• In DNS Manager, open the zone, choose Aging from the context menu, and confirm scavenging is enabled on both the zone and the server (Set-DnsServerScavenging).
• Check Get-DnsServerResourceRecord -ZoneName contoso.com -RRType A | Where-Object {$_.RecordData.IPv4Address -eq '10.0.0.15'} to find duplicates.
• Never delete the records of a live DC without stopping it first; instead, deregister from the DC itself with ipconfig /release + /renew or nltest /dsregdns.

Duplicate PTR records in the reverse zone are less damaging but slow nslookup and some application logging. Enable scavenging on the reverse zone as well.

Layer 4: Forwarders, Conditional Forwarders, and Root Hints

AD-integrated zones resolve the domain; everything else is forwarded. Misconfigured forwarders produce the infamous “3-second delay” on every web request from a server, because the DNS client retries each server in the list serially.

• Get-DnsServerForwarder — list the current forwarders. Use two or three public resolvers on different networks, or your ISP’s if the public ones are blocked.
• Get-DnsServerRootHint and Resolve-DnsName www.microsoft.com -Server 10.0.0.10 to time a forwarded query.
• Set the forwarder timeout and disable recursion correctly with Set-DnsServerForwarder -TimeOut 3.
• If the VPS provider filters outbound UDP/53 to public resolvers (increasingly common), the domain still resolves but the internet does not. Test with Test-NetConnection 8.8.8.8 -Port 53 and switch to the provider’s resolver or DNS over HTTPS via a local proxy if needed.

# Time forwarded resolution from a client
Measure-Command { Resolve-DnsName www.microsoft.com -Server dc01.contoso.com }

Anything above 200 ms for a single uncached query indicates a forwarder path with loss or a slow first hop. Compare against a query served from cache, which should be under 2 ms.

Layer 5: Client-Side Symptoms Mapped to Causes

Symptom	Likely cause	First command
Logon takes 60–120 s, then works	Member pointing at wrong DNS or a DC not advertising	dcdiag /test:advertising /v
GPO not applying to some machines	Stale/duplicate A record for a DC	Get-DnsServerResourceRecord
Intermittent “no logon servers available”	Replication delay between DCs	repadmin /replsummary
Every external lookup takes ~3 s	Dead forwarder in the list	Get-DnsServerForwarder
DNS event 4013 at boot	Zone loaded before AD is reachable — check AD connectivity first	dcdiag /test:connectivity

Prevention: What to Baseline

Record three values on a monthly cadence so a regression is visible the day it appears: the count of A/SRV records per DC, the result of dcdiag /test:dns /e, and forwarded query latency. Store the output as a file or into a SQL table via a scheduled task. When a DC is re-IPed, re-imaged, or a new one is promoted, rerun all five layers rather than the most convenient one.

If the domain is small — one or two DCs on a single host — the same checks apply, but you also need to keep the DNS service and the DC on separate uptime assumptions: a host reboot that brings the DC up before the network is routable will leave the zone unregistered until netlogon retries. A delayed start on the DNS service, or a scheduled nltest /dsregdns a minute after boot, closes that gap on the Windows Server environments we document, where virtual NICs can take several seconds to appear.