DNSSEC Validation Failed: Fix the SERVFAIL

Problem

A signed zone returns status: SERVFAIL, and you’ve already ruled out a dead nameserver — the authoritative servers answer fine when you ask them directly. The records are correct. The name still won’t resolve through any validating resolver. This is the cruelest DNS failure mode: DNSSEC is rejecting a correct answer on purpose because it can’t prove the answer is authentic.

Symptoms

• dig example.com returns SERVFAIL, but dig +cd example.com returns the records.
• The domain went dark right after a key rollover, a DNS provider migration, or enabling DNSSEC for the first time.
• It resolves on some networks (non-validating resolvers) and SERVFAILs on others (1.1.1.1, 8.8.8.8, Quad9).
• A resolver that supports Extended DNS Errors returns a specific reason like “DNSSEC Bogus” or “Signature Expired.”

What “Validation Failed” Actually Means

DNSSEC doesn’t encrypt anything. All it does is let a resolver verify that the answer it got is the answer the zone’s owner actually published. It does this with a chain of signatures: the root zone vouches for the TLD, the TLD vouches for your domain via a DS record, and your domain signs its own records with a DNSKEY, producing an RRSIG signature on every record set.

A validating resolver walks that chain from the root down. If any single link doesn’t hold — the DS at the parent doesn’t match your DNSKEY, an RRSIG has expired, a signature covers the wrong key — the resolver does not degrade gracefully. It does not serve the record “just this once.” It returns SERVFAIL, the same generic code you’d get from a dead server, because the protocol deliberately refuses to hand back data it can’t authenticate. That’s the entire point of DNSSEC, and it’s also why one stale record at your registrar can erase your domain from a third of the internet.

The good news: modern resolvers can now tell you which link broke. RFC 8914 added Extended DNS Errors (EDE), a code attached to the SERVFAIL that names the failure. The ones you’ll actually see:

• EDE 6 — DNSSEC Bogus: validation failed, generic.
• EDE 7 — Signature Expired: an RRSIG’s validity window has passed.
• EDE 8 — Signature Not Yet Valid: the RRSIG’s start time is in the future (usually a clock-skew or premature-publish problem).
• EDE 9 — DNSKEY Missing: the parent has a DS record, but no matching DNSKEY exists in the child zone.
• EDE 10 — RRSIGs Missing: records that should be signed have no signature.

If your resolver reports one of these, it has already done your triage for you.

Top 3 Causes

1. DS / DNSKEY mismatch after a key rollover — The single most common cause. You generated a new key signing key but the DS record at your registrar still points at the old one (or was never published). The parent zone is now vouching for a key your zone no longer uses, so the chain of trust snaps. This produces EDE 9 (DNSKEY Missing) or a generic Bogus. The fix is at the registrar: publish a DS that matches your live KSK, and don’t retire the old key until the new DS has propagated past its TTL.
2. Expired RRSIG signatures — Unlike TLS certificates, DNSSEC signatures have a short validity window (often a couple of weeks) and the zone must be re-signed before they lapse. If your signing automation breaks or a manual zone wasn’t re-signed in time, every signature expires at once and validating resolvers return EDE 7 (Signature Expired) worldwide — even though nothing about the records changed. The tell: it worked yesterday and nobody touched DNS.
3. Algorithm or digest mismatch — The DS record commits to a specific signing algorithm and digest type. If you migrate DNS providers and the new provider signs with a different algorithm, or you publish a DS with the wrong digest, validating resolvers can’t reconcile the parent’s DS with the child’s keys. Common during provider migrations where DNSSEC was “carried over” without re-coordinating the DS.

Diagnose with DechoNet

• DNS Check queries the name from outside your network and shows the records the authoritative servers actually return. If the records are present and correct but the name still SERVFAILs through validating resolvers, you’ve confirmed the records are fine and the chain is broken — look at the DS and signatures, not the zone contents.
• Propagation Check asks several independent resolvers at once. A signed zone with a broken chain shows a clean split: validating resolvers SERVFAIL while non-validating ones answer. That split is the fingerprint of a DNSSEC failure rather than a dead nameserver, which fails everywhere.

Resolution Checklist

• Confirm it’s validation: dig +cd example.com returns the answer while dig example.com returns SERVFAIL. If +cd also fails, this is not a DNSSEC problem — go check the nameservers.
• Read the Extended DNS Error if your resolver provides one: dig example.com and look for the EDE: line in the output. Codes 6–10 each point at a different fix.
• Compare parent and child: dig DS example.com @<parent-ns> versus dig DNSKEY example.com. The DS digest must match one of your published DNSKEYs. A mismatch after a rollover is the classic kill.
• Check signature freshness: dig RRSIG example.com and read the expiration field. A past date means the zone wasn’t re-signed in time — fix the signing pipeline and re-sign.
• Run a chain analyzer like DNSViz or delv example.com (which prints the validation path and the exact reason it fails) for a full top-to-bottom view of where the chain breaks.
• If you can’t fix the DS in time and the outage is live, the emergency stop is to remove DNSSEC entirely: delete the DS record at the registrar. Resolvers stop validating and serve the unsigned zone. It’s a rollback, not a fix, but it ends the outage.

When to Escalate

• A DS/DNSKEY mismatch can only be corrected by whoever controls the registrar account — the parent zone, not your DNS provider, holds the DS. If those are different vendors, you’ll need both.
• Expired signatures on a managed DNS provider are the provider’s automation failing. If re-signing isn’t something you trigger yourself, open a ticket — and treat repeat lapses as a reason to leave.
• If delv and DNSViz both show a clean, validating chain but a specific resolver still SERVFAILs, the fault is that resolver’s cache holding a stale bogus result. It clears on its own after the TTL; nothing on your side will speed it up.