Why does DNSSEC cause SERVFAIL?

When a validating resolver cannot verify a domain's signatures against the DS record in the parent zone, it treats the answer as possibly forged and returns SERVFAIL instead.

How do I know if a SERVFAIL is caused by DNSSEC?

Repeat the query with checking disabled, for example dig @1.1.1.1 example.com +cd. If the answer appears with +cd but not without it, DNSSEC validation is what is failing.

Should I disable DNSSEC before changing DNS provider?

Either remove the DS record at your registrar and wait for its TTL to pass before switching, or set up signing at the new provider and publish its DS record first. Leaving the old DS in place is the most common cause of DNSSEC outages.

How do I fix a DS record mismatch?

Update the DS record at your registrar to match the current key-signing key your DNS provider publishes, or remove it if the zone is no longer signed.

DNSSEC Validation Failed? Fix DS Mismatch & SERVFAIL

When DNSSEC breaks, it breaks loudly: validating resolvers—including the large public ones and many ISPs—return SERVFAIL and the domain disappears for a large share of users. Users of non-validating resolvers see nothing wrong, which makes these outages confusing. Nearly all of them come down to a handful of causes.

First: confirm it is really DNSSEC

SERVFAIL has other causes too, such as unreachable nameservers. The quickest test is to repeat the query with checking disabled (the CD flag), which tells a validating resolver to skip validation:

dig @1.1.1.1 example.com A          ; SERVFAIL
dig @1.1.1.1 example.com A +cd      ; NOERROR with an answer

If the answer appears with +cd, the data is reachable and validation is what's failing. Modern resolvers often explain why with an Extended DNS Error (RFC 8914) in the response, for example "DNSKEY missing" or "Signature expired".

1. Stale DS record after changing DNS provider

This is by far the most common failure. A domain is signed at provider A, with a DS record at the registrar. The owner moves DNS to provider B and updates the nameservers—but the old DS record stays at the registrar.

If provider B doesn't sign the zone, the parent says "this zone is signed" but the zone has no DNSKEY records. Validation fails.
If provider B does sign, it uses its own keys, which don't match the old DS. Validation fails.

Fix: remove the old DS record at the registrar, or replace it with the DS from the new provider. The safe order for a move is: remove the DS, wait for the DS TTL plus a margin (often a day or two), move the nameservers, then enable DNSSEC at the new provider and publish its DS.

2. DS record doesn't match any key

Even without a provider change, the DS record can point to a key the zone no longer publishes. This happens after a KSK rollover where the registrar's DS was not updated, or when a DS was copied with a typo, the wrong digest type or the wrong algorithm number.

The key tag in the DS must match a DNSKEY, and recomputing the digest from that DNSKEY must give exactly the published digest. The DNSSEC Chain Validator does that recomputation and tells you whether there is no key with that tag, or the tag matches but the digest differs.

Fix: copy the current DS record from your DNS provider into the registrar's DNSSEC settings, and remove DS records that no longer match.

3. Expired signatures

Every RRSIG has an expiration time. Signers refresh them automatically, typically days or weeks before expiry. If the signing process stops—a broken cron job, a disabled signer, a secondary server that stopped receiving updates—signatures eventually expire and validation fails on a schedule nobody planned.

The reverse also occurs: signatures with an inception time in the future, usually because the signing host's clock is wrong.

Fix: restart or repair the signer, or ask your DNS provider. Then check that every nameserver serves the freshly signed zone.

4. Inconsistent nameservers

With several nameservers, all of them must serve the same signed data. Validation then depends on which server a resolver happens to ask:

a secondary server still serves an old, unsigned copy of the zone;
two DNS providers each sign the zone with their own keys, but neither publishes the other's keys;
a rollover has completed on some servers but not others.

The result is intermittent failure, which is hard to reproduce. Comparing the DNSKEY set from every nameserver, as the validator does, shows it immediately. Multi-provider DNSSEC is possible but requires the providers to share keys (RFC 8901).

5. Deprecated or unsupported algorithms

Zones signed with old algorithms such as RSA/SHA-1 (algorithm 5 or 7) are increasingly treated as insecure by validators: the domain keeps resolving but silently loses its protection. Similarly, SHA-1 DS digests (digest type 1) are deprecated. Neither causes an outage today, but both are worth replacing with ECDSA P-256 (algorithm 13) and SHA-256 DS digests.

A recovery checklist

Confirm the failure is DNSSEC (SERVFAIL without +cd, an answer with it).
Compare the parent's DS records with the zone's DNSKEY records.
If you no longer want DNSSEC, or need the domain back now, remove the DS records at the registrar. Resolvers recover once the cached DS expires (check the DS TTL in the parent zone).
Otherwise update the DS to match the current KSK, or fix signing at the provider.
Re-check every nameserver, and re-run the validator after the old TTLs have passed.

Removing a DS record is always safe from a resolution point of view—it turns a bogus domain into an insecure one. Adding a wrong one is what causes outages.