DNS SERVFAIL — DNSSEC, Delegation, and Resolver Failures

Diagnose DNS SERVFAIL by comparing resolvers, checking the authoritative servers, validating DNSSEC with delv, and fixing delegation or zone-signing problems.

advanceddebuggingdnsdnssec

Symptoms

dig returns status: SERVFAIL for a domain that used to resolve
Some resolvers fail while others return an answer
The failure affects every record type for the zone
Public resolvers return SERVFAIL but the authoritative server answers directly

Possible causes

The authoritative nameservers are unreachable or return inconsistent answers
DNSSEC validation fails because signatures expired or the DS record does not match
The delegation is lame: parent NS records point to servers not authoritative for the zone
The recursive resolver has a broken forwarder or a stale negative cache
The zone file has a syntax error that prevents loading on the primary

Diagnosis steps

Confirm the failure and which resolver produced it

dig +noall +comments example.com

Interpretation

The status line names SERVFAIL and the SERVER line shows the resolver used. Repeat against a public resolver to see whether the problem is local or global.

Ask authoritative servers directly

dig @ns1.example.com example.com SOA +norecurse

Interpretation

A NOERROR answer with the SOA proves the zone is loaded and authoritative. Timeouts or REFUSED point to server reachability or ACLs rather than DNSSEC.

Validate the DNSSEC chain

delv example.com && dig +dnssec example.com | grep -E 'status|RRSIG|ad;'

Interpretation

delv reports secure, insecure, bogus, or indeterminate. Bogus means validation failed, usually an expired signature, missing DNSKEY, or mismatched DS.

Check the delegation from the parent

dig +trace example.com | tail -30

Interpretation

The trace shows the referral chain. A missing glue record, wrong NS target, or a parent that does not delegate to the current servers explains a lame delegation.

Root cause

SERVFAIL means the resolver could not produce an answer, not that the name does not exist. The cause is either operational (authoritative servers unreachable or inconsistent) or DNSSEC validation (missing or expired signatures, DS mismatch). A lame delegation sends the resolver to servers that are not authoritative, and the resolver ultimately gives up with SERVFAIL instead of NXDOMAIN.

Fix

Restore authoritative service and consistent zone data, fix delegation NS and glue records at the registrar, and repair DNSSEC by publishing the correct DNSKEY and DS records and re-signing the zone before signatures expire. If only one resolver is affected, fix its forwarders or clear its cache. Do not disable DNSSEC validation to make a broken zone resolve.

Risk note

Removing DS records disables DNSSEC protection for the entire zone and propagates slowly. Changing NS records during an outage can extend the failure through TTL caches. Flushing resolver caches hides the symptom without repairing the delegation.

Verify the fix

Query the authoritative servers and at least two public resolvers and confirm NOERROR with consistent answers. Run delv and verify the zone reports secure, then check that the previous SERVFAIL is gone after the TTL window.

SERVFAIL means “I could not answer”

It does not mean the name is absent; that is NXDOMAIN. SERVFAIL says the resolver failed, whether because the authoritative servers are unreachable, inconsistent, or failed DNSSEC validation.

dig +noall +comments example.com
dig @1.1.1.1 example.com +noall +comments
dig @ns1.example.com example.com SOA +norecurse

If the authoritative server answers directly but public resolvers return SERVFAIL, the zone data is reachable and the problem is delegation or validation.

Test DNSSEC explicitly

delv example.com
dig +dnssec example.com | grep -E "status|RRSIG|ad;"
dig +trace example.com | tail -30

delv classifies the result as secure, insecure, bogus, or indeterminate. Bogus points to an expired RRSIG, a missing DNSKEY, or a DS record that does not match the current key. The trace exposes lame delegation and missing glue.

Repair the chain

Ensure every NS record in the parent resolves and is authoritative for the zone.
Publish matching DNSKEY and DS records; re-sign the zone before signature expiry.
Keep SOA serials increasing so secondaries transfer.
If only one resolver fails, fix its forwarders and cache rather than changing the zone.

rndc sign example.com
rndc reload

Verify

Query the authoritative servers and two public resolvers; all should return NOERROR with the same answer. delv should report secure, and the SERVFAIL should disappear after the negative cache TTL expires. If it persists, re-check the parent delegation before touching DNSSEC again.