Is SERVFAIL the same as NXDOMAIN?

No, and the difference points you at completely different fixes. NXDOMAIN (RCODE 3) is an answer: an authoritative server did the work and told you the name does not exist. SERVFAIL (RCODE 2) is the absence of an answer — the resolver tried to resolve the name and couldn't finish, so it gives up with 'server failure.' NXDOMAIN means 'this name is gone'; SERVFAIL means 'I couldn't get a trustworthy answer.' One is about the domain, the other is about the resolution path.

Why does SERVFAIL come and go for the same domain?

Intermittent SERVFAIL usually means one of several authoritative nameservers is broken while others are fine. Resolvers pick a nameserver per query, so you get a good answer when they hit a healthy server and SERVFAIL when they hit the broken one. Expired DNSSEC signatures behave the same way across resolvers: an unvalidating resolver answers, a validating one returns SERVFAIL. If results differ by resolver, the domain's DNS is inconsistent, not your machine.

I just enabled DNSSEC and now I get SERVFAIL — why?

Almost always a broken chain of trust. The most common cause is a missing or wrong DS record at your registrar: you signed the zone, but the parent zone still has no DS record (or an old one), so validating resolvers can't link your keys to the trust anchor and return SERVFAIL. The other frequent cause is expired RRSIG signatures because the zone wasn't re-signed in time. Run dig +cd to confirm it's validation, then compare the DS at the parent against your live DNSKEY.

Views: 7

DNS SERVFAIL: Fix Server Failure Responses

DNS SERVFAIL means the resolver tried and failed — usually DNSSEC or a dead nameserver. Split the cause in 4 checks. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

A lookup returns status: SERVFAIL, or an application reports “DNS server failure” / “temporary failure in name resolution.” The name doesn’t resolve, but the resolver isn’t telling you the domain is gone — it’s telling you it gave up.

Symptoms

dig or nslookup shows status: SERVFAIL in the header.
The site loads on some networks or some devices but not others.
It started right after a DNSSEC change, a nameserver migration, or a key rollover.
The same name resolves fine when you query a different DNS server.

What SERVFAIL Actually Means

SERVFAIL is DNS response code 2 (RFC 1035). It is the resolver’s way of saying “I tried to answer your question and something went wrong before I could.” That “something” is deliberately vague in the protocol — the resolver doesn’t get to explain itself, it just hands back RCODE 2 and moves on. Which is exactly why SERVFAIL feels so unhelpful: it’s an error about the process of resolving, not about the name.

The single most important distinction: SERVFAIL is not NXDOMAIN. NXDOMAIN is a real answer from an authoritative server — the name does not exist, full stop. SERVFAIL means the resolver never got an answer it could trust. So the suspects aren’t “is the domain registered?” They’re “can the resolver reach the authoritative servers, and does what comes back validate?” In modern DNS, by far the most common reason a perfectly valid answer gets rejected is DNSSEC: a validating resolver receives the records, fails to verify the signatures against the chain of trust, and turns a good answer into SERVFAIL on purpose.

Top 3 Causes

DNSSEC validation failure - The zone is signed, but the chain of trust is broken: a missing or stale DS record at the registrar after a key rollover, an expired RRSIG signature because the zone wasn’t re-signed in time, or a DNSKEY that no longer matches the published DS. A validating resolver refuses to serve records it can’t verify and returns SERVFAIL — even though the records are correct. The tell: dig +cd (checking disabled) returns the answer while a normal query returns SERVFAIL.
All authoritative nameservers are failing - Every nameserver for the zone is down, timing out, or refusing the query, so the resolver exhausts its options and gives up. This includes lame delegation — the parent zone delegates to nameservers that aren’t actually authoritative for the zone — and firewalls that silently drop DNS on port 53. If even one nameserver answered correctly, you’d get a real response; SERVFAIL here means none of them did.
The resolver itself is broken or overloaded - A misconfigured forwarder, an upstream resolver that’s down, or a cache holding a poisoned/failed entry can manufacture SERVFAIL even when the domain’s own DNS is healthy. The tell here is the mirror image of cause #1: the name resolves fine from 1.1.1.1 or 8.8.8.8 but SERVFAILs through your configured resolver.

Diagnose with DechoNet

DNS Check queries the name from outside your network. If it returns clean records while your machine shows SERVFAIL, the domain’s DNS is fine and your resolver is the problem. If it also fails, the fault is in the zone — DNSSEC or the nameservers.
Propagation Check asks several independent resolvers at once. If some answer and others SERVFAIL, you’ve found an inconsistency: a broken nameserver in the set, or a DNSSEC failure that only validating resolvers reject.

Resolution Checklist

Confirm the RCODE: dig example.com and read the status: line. SERVFAIL, not NXDOMAIN, is what this guide fixes.
Isolate DNSSEC: dig +cd example.com. If the answer comes back with checking disabled but SERVFAILs without it, the problem is validation, not the records.
If it’s DNSSEC, compare the parent’s DS against your live keys: dig DS example.com (at the parent) versus dig DNSKEY example.com (at your authoritative server). A mismatch or missing DS after a key change is the usual culprit.
Check RRSIG expiry: dig RRSIG example.com and look at the signature expiration field. An unsigned-in-time zone fails validation for everyone.
Query each authoritative nameserver directly: dig @ns1.example.com example.com. A server that times out or refuses is your broken delegation.
Rule out your own resolver: retry against 1.1.1.1 and 8.8.8.8. If those succeed, fix or replace your local/upstream resolver and flush its cache.

When to Escalate

If dig +cd succeeds but normal queries SERVFAIL, this is a DNSSEC problem only the domain operator can fix — correct the DS record at the registrar or re-sign the zone. No client-side change will help.
If every authoritative nameserver fails to answer, escalate to whoever runs the DNS: the delegation is lame or the servers are down, and resolvers worldwide are getting the same SERVFAIL you are.