DNS failures announce themselves in short error messages that hide a lot of complexity. SERVFAIL, or a bare timeout, doesn’t point to a single cause. Each is a symptom from somewhere along a distributed chain of clients, recursive resolvers, authoritative servers, and the networks between them.
Knowing what each failure mode usually means, and which part of the chain produces it, is most of the diagnostic battle.
DNS rarely fails in one place
A DNS lookup is a chain of dependent steps, and a failure anywhere in the chain reaches the client as a simplified summary. The client sees one of a few outcomes: a successful answer, an explicit error code such as SERVFAIL or NXDOMAIN, or nothing at all, which surfaces as a timeout.
The visible error is often downstream from the real cause. Start every DNS investigation with that assumption.
SERVFAIL
SERVFAIL means a DNS server failed to complete the query. It doesn’t mean the domain doesn’t exist, and it deliberately doesn’t say why. It’s the protocol’s generic “something went wrong.”
Common underlying causes:
- DNSSEC validation failures
- An authoritative server returning malformed responses
- A resolver failing to reach an authoritative server
- Internal resolver errors or resource exhaustion
DNSSEC is worth ruling out early. A resolver that can’t validate a signed response must fail the query rather than hand back data it can’t vouch for. To test for it, retry with validation disabled using dig example.com +cd. If the SERVFAIL disappears, you have a DNSSEC problem, not a reachability problem.
SERVFAIL also tends to look intermittent from the client side. One resolver succeeds while another fails, depending on cache state, validation settings, and reachability.
Timeouts
A timeout means no response arrived within the configured wait period. Unlike SERVFAIL, there’s no response code because there’s no response.
Timeouts usually indicate:
- Packet loss or network filtering
- An authoritative server that is slow or unreachable
- A resolver under heavy load
- MTU or fragmentation issues affecting large responses
When a response is too big for UDP, the server truncates it and the client retries over TCP. If TCP port 53 is blocked somewhere along the path, the query simply dies.
Timeouts are hard to diagnose because there’s nothing to inspect. Resolver logs or a packet capture are usually the only way to see where the query stalled, and resolver retries can mask early trouble before users notice it.
Stale data
Stale data is a cached answer that outlives its intended lifetime. It’s usually a caching behavior, not an outright failure.
It shows up when TTL values are set too high, when a cached negative answer (an NXDOMAIN or no-data result) outlives a fix, or when resolvers deliberately serve expired records because the authoritative servers are unreachable. That last behavior is a resilience feature, not a bug, and modern resolvers support it.
To users, stale data looks like partial recovery. Some clients reach the new address while others keep landing on the old one, and which group a user falls into depends on whose cache they sit behind.
Partial outages
A partial outage is resolution that works for some users, locations, or record types and fails for others. Common shapes:
- Anycast routing problems that steer some regions to a failing node
- Zone data that differs across authoritative servers
- Failures confined to IPv6 or IPv4
- Split-horizon or conditional-forwarding misconfigurations, where a resolver answers differently by client
Because DNS leans so heavily on caching, a partial outage can outlive its root cause, and different resolvers keep serving different answers until caches expire.
Partial outages are easy to misdiagnose as application bugs, because nothing fails uniformly. From the outside the system looks flaky rather than down, and flaky rarely gets blamed on DNS first.
Why DNS failures are confusing by design
DNS response codes are terse by design, and the original protocol gave clients no window into resolver internals. Many distinct problems collapse into the same visible error. Caches delay and mask failures. Recovery arrives unevenly across clients and networks.
Extended DNS Errors help when both resolver and client support them, but that support isn’t universal, so the underlying cause often stays hidden even when better information exists on the wire.
Summary
A visible DNS error is a symptom, not a root cause. Caching softens failures and then prolongs the confusion, and in a distributed, cached system, partial or intermittent failure is expected rather than exceptional.
Hold those three traits in mind and the failures in this article get easier to reason about. Each one points back into a chain of dependencies, which is where to look first.