Windows Server DNS Troubleshooting: Complete Checklist

Run these from an affected client first, then from the DNS server itself. The pattern tells you where to look.

# From the client
Resolve-DnsName problem-host.contoso.com
Resolve-DnsName problem-host.contoso.com -Server 10.0.0.10   # query a specific DNS server directly

# From the DNS server
Get-DnsServer
Get-Service DNS

• Fails from client, works when querying the DNS server directly — client-side resolver or network path issue, not the DNS server itself.
• Fails everywhere, including on the server — the DNS service, zone, or record is the problem.
• Works for some records, fails for others — likely a specific missing or stale record, not a service-wide outage.

Get-Service DNS | Select-Object Status, StartType
Get-WinEvent -LogName "DNS Server" -MaxEvents 50 | Where-Object LevelDisplayName -in "Error","Warning"

Common entries to look for:

• Event ID 4013/4015 — the DNS server failed to load a zone. Usually a corrupt zone file or an AD replication issue if the zone is AD-integrated.
• Event ID 6527 — the server can't bind to an IP address, often because another process, or a second NIC, is holding port 53.
• Event ID 708 — the server couldn't open the zone's Active Directory partition. Check AD replication health with repadmin /replsummary.

If the service is stopped, don't just restart it blindly — check why it stopped first (crash dump, resource exhaustion, disk full on the zone file volume) or you'll be back here in an hour.

Get-DnsServerResourceRecord -ZoneName "contoso.com" -Name "problem-host"

Things that commonly go wrong here:

• Stale record from DHCP-registered dynamic DNS. If a machine changed IP and didn't re-register (common with laptops that sleep instead of shutting down), the old A record sticks around. Consider enabling scavenging if this happens repeatedly: Set-DnsServerScavenging -ScavengingState $true -RefreshInterval 7.00:00:00
• Duplicate or conflicting records — two A records for the same name pointing at different IPs. A classic cause of intermittent failures because clients round-robin between them.
• Missing PTR record — fine for forward resolution, but breaks anything relying on reverse lookup, including some auth mechanisms and Kerberos in specific configurations.

Get-DnsClientServerAddress -InterfaceAlias "Ethernet"
ipconfig /displaydns | Select-String "problem-host" -Context 2,2

Confirm the client is actually pointed at your internal DNS server, not a stale secondary, a VPN-assigned DNS, or a public resolver such as 8.8.8.8 that has no idea your internal zone exists. Clear a poisoned local cache before re-testing:

Clear-DnsClientCache
ipconfig /flushdns

If the client has multiple NICs (VPN plus physical, or Hyper-V virtual adapters), check the interface metric and DNS suffix search order — a lower-metric interface with a bad DNS server can shadow the correct one.

If internal names resolve fine but external (internet) names fail:

Get-DnsServerForwarder
Resolve-DnsName www.microsoft.com -Server 10.0.0.10

Confirm forwarder IPs are actually reachable from the DNS server. A firewall change upstream is a common silent cause:

Test-NetConnection 8.8.8.8 -Port 53

If forwarders are fine but resolution still fails, check whether the server is configured to use root hints instead, and whether outbound UDP/53 (and TCP/53 for larger responses) is permitted through the perimeter firewall.

Test-NetConnection -ComputerName 10.0.0.10 -Port 53
Test-NetConnection -ComputerName 10.0.0.10 -Port 53 -InformationLevel Detailed

DNS uses UDP/53 for most queries but falls back to TCP/53 for responses over roughly 512 bytes (common with DNSSEC or large record sets) and for zone transfers. If UDP/53 is open but TCP/53 is blocked, you'll see intermittent failures that look random and are hard to reproduce, specifically on queries with large responses.