DNS Resolution Failures in a Windows Domain — Fix

Confirm It's Actually DNS

Before assuming DNS, rule out basic connectivity. DNS failure and network failure look identical from the surface.

# Test by IP address — bypasses DNS entirely
ping 10.0.0.10

# Test by hostname — uses DNS
ping dc01.corp.local

# If IP works but hostname fails: it's DNS
# If both fail: it's network or firewall

# Definitive DNS test
Resolve-DnsName dc01.corp.local
Resolve-DnsName corp.local -Type SOA

If Resolve-DnsName fails or returns wrong IPs, DNS is broken. Continue below.

Check Client DNS Settings

Windows clients must point to a domain controller's IP as their primary DNS server — not the router, not 8.8.8.8, and not themselves unless they ARE the DC.

# Check current DNS servers on all adapters
Get-DnsClientServerAddress | Where-Object {$_.AddressFamily -eq 2}

# Classic way
ipconfig /all | findstr "DNS Servers"

Common mistakePointing DNS at the default gateway (router) instead of a DC. The router doesn't know your internal domain zones. It must be the DC's IP.

# Fix: set DNS to DC IPs
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses ("10.0.0.10","10.0.0.11")

Test DC Reachability

# Locate a domain controller
nltest /dsgetdc:corp.local

# Test DC is responding on DNS port
Test-NetConnection -ComputerName 10.0.0.10 -Port 53

# Test LDAP connectivity
Test-NetConnection -ComputerName dc01.corp.local -Port 389

If port 53 is blocked, DNS queries can't reach the DC. Check firewall rules — port 53 (TCP and UDP) must be open between clients and the DC.

Inspect DNS Server Health

On the domain controller running DNS:

# Check DNS Server service status
Get-Service DNS | Select Status

# View DNS event log for errors
Get-WinEvent -LogName "DNS Server" -MaxEvents 50 |
  Where-Object {$_.LevelDisplayName -eq "Error" -or $_.LevelDisplayName -eq "Warning"} |
  Select TimeCreated, Id, Message | Format-List

# List all DNS zones
Get-DnsServerZone

Look for zones marked Paused or with unexpected ZoneType. A paused zone means DNS isn't responding for that domain.

# Resume a paused zone
Resume-DnsServerZone -Name "corp.local"

Check SRV Records

The domain might resolve but return stale or missing records — particularly the SRV records DCs and clients use to find each other.

# Check _msdcs zone — critical for DC location and Kerberos
Resolve-DnsName _ldap._tcp.dc._msdcs.corp.local -Type SRV

# Verify SOA and NS records
Resolve-DnsName corp.local -Type SOA -Server 10.0.0.10

# Re-register DC DNS records if missing
ipconfig /registerdns
net stop netlogon && net start netlogon

NoteIf SRV records are missing, Kerberos and domain join will fail even if basic name resolution works. Restarting Netlogon re-registers them.

Flush and Re-register on the Client

# Run as administrator on the affected client
ipconfig /flushdns
ipconfig /registerdns
ipconfig /release
ipconfig /renew

# Test immediately after
Resolve-DnsName dc01.corp.local

TipIf it resolves after flushing, it was a stale cache issue. No further action needed on the server side.

Check Forwarders

If internal DNS works but external DNS is broken (can reach dc01 but not google.com), the issue is forwarders.

# On the DC — check configured forwarders
Get-DnsServerForwarder

# Add Cloudflare and Google as forwarders if missing
Add-DnsServerForwarder -IPAddress 1.1.1.1, 8.8.8.8

# Test external resolution via the DC directly
Resolve-DnsName google.com -Server 10.0.0.10

DNS Resolution Failures in a Windows Domain — Step-by-Step Fix