What Is a DNS Resolution Failure? – Causes and Fixes
Learn why hostname lookups fail, how to read each stage of resolution, which errors mean what, and how to fix propagation, caching, and resolver problems.
A DNS resolution failure means a hostname could not be turned into an address, so no connection was ever attempted. It is the earliest possible failure in any network request.
1. What Happens During Resolution
- The client checks its own cache and hosts file.
- It asks its configured resolver.
- The resolver checks its cache, then walks from the root to the authoritative servers.
- An answer, or an authoritative "does not exist", returns and is cached for the record's TTL.
Each stage can fail independently, and caching means a fix may not be visible immediately.
2. Reading the Error
| Symptom | Meaning |
|---|---|
NXDOMAIN |
The name authoritatively does not exist |
SERVFAIL |
The resolver failed, often a broken delegation or signature |
| Timeout | The resolver did not answer at all |
| Resolves to the wrong address | Stale cache, or a hosts-file entry |
| Resolves inside but not outside | A split-horizon or internal-only zone |
NXDOMAIN and SERVFAIL are different problems: one is a missing record, the other a broken server or chain.
3. Diagnosing It
dig +trace example.com
dig @1.1.1.1 example.com
dig @8.8.8.8 example.com
The trace shows where the walk stops. Querying two public resolvers separates a local resolver problem from an authoritative one — if both agree and your machine disagrees, the fault is local.
Check the hosts file too; a stale manual entry silently overrides DNS entirely.
4. Common Causes
- Record missing or mistyped, including a trailing-dot mistake in the zone.
- Propagation delay after a change, bounded by the previous TTL rather than by any global clock.
- Nameserver delegation wrong at the registrar, so the authoritative servers are never consulted.
- Local resolver failure — a router's DNS service or a VPN's resolver.
- DNSSEC validation failure producing
SERVFAILwhere an unvalidating resolver would answer. - Hosts file entries left over from testing.
5. Fixing It
- Verify the record exists at the authoritative nameservers, not just at a public resolver.
- Wait out the TTL. Lower TTLs before planned changes rather than after.
- Flush local caches on the machine, and restart the browser, which keeps its own.
- Try another resolver to confirm whether the fault is local.
- Check the registrar's delegation matches the DNS provider's nameservers.
- Remove hosts-file overrides once testing is finished.
6. In Automated Collection
Resolution failures at scale usually indicate resolver capacity or rate limiting rather than a missing record — a burst of concurrent lookups can overwhelm a small resolver.
Reuse connections so fewer lookups are needed, respect record TTLs rather than caching indefinitely, and treat a sudden rise in failures as a resolver problem before suspecting the target.
7. Real-World Examples
- A migration where the registrar still delegates to the previous provider's nameservers.
- A VPN resolver that answers for internal names and fails for public ones.
- A stale hosts entry pointing a production hostname at a retired address.
- A crawler exhausting a local resolver's throughput and seeing widespread, unrelated failures.
8. Summary
DNS failures stop a request before any connection is attempted, and the response type — NXDOMAIN, SERVFAIL, or timeout — identifies whether the record, the chain, or the resolver is at fault.
Compare public resolvers against the authoritative servers, check the local hosts file, and remember that propagation is governed by the old TTL rather than by how recently the change was made.