DNS Troubleshooting Order: Resolver Cache to Authoritative Server
Troubleshoot DNS in order: capture the failing answer, inspect the client cache, compare recursive resolvers, trace delegation, then query each authoritative.
Troubleshoot DNS in order: capture the failing answer, inspect the client cache, compare recursive resolvers, trace delegation, then query each authoritative server directly.
Preserve the evidence before changing anything
Record the exact fully qualified domain name, record type, time, network, application error, and expected value. Test the name with its trailing dot, such as www.example.com., to avoid silently appending a local search suffix.
Capture a baseline with dig www.example.com. A +noall +answer +authority +comments. Note the response status, flags, answer, TTL, responding server, and query time. A NOERROR response with no requested record is NODATA, while NXDOMAIN says the name does not exist. Those outcomes require different investigation.
Do not flush caches yet. A decreasing TTL, an unexpected negative answer, or a particular responding server may identify the faulty layer. DNS TTL defines how long a resource record may remain cached, while negative answers also carry cache lifetimes through the zone’s SOA data, as specified by RFC 1034 and RFC 2308.
If the name is private, customer-specific, or reveals internal infrastructure, do not submit it to public resolvers or websites. Use an approved internal resolver and local command-line tools. For public names, the DNS Lookup can provide a convenient second view, but treat that lookup as information disclosed to an external service.
Follow the diagnostic branches in order
| Observed signal | Safe check | Expected result | Interpretation | Next action |
|---|---|---|---|---|
| Only one application fails. | Resolve the same absolute name with dig, then retry in another application on the same device. |
Both applications and the command-line query should ultimately use the same current address. | If dig is correct, the application may have its own cache, proxy, secure-DNS setting, or stale connection pool. |
Restart only the affected application or clear its documented DNS cache. Preserve its proxy and secure-DNS configuration for comparison. |
| Every application fails on one device. | Inspect the hosts file, configured resolvers, VPN state, and local cache before changing them. | No unintended hosts-file override should exist, and the device should be using the resolver intended for that network. | A hosts entry, VPN resolver, search suffix, or stale local cache can bypass otherwise healthy DNS. | Correct the local override or resolver selection. Flush only the client cache after recording the old answer. |
| Several devices fail behind one resolver. | Compare dig name type with dig @1.1.1.1 name type for a public name. |
Equivalent status and record sets are expected, allowing for legitimate CDN variation. | If the public resolver is correct but the normal resolver is not, suspect its cache, forwarding path, policy, or DNSSEC validation. | Check the recursive resolver’s logs and cache. Do not replace an organisation’s resolver without approval because internal zones and security policy may depend on it. |
| Recursive resolvers return a stale value or NXDOMAIN. | Read the remaining TTL and query an authoritative server directly. | The authoritative response should contain the current value and the aa flag. |
If authority is correct, a positive or negative cache entry may still be valid until its TTL expires. | Wait for expiry or clear only a cache you administer. Avoid repeatedly flushing clients because that hides TTL behaviour and increases query traffic. |
Resolvers return SERVFAIL. |
Compare dig @resolver.example name A +dnssec with the same query using +cd, substituting the actual approved resolver. |
Ordinary validation should succeed. Data appearing only with checking disabled suggests a DNSSEC problem. | The delegation may have a stale DS record, missing signatures, expired signatures, or an inconsistent key set. | Validate the chain and correct DS, DNSKEY, or signature data. Do not leave DNSSEC checking disabled as a workaround. |
| Queries time out. | Repeat once with dig @server name A +tcp and test every published authoritative server. |
Both UDP and TCP on port 53 should work for normal public authority service. | TCP-only success suggests filtering, truncation handling, an EDNS or path-MTU issue; one-server failure suggests host-specific reachability. | Inspect firewalls and packet paths. Do not run broad port scans against systems you do not administer. |
Inspect the client cache without destroying clues
On Windows, run ipconfig /displaydns and look for the exact name and record type. Microsoft documents that this cache includes records learned from queries and entries preloaded from the hosts file. After capturing the evidence, ipconfig /flushdns resets dynamically added entries, including negative cache entries; see the official ipconfig documentation.
On systems using systemd-resolved, resolvectl query www.example.com. shows the selected protocol, interface, and answer, while resolvectl statistics can expose cache activity. Cache-control commands vary across operating systems and resolver implementations, so use the platform’s documented method rather than restarting the entire network stack.
Decision boundary after a flush
If the first post-flush query becomes correct, the client held stale positive or negative data. Verify that a second query remains correct and that its TTL decreases normally. If the answer is immediately wrong again, the source is upstream or an active local override; another flush will not fix it.
Be aware that some recursive resolvers deliberately serve expired data when authoritative servers are unreachable. This improves availability but can make an old answer appear after its normal TTL. RFC 8767 defines this serve-stale behaviour, so a stale recursive answer does not by itself prove that the cache is malfunctioning.
Compare the recursive view with delegation
Discover the published authority with dig example.com. NS +short. At the time of a normal successful lookup, the result should list the zone’s delegated name servers, such as a.iana-servers.net. and b.iana-servers.net. for the reserved example domain.
Next run dig +trace example.com. A. The trace should progress from a root referral to the com. delegation and then to an authoritative answer for example.com.. BIND’s official manual explains that +trace follows the delegation path with iterative queries and that +norecurse suppresses the normal recursion request; see the BIND 9 dig documentation.
If the trace stops at a referral, inspect the parent’s NS and glue data. If a listed name server’s address cannot be found, or the server says it is not authoritative, the delegation may be lame. Confirm registrar-facing nameserver information with the WHOIS Lookup, while remembering that registry delegation and the child zone’s own NS records must also be compared directly.
Worked example: isolate authority from cache
- Run
dig example.com. A +noall +answer +comments. Expectstatus: NOERRORand at least one A record. Record the value, TTL, and server address. - Run
dig @1.1.1.1 example.com. A +noall +answer +comments. Expect another successful recursive answer. Different addresses are not automatically wrong because traffic-management systems may vary answers by resolver location. - Run
dig example.com. NS +short. Expect the delegated IANA name servers. - Run
dig @a.iana-servers.net. example.com. A +norecurse +noall +answer +comments, then repeat againstb.iana-servers.net.. ExpectNOERROR, theaaflag, and mutually consistent record sets. - Run
dig +trace example.com. A. Expect referrals followed by an authoritative answer rather than a timeout, loop, orSERVFAIL.
The decision boundary is the authoritative comparison. If both authoritative servers agree but one recursive resolver differs, investigate cache lifetime, forwarding, filtering, or validation at that resolver. If the authoritative servers disagree, compare dig @server example.com. SOA +norecurse results: differing SOA serials suggest incomplete zone transfer or deployment. If all authoritative servers agree on the wrong value, correct the zone source and publish it; flushing clients cannot repair authoritative data.
After remediation, query every published authority again, then the normal recursive resolver, and finally the affected application. Verify the status, record type, value, authority flag where appropriate, and TTL. Repeat from the affected network because VPNs, split-horizon DNS, and filtering can produce a different view. The broader DNS and Network Troubleshooting guide helps separate DNS failures from routing, firewall, and application-layer problems.
Important limitations and safer alternatives
- Split-horizon zones intentionally return different answers internally and externally. Public-resolver comparisons are unsafe for confidential names and misleading for private zones; test from an authorised internal client instead.
- NXDOMAIN can remain cached after a record is created. The negative TTL derives from the SOA data described by RFC 2308, so waiting for expiry may be safer than demanding organisation-wide cache purges.
- DNSSEC-related
SERVFAILshould be diagnosed, not bypassed. The+cdcomparison is evidence gathering; permanently disabling validation removes protection against forged DNS data. - CDNs, geo-aware DNS, anycast services, and weighted records may return several valid answers. Compare status, ownership, record type, and the provider’s documented ranges rather than demanding byte-for-byte equality.
dig +tracecontacts multiple public DNS servers and may expose the queried name. Use a synthetic public domain when demonstrating commands, and never paste internal hostnames, resolver addresses, or complete diagnostic logs into public tools or tickets without review.