Windows Server · Troubleshooting

Troubleshooting DNS resolution on Windows Server

"It's always DNS." Here's the methodical way to prove it, find the fault and fix it, from the client cache to the server's forwarders.

Two engineers troubleshooting network issues at a monitoring desk

When users report that "the internet is down" or "the shared drive won't open", the culprit is very often name resolution, not the network itself. The trick is to work from the client outwards, proving each layer before moving to the next. Skipping steps is how a ten-minute fix becomes an afternoon.

Example environment used in this guideDomain contoso.local, DNS server / domain controller at 10.0.0.10, failing name intranet.contoso.local. Replace these with your own values.

1Confirm it's actually DNS

First, separate "can't reach the machine" from "can't find its name". Ping the target by IP address, then by name:

ping 10.0.0.25            # by IP address
ping intranet.contoso.local  # by name

If the IP works but the name fails with "could not find host", you have a DNS problem. If both fail, look at the network path first. Our ping and tracert guide covers that.

NoteSome servers block ping (ICMP) by firewall. A failed ping by IP isn't proof of a network fault on its own; try Test-NetConnection 10.0.0.25 -Port 445 or another port you know is open.

2Check the client's DNS settings

Look at which DNS servers the machine is actually using:

ipconfig /all
# or, in PowerShell:
Get-DnsClientServerAddress -AddressFamily IPv4

On a domain-joined machine, the DNS servers listed should be your internal DNS servers (usually domain controllers), never a public resolver like 8.8.8.8. Public resolvers have no idea what contoso.local is, so internal names will fail while websites keep working. That's the classic symptom.

3Clear the client cache

Windows caches DNS answers, including failed lookups (negative caching). An old or wrong answer can persist after the real problem is fixed.

Get-DnsClientCache | Where-Object Entry -like "*intranet*"   # inspect first
Clear-DnsClientCache                                        # same as ipconfig /flushdns

Also check the local hosts file at C:\Windows\System32\drivers\etc\hosts. An old manual entry there overrides DNS completely and is easy to forget.

4Query the DNS server directly

Now ask the DNS server by name, bypassing the cache and hosts file. This tells you whether the problem is the client or the server:

Resolve-DnsName intranet.contoso.local -Server 10.0.0.10 -DnsOnly
# the classic equivalent:
nslookup intranet.contoso.local 10.0.0.10
  • Answer returned: the server is fine; the problem is on the client (settings, cache, hosts file).
  • "DNS name does not exist": the server is reachable but has no record. Go to step 6.
  • Timeout: the client can't reach the server at all. Go to step 5.

5Test connectivity to port 53

DNS listens on port 53. Check the client can reach it:

Test-NetConnection 10.0.0.10 -Port 53

TcpTestSucceeded : True means the path and service are up. Note that this tests TCP, while most DNS queries use UDP port 53, so a firewall could still block UDP only. If TCP succeeds but queries time out, check firewall rules for UDP 53 on both the client and the server.

6Check the DNS server itself

On the DNS server, confirm the service is running and the zone and record exist:

Get-Service DNS
Get-DnsServerZone
Get-DnsServerResourceRecord -ZoneName "contoso.local" -Name "intranet"

If the record is missing, recreate it, or check why dynamic registration failed on the target machine (running ipconfig /registerdns there forces a re-registration). If the record exists but points to an old IP address, update it, then clear the server's cache:

Clear-DnsServerCache -Force

7When only external names fail

If internal names resolve but public websites don't, the server can't reach the outside world for lookups. Check its forwarders, the upstream resolvers it asks for names it doesn't host:

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

A forwarder that has been decommissioned, or a firewall blocking the server's outbound port 53, are the usual causes. If no forwarders are set, the server falls back to root hints, which also needs outbound DNS access.

In a domain, DNS and Active Directory depend on each other. Run the built-in diagnostic on a domain controller:

dcdiag /test:dns /v

Then open Event Viewer → Applications and Services Logs → DNS Server and look for recent errors or warnings. Zone-loading and replication errors here point to deeper issues worth fixing before they spread.

Quick reference

SymptomLikely causeCommand to check
Internal names fail, websites workClient uses a public DNS serveripconfig /all
Old IP keeps coming backClient or server cache, hosts fileClear-DnsClientCache
"Name does not exist"Missing or wrong recordGet-DnsServerResourceRecord
Queries time outFirewall or DNS service downTest-NetConnection -Port 53
Only external names failBroken forwardersGet-DnsServerForwarder
Domain logons slow or failingAD DNS records unhealthydcdiag /test:dns

Work through the steps in order and you'll rarely need more than ten minutes. And when someone insists "it can't be DNS", you'll have the output to show them.