A DNS lookup failed message means one specific thing: the resolution chain that turns a domain name into an IP address broke somewhere between your stub resolver and the authoritative nameservers. Everything else, the browser error string, the application timeout, the failed API call, is downstream noise. Your job is to find which hop stopped answering.
Work the resolution path in order (client cache, stub resolver, recursive resolver, authoritative nameserver, zone data) and a DNS lookup failure narrows to a single fault domain in under five minutes. That order matters because each layer can mask the one behind it, and flushing a cache before you know whether the domain even delegates correctly wastes the outage window.
PacketTools was built around exactly this workflow. The same DNS Lookup, DNS Propagation Checker, and SuperTool queries used here run in production networks to verify delegation, compare resolver answers, and confirm records before a change goes live. No sign-in, no logging of your queries, no stored test data.
By the end, you will be able to read an NXDOMAIN, a SERVFAIL, and a bare timeout as three different diagnoses, and know which one belongs to you and which one belongs to the domain owner.
What the Error Reveals About the Resolution Path
The exact response code your resolver returns tells you how far the query traveled before it died. A domain that returns NXDOMAIN reached authoritative DNS and got a definitive “no such name.” A query that times out may never have left your NIC.
How a Recursive Resolver Reaches Authoritative DNS
Your stub resolver hands the query to a recursive resolver, which walks the hierarchy from root to TLD to the domain’s nameservers.
The recursive resolver asks a root server for .com nameservers, asks those for the domain’s NS records, then asks the authoritative nameserver for the A record, AAAA record, or CNAME record you requested. Each step is cached against its TTL.
Break any link and the symptom changes. A missing NS record at the parent zone kills the referral. A dead authoritative host kills the final answer. A broken CNAME target resolves halfway and then returns nothing usable.
NXDOMAIN vs. SERVFAIL vs. Timeout Responses
These three responses point at three different owners of the problem.
| Response | What it means | Where to look |
|---|---|---|
| NXDOMAIN | Authoritative DNS confirms the name does not exist | Typo, deleted record, expired domain |
| SERVFAIL | Resolver tried and could not complete the lookup | DNSSEC validation failure, broken delegation, unreachable nameserver |
| Timeout | No response at all within the grace period | Blocked UDP port 53, unreachable resolver IP, firewall drop |
SERVFAIL is the one engineers misdiagnose most. It is a resolver-side failure report, so the domain can be perfectly configured while your validating resolver rejects the chain.
Why 504 DNS Lookup Failed Is a Different Failure Mode
A 504 DNS lookup failed comes from a proxy, CDN edge, or gateway, telling you its resolver could not resolve your origin hostname.
Your workstation resolves the site fine because you are hitting the edge, which then fails to look up the backend. Check the origin hostname in your CDN configuration, the origin’s A record, and whether the origin nameservers answer queries from outside your network.
Is the Fault Local, Network-Wide, or Domain-Side?
Scope the blast radius before touching a single setting. One device failing, every device on the LAN failing, and one domain failing everywhere are three separate investigations with almost no overlap in remediation.
What It Means When Only One Device Fails
A single failing host points at that host’s DNS configuration, cache, or a local override.
Test the same name from a phone on mobile data and from a second machine on the same subnet. If both succeed, the fault sits in the endpoint’s resolver settings, a stale cache entry, a hosts file line, or a VPN client that rewrote the DNS servers on the network adapter.
Windows checks its cache first, then the hosts file, then queries the DNS server, according to Microsoft’s client name resolution guidance. A stale hosts entry produces zero DNS traffic on the wire, which is why packet captures look empty during these failures.
How to Separate Wi-Fi and ISP Problems From DNS
Ping an IP address directly. If ping 1.1.1.1 succeeds and name resolution fails, connectivity is fine and DNS is the problem.
When the ping also fails, you are chasing a Wi-Fi, modem, or ISP path issue, not resolution. That is the difference between a resolver fault and a Wi-Fi connected but no internet condition, and the fixes share nothing.
DHCP hands out ISP DNS by default. When an ISP resolver has a partial outage, some names resolve and others fail, which reads like a random site problem until you compare against a public resolver.
When One Domain Fails but Other Sites Resolve
A single domain failing across multiple networks and resolvers is a domain-side fault.
Check registration status and nameserver delegation first. An expired domain, a registrar hold, or nameservers that were changed at the registrar but never populated at the DNS provider all produce the same user-facing failure.
Recent record changes bring TTL into it. A DNS propagation delay means old cached answers persist for the length of the previous TTL, and CDN edges hold their own cached views independently.
Run the First DNS Tests Before Changing Settings
Diagnose before you remediate. Four minutes of resolver comparison and a dig +trace will tell you whether the fault is your resolver, the transport path, or the domain’s zone, and that answer determines every step after it.
Compare Local, Google, Cloudflare, and Quad9 Resolver Results
Query the same name against your configured resolver and three public DNS servers, then compare.
- Google DNS: 8.8.8.8 and 8.8.4.4
- Cloudflare DNS: 1.1.1.1 and 1.0.0.1
- Quad9: 9.9.9.9
If your local resolver fails while all three public resolvers answer, the fault is your resolver or ISP DNS. If every resolver fails identically, the domain or its delegation is broken. If public resolvers work and your local one returns a different answer, suspect split DNS or interception.
Quad9 filters known-malicious domains, so a name that resolves on 1.1.1.1 and returns NXDOMAIN on 9.9.9.9 is a reputation block, not a configuration error.
Use nslookup and dig to Identify the Break
dig gives you the status line and the full chain; nslookup ships on every Windows box.
dig example.com A +short
dig @8.8.8.8 example.com A
dig example.com NS
dig +trace example.com+trace walks root to TLD to authoritative, and where it stops is where delegation breaks. Failing early in the trace points at domain registration or the parent zone’s NS records.
On Windows, nslookup example.com 8.8.8.8 forces a specific server. Note that nslookup contacts only the primary configured DNS server, so on a NIC with four resolvers listed it will report failure even when a secondary would have answered. Windows uses nslookup while macOS and Linux use dig for the same class of test.
Read the status: field in dig output. NOERROR with an empty ANSWER section means the name exists but the record type you asked for does not.
Check Reachability and the DNS Path With Ping and Traceroute
DNS rides UDP port 53 with TCP fallback for large responses, so confirm that transport actually works.
Ping the resolver IP. A resolver that does not answer ICMP still may serve DNS, so follow with dig @<resolver-ip> example.com to test port 53 directly. Run a ping test against the resolved IP once you have an answer to separate resolution from reachability.
Traceroute the resolver address when queries time out on an internal DNS server. Path asymmetry, a firewall hop that drops UDP, or an MPLS re-route shows up in the hop list. Our guide on how to trace a route covers reading those hops properly.
Validate a Domain With PacketTools DNS Lookup and SuperTool
Command-line tools show you what your vantage point sees. External validation shows what the rest of the internet sees.
The PacketTools DNS Lookup runs the query from outside your network, so a name that fails locally and resolves externally confirms the fault is inside your perimeter. SuperTool bundles DNS, MX, SPF, DKIM, DMARC, blacklist, and SSL checks into a single domain run, which is faster than firing six separate queries when a domain’s records are suspect.
Nothing is logged. No IPs, no queries, no test data, no sign-in.
Fix Endpoint Resolver and Cache Problems
Endpoint fixes are cheap and reversible, which is why they come after diagnosis and before anything touching production DNS. A corrupted cache, a stale static resolver entry, or a VPN client override accounts for most single-machine failures.
Clear a Corrupt DNS Cache on Windows, macOS, and Linux
Flush the cache when a record changed recently and your machine still returns the old IP address.
- Windows:
ipconfig /flushdnsfrom an elevated Command Prompt - macOS:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder - Linux (systemd-resolved):
sudo resolvectl flush-caches - Linux (nscd):
sudo systemctl restart nscd
Verify after flushing with dig and check the TTL value in the response. A TTL counting down from the record’s full value means you received a fresh authoritative answer; a low odd number means you hit a cache again.
Google Chrome keeps its own cache at chrome://net-internals/#dns. Clear that separately, since flushing the OS cache leaves it untouched.
Verify DHCP and Static DNS Configuration
Check what DNS servers the adapter is currently using before assuming DHCP delivered them.
Run ipconfig /all on Windows or resolvectl status on Linux. A static entry pointing at a decommissioned internal DNS server is a common leftover from a lab build or an old migration.
Multiple unreachable servers listed ahead of a working one cause resolution to take roughly four seconds while the client cycles through the list. Applications time out before DNS does. Remove dead entries in the TCP/IPv4 properties rather than adding more.
Reset the Windows Network Stack Only When Needed
Reserve stack resets for cases where the adapter configuration looks correct and queries still never leave the machine.
netsh winsock reset
netsh int ip resetBoth require a reboot and will clear proxy settings, static routes, and any LSP entries installed by security software. Capture the current config first. This is the step that fixes DNS_PROBE_FINISHED_BAD_CONFIG conditions when nothing lighter has, and our walkthrough on DNS_PROBE_FINISHED_BAD_CONFIG covers the sequence in more detail.
Check Browser, Hosts File, VPN, and Proxy Overrides
Something between the application and the resolver is rewriting your query more often than you would expect.
Inspect C:WindowsSystem32driversetchosts or /etc/hosts for leftover entries. A hosts entry produces an answer with no DNS traffic on the wire at all.
Then check for a VPN client that pushed its own DNS servers, an Android Private DNS profile still pointed at a decommissioned DoT host, and browser-level DNS-over-HTTPS that bypasses your corporate resolver entirely. Clearing cookies fixes nothing here; the override is at the resolver layer.
Resolve Network, Security, and Authoritative DNS Faults
Once the endpoint is clean, the remaining faults live in the transport path or the zone itself. Blocked port 53, split-horizon views that leak, broken delegation, and DNSSEC chain failures each produce distinct signatures.
Allow DNS Transport Through Firewalls, Filters, and Relays
An outbound rule blocking UDP port 53 produces a timeout with zero DNS traffic reaching the server.
Microsoft documents this precisely: with UDP 53 blocked, Resolve-DnsName returns an operation timeout and a Wireshark trace on the client shows no outbound DNS at all. Mirror the switch port to confirm whether the packet ever left the host.
Allow TCP 53 as well. Large responses, DNSSEC records, and zone transfers fall back to TCP, and a UDP-only rule breaks them selectively. Content filters and router DNS relays add another failure point when the relay itself points at a dead upstream.
Diagnose Split DNS on Corporate Networks and VPNs
Split DNS breaks when the client resolves an internal name against an external resolver, or the reverse.
Compare dig @<internal-dns> intranet.corp.example with dig @1.1.1.1 intranet.corp.example. Internal-only zones return NXDOMAIN publicly by design, so a public NXDOMAIN on an internal name is correct behavior and tells you the query went to the wrong resolver.
Check the VPN’s DNS suffix search list and split-tunnel rules. A long suffix search list makes the client append each domain in order, adding seconds of latency before the correct query is even sent.
Repair Delegation, Zones, and Missing Records
Delegation faults show up as SERVFAIL or an early stop in dig +trace.
Query the parent zone for NS records with dig example.com NS @<tld-server> and compare against what the DNS provider actually serves. Registrar nameservers and provider nameservers must match exactly.
Then confirm the record itself exists. An A record deleted during a migration, a CNAME pointing at a hostname that no longer resolves, or an AAAA record for an IPv6 address that is not routed all produce failures for clients that prefer that record type.
Handle DNSSEC Failures and Propagation Safely
A DNSSEC validation failure returns SERVFAIL on validating resolvers while non-validating resolvers answer normally.
Test with dig +cd example.com to disable validation. An answer with +cd and SERVFAIL without it confirms a broken chain, almost always a DS record at the registrar that no longer matches the zone’s DNSKEY after a key rollover.
Lower TTLs to 300 seconds at least 24 hours before a planned change, then verify the new records across regions with a propagation check before restoring the original TTL. Testing changes on a staging domain that mirrors production is standard practice, as outlined in safe pre-launch DNS testing.
Turn DNS Evidence Into the Right Next Action
Every DNS lookup failed error resolves into one of four owners: your endpoint, your network path, your resolver, or the domain’s authoritative DNS. The response code and the resolver comparison identify which one before you change anything.
Work the sequence. Compare your resolver against 8.8.8.8, 1.1.1.1, and 9.9.9.9. Run dig +trace to see where delegation stops. Flush the cache only when a record changed recently. Reset the Windows stack only when queries never leave the NIC.
For domain-side faults, verify delegation and records externally with the PacketTools DNS Lookup and confirm timing with the propagation checker before you tell a stakeholder the change is live. When a broader outage is in play, our network troubleshooting and DNS server not responding guides pick up where resolution testing leaves off.
Keep the four public resolver IPs and dig +trace in your runbook. Those two things answer the ownership question faster than any log dive.
Leave a Reply