SERVFAIL is a DNS response code, and it is the least specific one you can get:

The resolver tried to answer your query and could not produce a valid result.

That is deliberately vague, because SERVFAIL covers everything from a broken cryptographic signature to a name server that is simply switched off. The domain probably exists. Something between you and the authoritative answer went wrong.

This makes it harder to diagnose than NXDOMAIN — but there is one command that splits the possibilities in half immediately, and most explanations never mention it.

Where you will see it 

dig example.com ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 18442 
nslookup example.com ** server can't find example.com: SERVFAIL host example.com Host example.com not found: 2(SERVFAIL)

That 2 is the numeric code. NXDOMAIN is 3, SERVFAIL is 2, NOERROR is 0.

In browsers it usually surfaces as DNS_PROBE_FINISHED_NXDOMAIN or ERR_NAME_NOT_RESOLVED — browsers collapse DNS failures into one message, which is exactly why people end up diagnosing the wrong problem. The browser text does not tell you which response code came back. Only a direct query does.

The one command that narrows it immediately 

dig +cd example.com

+cd means checking disabled — it tells the resolver to skip DNSSEC validation and hand you whatever it gets.

  • Works with +cd, fails without it → DNSSEC validation failure. The data is there; the signatures do not check out
  • Fails both ways → the resolver genuinely cannot reach or get a usable answer from the authoritative name servers

That one comparison eliminates roughly half the possible causes. Do it before anything else.

What actually causes it

DNSSEC validation failure

The most common cause on domains that were working yesterday.

DNSSEC signs DNS records cryptographically. If the chain breaks — an expired signature, a DS record at the registry that no longer matches the zone's key, a key rotation done incorrectly, or DNSSEC left enabled after moving to a provider that does not sign — validating resolvers refuse to serve the answer at all.

Refusing is correct behaviour: the alternative is serving data that may have been tampered with.

Those signatures carry expiry dates, so a zone that stops being re-signed breaks at a predictable moment without anyone touching anything. A domain that "broke overnight with no changes" is very often this.

Non-validating resolvers still answer normally, which is why the domain works for some people and not others.

The authoritative name servers are unreachable

Nothing exotic — servers down, host offline, or a firewall blocking port 53. The resolver asked, nothing usable came back.

Lame delegation

The parent zone points at name servers that do not host the zone. They are reachable and they respond — they just have no authoritative data for this domain.

Happens after a migration where name servers were changed at one end but not the other, or where a hosting account was closed while the registrar still points at it.

Inconsistent name servers

A domain lists four name servers; two have the zone, two do not, or they hold different versions. Resolvers pick whichever they like, so the domain resolves intermittently — with no pattern anyone can reproduce.

Query each one individually and compare. If they disagree, you have found it.

EDNS and packet size

DNSSEC-signed responses regularly exceed the 512-byte limit of classic DNS. Some firewalls and older middleboxes drop oversized UDP responses or block fragments outright.

Symptom: small queries work, large ones fail.

dig +bufsize=512 example.com

Succeeds where the default fails → packet size, not DNS data.

SERVFAIL vs NXDOMAIN

They point in opposite directions, and treating one as the other wastes hours.

SERVFAIL — no usable answer arrived. The domain probably exists. The problem is DNSSEC, the name servers, or the path to them.

NXDOMAIN — an authoritative server answered, and the answer was that the name does not exist. The problem is the name itself.

The rule: NXDOMAIN is an answer you should believe. SERVFAIL means try again, against a different resolver, and look at the infrastructure.

How to diagnose it, in order

1. dig +cd. DNSSEC or not. Halves the problem.

2. Try different resolvers.

dig example.com @1.1.1.1 dig example.com @8.8.8.8 dig example.com @9.9.9.9

Some answer and others do not → almost certainly DNSSEC. Cloudflare, Google and Quad9 all validate, but they cache independently, and a resolver holding a pre-breakage answer keeps serving it until that entry expires.

3. Query each delegated name server.

dig NS example.com dig example.com @ns1.provider.com dig example.com @ns2.provider.com

All should agree. Any that times out, refuses, or disagrees is the fault.

4. Trace from the root.

dig +trace example.com

Walks root → TLD → authoritative, showing exactly which step fails. Fastest way to spot a lame delegation.

5. Check what the registry actually has. If the registry's name servers do not match the ones you expect, the delegation was never updated. A DNS lookup from outside your own network shows the delegation as the rest of the internet sees it — full disclosure, that's a free tool I built, and the reason it helps here is that it removes your own resolver's cache from the picture.

If it is DNSSEC

Two options, depending on whether you control the zone.

Fix the chain. Re-sign the zone, or correct the DS record at the registrar so it matches the key the zone actually publishes. This is the proper fix.

Remove DNSSEC. Delete the DS record at the registrar, wait for it to expire from caches, and the domain resolves again unsigned. This is the usual emergency measure, and it removes the protection entirely.

What you cannot do is tell other people's resolvers to ignore the problem. Validation failing is them doing their job.

The short version

SERVFAIL means no usable answer arrived, not that the name is missing — the opposite of NXDOMAIN, which is why people troubleshoot the wrong thing.

Start with dig +cd: if that works and a normal query does not, it is DNSSEC, and the fix is the DS record rather than anything in the zone. If both fail, query each delegated name server individually — one that times out, refuses, or disagrees with the others is your answer.

Originally published at webtoolsrealm.com