SERVFAIL after enabling DNSSEC: DS mismatch and expired signatures

2026-06-21 · dnssec · dns · servfail · ds-record · troubleshooting

dnssecdnsservfailds-recordtroubleshooting

If your domain returns SERVFAIL from validating resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1) but resolves fine from a non-validating one, DNSSEC validation is broken — the chain of trust no longer links up. The single most common cause is a DS record at your registrar (the parent zone) that does not match the current DNSKEY in your zone, usually after a key rollover or after you turned on signing before publishing the matching DS. The other usual suspects are expired RRSIG signatures because the signer stopped re-signing the zone.

Confirm it is DNSSEC, not the zone

A validation failure looks like a total outage but the records are fine. Query a validating resolver and a non-validating one side by side:

dig @1.1.1.1 example.com A          # SERVFAIL
dig @1.1.1.1 +cd example.com A      # NOERROR — answers come back

The +cd flag (checking disabled) tells the resolver to skip DNSSEC validation. If +cd returns your records and the plain query returns SERVFAIL, the data is intact — the cryptographic chain is what is failing.

Cause 1: DS does not match the DNSKEY

The parent zone holds a DS (Delegation Signer) record that is a hash of your zone's DNSKEY. Validation walks down from the root, and at your delegation it checks that the DS hash matches a key you are actually publishing. If it does not, the chain breaks.

Pull both sides and compare. The DS lives in the parent (your TLD), the DNSKEY in your zone:

dig +short DS example.com @1.1.1.1
dig +short DNSKEY example.com @1.1.1.1

The DS record is keytag algorithm digest-type digest. The key tag at the front must match the tag of a published DNSKEY (the KSK), and the algorithm number must match too. After a key rollover, the registrar often still advertises the DS for the old key — that is the classic break. Mismatched key tag, wrong digest type (SHA-1 DS against a SHA-256-only setup), or an algorithm mismatch all produce the same SERVFAIL.

Cause 2: expired RRSIG signatures

Every signed RRset ships an RRSIG with an inception and expiration timestamp. If your signer stopped re-signing — a broken cron, a paused managed-DNS feature, a key the automation lost access to — the signatures eventually pass their expiration and resolvers reject them as bogus, even though the DS is correct.

dig +dnssec example.com SOA @1.1.1.1

Look at the RRSIG line in the answer. The fields run type-covered, algorithm, labels, original-TTL, then the signature expiration (the fifth field), then inception — both as YYYYMMDDHHMMSS. If the expiration is in the past, the zone is stale. Re-sign it.

Run a full chain validator

Two queries tell you which side is wrong; a chain validator tells you exactly where. Paste your domain into DNSViz or the Verisign DNSSEC debugger and it walks root → TLD → your zone, drawing the break in red — DS/DNSKEY mismatch, missing RRSIG, or expired signature.

Check the DNSSEC chain on your domain →

How to fix it (and how to disable safely)

To fix forward, re-sync the DS at your registrar to the current DNSKEY (publish the new DS, wait out the parent TTL, then retire the old one), and make sure your signer is re-signing so the RRSIGs are current.

If you need to back out, never delete the DNSKEY first — that strands the DS and guarantees SERVFAIL. Remove the DS at the registrar, wait for its TTL to expire so resolvers stop expecting signed data, then unsign the zone. Order matters: parent first, child second.