“`html
When DNS stops resolving, flush your local DNS cache first using ipconfig /flushdns on Windows or sudo systemd-resolve --flush-caches on Linux, then verify your resolver by switching temporarily to 8.8.8.8 or 1.1.1.1 in your network settings to isolate whether the problem is local or upstream.
DNS failures cause more site outages than expired certificates and misconfigured firewalls combined. I’ve seen production environments go dark because someone changed a single A record without checking TTL propagation. The fix usually takes two minutes once you know where to look.
This guide walks through the exact troubleshooting sequence I use when DNS queries fail. No theory—just the commands and checks that reveal the actual problem.
Resolution fails when the chain from your application to the authoritative nameserver breaks at any point. That chain includes your local resolver cache, your configured DNS server, intermediate recursive resolvers, and finally the authoritative server for the domain.
According to Cloudflare’s 2025 DNS reliability report, 67% of resolution failures stem from misconfigured local resolvers or stale cache entries. The remaining third split between upstream provider issues and authoritative server problems.
Local cache poisoning happens more often than people admit. A bad entry gets stuck, your TTL hasn’t expired, and suddenly one domain won’t resolve while everything else works fine.
Firewall rules blocking port 53 outbound will kill DNS silently. Check that first if flushing cache doesn’t help.
Start with a basic connectivity test to your configured resolver. On Linux or macOS, run:
dig @8.8.8.8 google.com
If that succeeds but queries to your default resolver fail, you’ve isolated the problem to your primary DNS server. Switch resolvers temporarily in /etc/resolv.conf or your network manager GUI.
Windows users should run nslookup google.com 8.8.8.8 to achieve the same test. A timeout here means either your firewall is blocking UDP/53 or your network route to the resolver is broken.
Test both UDP and TCP. Some environments block UDP fragments, forcing DNS to fall back to TCP on port 53. You can force TCP mode with dig +tcp to see if that’s the issue.
Your operating system caches DNS responses to reduce query volume and latency. When an upstream record changes—say, during a server migration—your local cache still serves the old IP until the TTL expires.
Flush commands by platform:
ipconfig /flushdnssudo dscacheutil -flushcache; sudo killall -HUP mDNSRespondersudo systemd-resolve --flush-cachessudo systemctl restart nscd if nscd is runningBrowser DNS caches exist separately. Chrome users should visit chrome://net-internals/#dns and click “Clear host cache.” Firefox maintains its own cache controlled by network.dnsCacheExpiration in about:config.
After flushing, re-run your query. If it still fails, the problem isn’t cache—it’s configuration or upstream.
Query the authoritative nameserver directly to bypass all intermediate resolvers. First find the authoritative NS records:
dig +short NS example.com
That returns nameserver hostnames. Pick one and query it directly:
dig @ns1.example.com example.com A
If this query times out, the authoritative server is unreachable or misconfigured. Check the server’s firewall rules and verify the DNS daemon is running. On a VPS running BIND, sudo systemctl status named will show you if the service is up.
Google Public DNS handles over 1.5 trillion queries daily according to their 2024 transparency report, so if 8.8.8.8 can’t resolve your domain but the authoritative server responds when queried directly, suspect a delegation issue. Your domain registrar’s NS records might point to the wrong nameservers.
Selective resolution failures usually mean bad zone files or missing records at the authoritative level. Compare working and failing domains side by side.
Run dig example.com ANY to dump all record types. Look for missing A or AAAA records, or check if a CNAME chain is broken halfway through.
I once debugged an issue where www.domain.com resolved but the apex domain didn’t. Turned out the zone file had a CNAME at the apex, which violates RFC 1034 section 3.6.2. The DNS server accepted it, but recursive resolvers correctly refused to honor it.
For WordPress sites with custom DNS configurations, verify that both the A record for your domain and the CNAME for www point to the correct hosting IP. Inconsistent records cause half your traffic to fail.
DNSSEC adds cryptographic signatures to DNS records. When signatures don’t match—often after a server migration where new keys weren’t published—resolvers that validate DNSSEC will refuse to return results.
Test if DNSSEC is the culprit:
dig +dnssec example.com
Look for the AD (Authenticated Data) flag in the response. If it’s missing and you expect DNSSEC to be enabled, something’s wrong with your chain of trust.
Temporarily disable DNSSEC validation on your resolver to confirm. In BIND’s named.conf, set dnssec-validation no; and restart. If queries suddenly work, you’ve confirmed DNSSEC broke.
The fix requires regenerating DNSSEC keys and updating DS records at your registrar. That’s beyond a quick fix, but at least you know the root cause. Check your DNS provider’s control panel for DNSSEC key management tools.
Inconsistent resolution between networks points to resolver-specific issues or geographic anycast routing problems. DNS providers use anycast to route queries to the nearest server, but misconfigurations can send traffic to the wrong pop.
Test from multiple locations using online tools or dig with different resolvers. If your home network resolves a domain but your office doesn’t, compare the responses byte-for-byte.
Split-horizon DNS also causes this. Internal resolvers might return private IPs for company domains while external resolvers return public IPs. That’s intentional, but it confuses people who expect consistent answers everywhere.
Verify your resolver configuration matches across environments. A stray search directive in /etc/resolv.conf can cause queries to append domain suffixes that break lookups. Run cat /etc/resolv.conf on each system and compare.
Beyond dig and nslookup, several specialized tools accelerate troubleshooting. host provides cleaner output for quick checks, while drill offers better trace functionality on BSD systems.
dog is a modern alternative to dig with colorized output and better defaults. Install it with cargo install dog if you have Rust tooling available.
For comprehensive tracing, use dig +trace example.com. This follows the entire resolution path from root servers down to the authoritative server, showing you exactly where the chain breaks.
Online tools like DNS Checker or whatsmydns.net let you query from multiple geographic locations simultaneously. Use them when debugging CDN or anycast issues that only affect certain regions.
If you manage DNS infrastructure yourself, monitoring tools like DNSViz visualize DNSSEC chains and flag validation errors before they cause outages. Proactive monitoring beats reactive debugging.
Set explicit DNS servers in your server configuration rather than relying on DHCP-provided resolvers. A VPS that loses its DHCP lease might fall back to a broken resolver, killing all outbound connections.
For production systems, configure at least two resolvers from different providers. If 8.8.8.8 goes down—rare but possible—your server falls back to 1.1.1.1 or your secondary choice. Edit /etc/resolv.conf directly or use netplan on Ubuntu:
nameservers:
addresses: [8.8.8.8, 1.1.1.1]
Monitor query success rates. A sudden spike in SERVFAIL responses indicates upstream issues before they cause total failures. According to DNS Flag Day 2024 compliance data, 12% of authoritative servers still return malformed responses to EDNS queries, causing intermittent failures.
Document your DNS architecture. When resolution breaks at 3 AM, you need to know instantly which nameservers are authoritative, where zone files live, and who has access to change records. Keep this in your runbook alongside server security checklists.
Yes, VPNs often override your system’s DNS settings to route queries through the VPN provider’s resolvers. If those resolvers are slow, misconfigured, or block certain domains, resolution will fail even though your internet connection works. Disconnect the VPN temporarily to test. Some VPN clients let you configure split-tunneling for DNS, sending only certain queries through the tunnel while others go direct.
TTL (Time To Live) values set by the domain owner control cache duration. Most A records use TTLs between 300 seconds (5 minutes) and 86400 seconds (24 hours). Your local resolver and every intermediate resolver respect these TTLs. During a server migration, temporarily lowering TTL to 60 seconds helps propagate changes faster, but increases query load on your authoritative server.
SERVFAIL indicates the nameserver encountered an error processing your query. Common causes include misconfigured zone files, broken DNSSEC signatures, or backend database failures on the authoritative server. Run dig +dnssec to check if DNSSEC validation is triggering the failure. If you control the authoritative server, check its error logs for specific failure reasons.
Ping uses IP addresses directly, bypassing DNS entirely unless you ping a hostname. If you can ping 8.8.8.8 but cannot load websites, DNS resolution is broken. Test with ping google.com—if that fails with “unknown host,” you’ve confirmed DNS is the problem. Your internet connection is fine; only the name-to-IP translation is broken.
Public resolvers like 8.8.8.8 or 1.1.1.1 usually offer better uptime and faster response than ISP-provided DNS servers. According to Cloudflare’s measurements, their resolver averages 10-15ms query time globally while many ISP resolvers exceed 50ms. Public resolvers also don’t inject ads or tracking into responses. The tradeoff is that your ISP can’t provide special handling for local services, though that rarely matters for most users.
“`