How to troubleshoot DNS resolution issues

"Server not found" with a perfectly healthy internet connection is the classic DNS failure signature. Packets flow, pings succeed by IP, but names won't resolve. The good news: DNS troubleshooting is a short, well-ordered checklist, and each step either fixes the problem or tells you exactly where to look next.

This guide works through that checklist with real commands. Budget 15-30 minutes for a stubborn case; most are solved in five.

First, confirm it's actually DNS

Before touching resolver settings, separate "DNS is broken" from "the network is broken". Ping a public IP directly:

ping 8.8.8.8

If that fails, your problem is connectivity, not DNS; start with a ping test against a few known-good hosts and work down the stack. If the IP ping succeeds but ping example.com fails with "cannot resolve" or "unknown host", you've confirmed a DNS resolution issue. Continue.

Step 1. Test resolution with dig or nslookup

dig (macOS/Linux) and nslookup (everywhere, including Windows) ask a DNS server a question and show you the raw answer.

dig example.com

The parts that matter in the output:

• status in the header: NOERROR means the query worked. NXDOMAIN means the name genuinely doesn't exist at that resolver. SERVFAIL means the resolver tried and failed, often a problem with the domain's authoritative nameservers or DNSSEC validation.
• ANSWER SECTION: the actual records returned. No answer section with NOERROR means the name exists but has no record of the type you asked for.
• Query time and SERVER at the bottom: which resolver answered and how long it took.

On Windows:

nslookup example.com

Three outcomes, three directions:

1. Resolution works in dig/nslookup but not in the browser: the OS or browser cache is stale. Go to step 3.
2. NXDOMAIN or SERVFAIL from your resolver: test an alternative resolver (step 4) to see whether the problem is your resolver or the domain itself.
3. The query times out entirely: your configured DNS server is unreachable. Go to step 2.

If you'd rather not open a terminal, run the same query through the DNS Lookup tool; it queries from our infrastructure, which also gives you a second vantage point for free. The basics of reading record types are covered in how to perform a DNS lookup.

Step 2. Check your DNS server settings

Find out which resolver your machine is actually using:

# macOS
scutil --dns | grep nameserver

# Linux (systemd-resolved)
resolvectl status

# Windows
ipconfig /all | findstr "DNS Servers"

Common misconfigurations:

• A dead or decommissioned internal DNS server still listed first. Queries hang for the timeout period, then fail or fall through slowly.
• VPN leftovers. VPN clients rewrite DNS settings and don't always restore them on disconnect. If DNS broke right after a VPN session, this is the prime suspect.
• Router as resolver. Most home setups hand out the router's IP via DHCP, and the router forwards to the ISP. If the router's DNS forwarder is wedged, every device on the network fails simultaneously, a useful diagnostic in itself. Reboot the router or point a single machine at a public resolver to confirm.

Step 3. Flush the DNS cache

Stale cached answers cause the "works on my phone, not on my laptop" pattern, especially after a record change. Flush:

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Windows
ipconfig /flushdns

# Linux (systemd-resolved)
sudo resolvectl flush-caches

Browsers keep their own DNS cache on top of the OS. In Chrome, visit chrome://net-internals/#dns and click Clear host cache, or just restart the browser. If resolution works in dig but the browser still fails after both flushes, check the browser's secure-DNS (DoH) setting; it may be bypassing your OS resolver entirely and talking to a different one.

Step 4. Try alternative DNS servers

Querying a different resolver directly tells you whether the fault is local or global:

dig example.com @8.8.8.8     # Google
dig example.com @1.1.1.1     # Cloudflare

• Works via 8.8.8.8 but not your default resolver: your resolver (ISP or router) is the problem. Switch your network settings to 8.8.8.8/1.1.1.1, at least temporarily.
• Fails everywhere with NXDOMAIN: the domain's records are genuinely missing or the domain has expired. Check the registration with a WHOIS lookup; an expired domain produces exactly these symptoms.
• Fails everywhere with SERVFAIL: likely broken authoritative nameservers or a bad DNSSEC signature. dig +cd example.com @8.8.8.8 (checking disabled) succeeding where the normal query fails is a strong DNSSEC indicator.

Step 5. Verify propagation if records recently changed

If the domain's records changed in the last day or two, you may simply be seeing old cached data that hasn't expired yet. Query the authoritative nameserver directly to see the true current value:

dig NS example.com +short          # find the authoritative servers
dig example.com @ns1.example.net   # ask one of them directly

If the authoritative answer is correct but public resolvers still serve the old value, you're waiting on TTL expiry, not fixing anything. The full workflow is in our DNS propagation guide.

Step 6. Check for DNS filtering or firewall blocks

If specific domains fail while others resolve fine, something is filtering:

• Filtering resolvers. Quad9, OpenDNS, and many corporate resolvers deliberately block malware/phishing domains, sometimes returning NXDOMAIN, sometimes a block-page IP. Compare answers between a filtering and non-filtering resolver.
• Firewall blocking port 53. Some networks force all DNS through their own resolver and drop outbound UDP/TCP 53. dig example.com @8.8.8.8 timing out while the default resolver works is the tell.
• Hosts file overrides. Check /etc/hosts (or C:\Windows\System32\drivers\etc\hosts) for stale manual entries; leftover dev entries pointing a production hostname at 127.0.0.1 is a classic.

When it keeps happening

If you're troubleshooting the same domain repeatedly because records keep changing underneath you, stop diagnosing reactively. A DNS record drift monitor snapshots the record set and alerts you the moment it changes, so the next incident starts with "here's the diff" instead of "why is this broken again?"

TL;DR

1. ping 8.8.8.8: if the IP works but names don't, it's DNS.
2. dig example.com: read the status. NOERROR, NXDOMAIN, or SERVFAIL each point somewhere different.
3. Flush the OS and browser DNS cache.
4. dig example.com @8.8.8.8: works there but not locally? Your resolver is at fault; switch it.
5. NXDOMAIN everywhere? Check WHOIS for expiry. Recent change? It's propagation, not breakage.
6. Specific domains only? Suspect filtering resolvers, port-53 firewall rules, or a stale hosts file.