NXDOMAIN vs SERVFAIL: What DNS Errors Actually Mean

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.

Same empty answer section, completely different meaning. This table is the fastest way to tell which DNS error you are actually looking at:

Rule of thumb: NXDOMAIN is a content problem (the record is missing), while SERVFAIL is an infrastructure problem (the path to the answer is broken).

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. How long that lasts is governed by DNS TTL and negative caching.
• 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.

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.

1. 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. For a quick single-name check first, the online nslookup tool shows NXDOMAIN in plain text.
2. Query the authoritative servers directly with dig. Use +norecurse against 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.
3. Check the parent zone's NS records vs the child zone's NS records. Mismatch = lame delegation.
4. 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.

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.