Guides · DNS
NXDOMAIN vs SERVFAIL: What DNS Errors Actually Mean
NXDOMAIN means the name does not exist. SERVFAIL means the resolver could not get a clean answer. Two different problems, two different fixes.
By Cody · 5 min read · Published
The short version
Both are DNS response codes (RCODEs), but they describe completely different failure modes:
- NXDOMAIN (RCODE 3) — the authoritative server answered, and the answer is “that name does not exist.”
- SERVFAIL (RCODE 2) — the resolver could not produce a definitive answer. Something on the path failed.
NXDOMAIN is a successful query with a negative answer. SERVFAIL is an unsuccessful query. Treat them differently.
What causes NXDOMAIN
NXDOMAIN appears when an authoritative server answers and says the queried name does not exist in the zone. Common real-world causes:
- The record was never created (typo, wrong subdomain).
- The record was deleted but a resolver still has the old answer cached as negative.
- The zone is correct upstream but the wrong nameservers are listed at the registrar.
- Wildcard logic that should match the name does not.
The fix is almost always at the zone: add or correct the record. There is nothing wrong with DNS infrastructure when NXDOMAIN appears — the system is working as designed.
What causes SERVFAIL
SERVFAIL means the resolver wanted to answer and couldn't. The interesting causes are not at the zone but along the path:
- Authoritative nameservers unreachable. All listed NS hosts are down, firewalled, or returning timeouts.
- Lame delegation. The parent zone lists nameservers that have never heard of the child zone. Common after registrar moves.
- DNSSEC validation failure. A validating resolver detected a broken or missing chain of trust. Symptom: 1.1.1.1 returns SERVFAIL, an unvalidating resolver returns the record fine.
- Response too large with no TCP fallback. Rare today but still happens with restrictive middleboxes.
SERVFAIL almost always means somebody's operations problem, not a missing record.
How to diagnose, in order
- Run the query against multiple resolvers using the DNS resolver comparison tool. If some return the answer and some return SERVFAIL, you have a DNSSEC or partial-outage problem. If all agree on NXDOMAIN, the record really does not exist.
- Query the authoritative servers directly with dig. Use
+norecurseagainst the NS hosts listed at the parent. If they answer, the zone is healthy and the resolver is the problem; if they SERVFAIL or time out, the zone is the problem. - Check the parent zone's NS records vs the child zone's NS records. Mismatch = lame delegation.
- If DNSSEC is involved, validate the DS / DNSKEY chain. A registrar-side DS that no longer matches the published DNSKEY produces SERVFAIL on every validating resolver.
Why the right fix matters
Treating SERVFAIL like NXDOMAIN — “the record must be missing, let me add it” — wastes time and sometimes adds wrong records. Treating NXDOMAIN like SERVFAIL — “the resolver is broken, ignore the answer” — keeps you debugging infrastructure that is doing exactly what it should.
When in doubt, the comparison tool tells you which one you have within seconds: same answer from every resolver means the zone agrees; divergent answers mean the path is broken.
Distinguishing the two with dig
- Example input
dig +short A nope.example.com && dig +short A broken-dnssec.example- Example result
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 12345 ;; ANSWER SECTION: (empty) ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 67890 ;; ANSWER SECTION: (empty)
Both look empty if you only inspect the answer section. The status line is what tells you which failure mode you are in.
Related tools
FAQ
Is SERVFAIL my fault or my DNS provider's fault?
Usually the authoritative side — the nameservers for the zone are unreachable, mismatched, or returning broken DNSSEC. If a public resolver like 1.1.1.1 returns SERVFAIL but a different one returns the answer, the failure is intermittent and resolver-specific; otherwise it is almost certainly the authoritative servers.
Why does dig say NXDOMAIN but the site loads in my browser?
Your browser may be using a different resolver (corporate DNS, VPN, DoH inside the browser itself) that still has a positive cached answer, while your shell uses the system resolver where the record has already expired or been removed. Check with multiple resolvers using the comparison tool.
How long do resolvers cache NXDOMAIN?
Negative caching is bounded by the SOA minimum TTL of the parent zone, capped at 24 hours by RFC 2308. In practice most public resolvers cap it lower (1–4 hours). If you just created a record and it still reports NXDOMAIN, you are waiting on negative caching to expire.
Does SERVFAIL mean a security problem?
Not by itself, but DNSSEC validation failures surface as SERVFAIL — and those can mean the chain is broken or, less commonly, that something is tampering with responses. If SERVFAIL appears only from validating resolvers (1.1.1.1, 9.9.9.9) and not from non-validating ones, suspect DNSSEC.
What is REFUSED and how is it different?
REFUSED means the server you asked refuses to answer for that zone at all — usually because it is not authoritative and not configured as an open recursor. NXDOMAIN says "that name does not exist"; REFUSED says "do not ask me about that zone."
Last reviewed: 2026-05-14.