DNSSEC validation failed (SERVFAIL)

What’s actually happening

The domain looks completely dead to anyone on a validating resolver (1.1.1.1, 8.8.8.8, most ISPs), but it resolves fine if you turn validation off. That split is the tell. A broken signature or DS mismatch is treated as a possible attack, so the resolver refuses to hand back records at all — it fails closed. This is a hard outage for real users, not a warning, which is why it sits at critical.

Common causes

• Expired RRSIG records — signatures have a validity window and lapse if not re-signed
• DS record at the registry doesn't match the live DNSKEY (bad or stale digest)
• Key rollover done incorrectly, leaving the chain broken mid-transition
• DNSSEC enabled at the DNS host but the DS was never published at the registrar (or vice versa)
• Zone re-signed or migrated to a new provider without updating the DS at the parent

How to fix it

1. Prove it's DNSSEC, not general SERVFAILdig +cd example.com (checking disabled) bypasses validation. If +cd returns records but a normal query is SERVFAIL, validation is the cause. delv example.com spells out which step failed.
2. Get the exact failure from dnsvizRun the domain through dnsviz.net or the dnsviz CLI. It shows expired RRSIGs, DS/DNSKEY mismatches, and broken delegations as a chain diagram — this tells you which record to fix.
3. Re-align the DS with the current DNSKEYPull the live key (dig DNSKEY example.com), generate the matching DS, and update it at the registrar so the parent delegation matches. Mismatched DS is the single most common cause.
4. Re-sign an expired zoneIf RRSIGs are past their expiry, trigger re-signing at your DNS provider (or dnssec-signzone for self-hosted BIND). Confirm new RRSIG expiration dates are in the future.
5. Roll back if mid-rolloverIf a key rollover broke the chain, restore the previous DNSKEY/DS pairing so validation succeeds, then redo the rollover following the double-signing or pre-publish steps in order.