DNSSEC validation failed: how to find the cause and fix it

When DNSSEC validation fails, the domain does not slow down or show a warning. It disappears. Resolvers that check signatures, which includes Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1), Quad9 and most mobile networks, answer SERVFAIL, and the browser says the site cannot be found. Mail servers that validate stop delivering to you and queue the mail instead.

It often looks random. The site works on your office network, because the office resolver does not validate, and fails on your phone. That mix is the first hint that DNSSEC is the cause and not the server.

Almost every failure we see comes from one of four things. In rough order of how often they happen:

What broke	The reason a resolver gives	Usual trigger
The DS record at the registry matches no key in the zone	DNSKEY Missing (no SEP matching the DS found)	A move to a new DNS host, or a key change, with the old DS left in place
The zone is not signed at all, or only partly	DNSKEY Missing, or RRSIGs Missing	The new DNS host does not sign, or two providers share the nameservers and only one signs
The signatures ran out	Signature Expired, or Signature Not Yet Valid	A self-run signer that stopped, nameservers serving an old copy, a disabled signing key
Algorithm or digest problems	Unsupported DNSKEY Algorithm, Unsupported DS Digest Type, or DNSSEC Bogus	Old RSA/SHA-1 keys, or a DS record copied with a typo

The names in the middle column are Extended DNS Errors, a list of reasons defined in RFC 8914 that resolvers attach to a SERVFAIL. Cloudflare's resolver sends them, and the Warnwell DNSSEC checker shows the one it got next to the result.

How DNSSEC validation works, in one paragraph

There are three links in the chain. The registry for your top-level domain (.com, .org, .de) holds a DS record: a fingerprint of your zone's key-signing key, which you or your DNS host gave the registrar. Your zone publishes that key as a DNSKEY record. Each set of records in the zone carries an RRSIG, a signature made with the zone's keys, valid between two dates. A validating resolver walks the chain from the root down (RFC 4035). If the DS matches a DNSKEY, the DNSKEY verifies the RRSIG, and the RRSIG is inside its dates, the answer is marked authentic. If any link fails, the answer is bogus, and the resolver throws it away rather than hand it to you. No DS record at the registry means the domain is simply unsigned, and nothing is checked.

That last point matters for the fix. The DS record is the switch. Delete it at the registrar and validating resolvers stop checking, whatever state the zone is in.

How to test DNSSEC on a domain

Paste the domain into the DNSSEC checker. It asks the registry for a DS record and asks a validating resolver for the domain's records twice, once normally and once with checking switched off. You get one of four answers:

Warnwell says	Meaning
DNSSEC on	A DS record exists and the answers validate.
DNSSEC off	No DS record. Nothing to fix, nothing protected.
DNS is signed wrong (DNSSEC)	A DS record exists, the normal question fails and the unchecked one answers. This is a validation failure, and the result names the reason the resolver gave.
DNSSEC on, but not checked	A DS record exists, but resolvers do not check it, usually because of an old algorithm. See the algorithm section below.

To see the same thing in a terminal, dig does it in three commands:

# Is DNSSEC switched on at the registry?
dig DS example.com +short
# Look for "ad" in the flags line, or status: SERVFAIL
dig example.com @1.1.1.1 +dnssec
# The same with validation off (+cd)
dig example.com @1.1.1.1 +cd

If the second command gives SERVFAIL and the third gives an answer, DNSSEC is the problem and the server is fine. Recent versions of dig print the Extended DNS Error under "OPT PSEUDOSECTION" as an EDE line. For a picture of the whole chain, DNSViz draws every key and signature and marks the broken link in red.

Cause 1: a DS record that matches no key

This is the one behind most of the "signed wrong" results the checker finds. The registry holds a DS record for a key your zone no longer publishes, so the chain breaks at the first link. Cloudflare's resolver calls it "DNSKEY Missing" with the detail "no SEP matching the DS found" (SEP, secure entry point, is the key-signing key).

How it happens:

• Moving DNS to a new host with DNSSEC on. The old host signed the zone, its DS sits at the registry, and the new host signs with a different key or not at all. Leaving Cloudflare is the classic case: Cloudflare-signed zones have a DS record that starts 2371 13 2 on every one we have checked, so if dig DS shows key tag 2371 and your nameservers are no longer Cloudflare's, you have found it.
• A key change where the new DS never reached the registry, or the old key was removed before the new DS was live. RFC 7583 explains the safe order of steps, and the short version is that the new DS has to be at the registry, and old copies of the DS gone from resolver caches, before the old key goes.
• A registrar transfer that also changed the nameservers. The transfer itself keeps the DS at the registry. The trouble starts when the new registrar's setup moves the domain onto its own DNS, which signs with another key or not at all.
• A typo when pasting the DS. One wrong character in the digest, or the wrong algorithm number in the form, and the DS points at nothing.

To confirm it, compare the key tag in the DS record with the key tags in the zone:

dig DS example.com +short
# The key with flags 257 is the key-signing key, and its "key id" is the tag
dig DNSKEY example.com +cd +multi

If no DNSKEY has the tag the DS names, or there is no DNSKEY at all, this is your cause.

The fix, fastest first: delete the DS record at the registrar. The domain resolves again for everyone once resolvers drop the old DS from their cache (see the timing section below). Then switch on signing at the DNS host you use now and add the new DS it gives you. If the domain must not go unsigned even for a day, the alternative is the multi-signer setup in RFC 8901, where old and new host both publish each other's keys during the move. Cloudflare supports it, but for most domains a day unsigned is the smaller risk.

For a planned move, do it in this order and nothing breaks: remove the DS at the registrar, wait at least the DS record's time to live (TTL) (one day for .com, see the table below), move the nameservers, wait for the new host to serve the zone, then switch on DNSSEC there and add its DS.

Cause 2: the zone is not signed, or only partly

A DS record at the registry promises that the zone is signed. If the nameservers serve no DNSKEY at all, resolvers report "DNSKEY Missing", same as cause 1. If the zone has keys but some records come back without signatures, the reason is "RRSIGs Missing".

The partial case is the hard one to spot because it fails some of the time. It happens when a domain lists nameservers from two providers, say two from the registrar's DNS and two from a CDN, and only one provider signs. A resolver that happens to ask a signing server gets a good answer, and the next one gets SERVFAIL. Check each nameserver in turn:

dig NS example.com +short
# Then, for every name in that list:
dig @ns1.example-host.net example.com DNSKEY +short

Every nameserver must answer with the same keys. The fix is to use one provider's nameservers only, or set the two up as multi-signers. If neither is possible today, remove the DS record until it is.

Cause 3: the signatures expired

Every RRSIG carries an inception and an expiration time (RFC 4034, section 3.1.5). The DNS host re-signs the zone well before the end date. Managed hosts such as Cloudflare and Route 53 do this for you and it rarely fails there. When it does fail, Cloudflare's resolver says "Signature Expired", and the checker shows that reason.

Where it goes wrong:

• A signer you run yourself (BIND, Knot, PowerDNS, OpenDNSSEC) that stopped re-signing: a crashed process, a full disk, key files the server can no longer read, a cron job removed in a server move. Everything keeps working until the last signatures run out, which can be weeks later, so nobody links the failure to the change.
• Secondary nameservers serving an old copy. If zone transfers from the primary stop, secondaries keep serving the last copy until the SOA expire timer runs out, often two to four weeks. That is longer than many signers' signature lifetime, so the old copy's signatures die first.
• Route 53 losing access to its signing key. Route 53 signs with a key held in AWS KMS. If someone disables or deletes that key, or removes Route 53's permission to use it, signing stops and the signatures run out. CloudWatch reports it as DNSSECKeySigningKeysNeedingAction.
• A wrong clock. A signer whose clock runs ahead makes signatures that start in the future, which resolvers reject as "Signature Not Yet Valid". A validating resolver with a wrong clock fails every signed domain, which is a different problem and usually on your own machine.

To read the dates, ask for the SOA record with its signature:

dig example.com SOA +dnssec +cd +multi

In the RRSIG line, the first long number is the expiration and the second the inception, both as YYYYMMDDHHMMSS in UTC. An expiration in the past is the answer.

The fix is to get the signer running and re-sign the zone, then check that every nameserver serves the new SOA serial. If that will take more than an hour, remove the DS record meanwhile so the domain works unsigned, and add it back once the zone is signed again.

Cause 4: algorithm and digest problems

Each DNSKEY has an algorithm number and each DS record a digest type. RFC 8624 set out which ones to use. RFC 9904 (November 2025) moved that list into an IANA registry, and RFC 9905 retired SHA-1:

Number	Algorithm	Status
1, 3, 6, 12	RSA/MD5, DSA, DSA-NSEC3, GOST	Must not be used for signing
5, 7	RSA/SHA-1	Must not be used for signing, and validators must treat them as unsupported (RFC 9905)
8	RSA/SHA-256	Must be supported
13	ECDSA P-256 with SHA-256	Must be supported. What Cloudflare and Route 53 use.
15	Ed25519	Recommended

A resolver that does not support a zone's algorithm treats the zone as unsigned (RFC 4035, section 5.2). So an old algorithm does not take the domain offline. It just stops protecting it, and Cloudflare reports "Unsupported DNSKEY Algorithm". That is what the checker's "DNSSEC on, but not checked" means. A DS record with digest type 1 (SHA-1) is the same story: new DS records must not use it. Use digest type 2 (SHA-256).

The fix is to move to algorithm 13. Changing algorithm in place has its own careful order (RFC 6781, section 4.1.4), and on a managed DNS host the simpler path is to remove the DS, wait one TTL, switch DNSSEC off and on again so the host makes a new key, and add the new DS.

"DNSSEC Bogus" is the catch-all: a signature that does not verify against its key. On a managed host it is rare and worth a support ticket. On a self-run signer it usually means records were edited in the signed zone file by hand, so re-sign the zone.

Where to fix it: registrar and DNS host

Two places are involved, and they are often different companies. The DS record lives at the registrar (where you pay for the domain). The keys and signatures live at the DNS host (whoever runs the nameservers). The checker shows both.

Where	Turn signing on or off	Add or remove the DS record
Cloudflare (DNS)	DNS, Settings, DNSSEC. Turning it on shows the DS record to copy.	If the domain is registered at Cloudflare too, it adds the DS for you within a day or two. Elsewhere, copy it to the registrar. To switch off, remove the DS first and keep signing on for 24 to 48 hours, as Cloudflare's own docs say.
Amazon Route 53	Hosted zone, DNSSEC signing, Enable. It needs a customer managed KMS key in us-east-1 (asymmetric, ECC_NIST_P256).	Domains registered with Route 53: Registered domains, the domain, DNSSEC keys. Route 53 asks for the public key rather than a DS, and makes the DS itself. Elsewhere, copy the DS from "View information to create DS record".
GoDaddy	On GoDaddy's own nameservers, the DNSSEC switch in the domain's DNS settings. Each account gets 5 free DNSSEC credits, and more domains need its paid Premium DNS.	For a domain on other nameservers: Domain Settings, DNS, DS Records, Add, with the key tag, algorithm, digest type and digest from your DNS host.
Namecheap	With Namecheap's own DNS: Domain List, Manage, Advanced DNS, DNSSEC switch. Namecheap signs and adds the DS itself.	With other nameservers, the same DNSSEC section takes the DS values from your DNS host.
Any other registrar	Look for DNSSEC in the domain's DNS or nameserver settings.	The form asks for the same four fields. Some ask for the public key instead and work out the DS themselves.

Some registries can do the DS part for you. With CDS and CDNSKEY records (RFC 7344, RFC 8078), the DNS host publishes the DS it wants in the zone, and the registry picks it up. The registries for .ch, .li, .cz, .se and .nu, among others, work this way, and Cloudflare publishes the records for zones it signs. On .com it still goes through the registrar.

How long until it works again

Resolvers keep a DS record for its time to live (TTL). After you remove or fix it at the registrar, the registry publishes the change within minutes on most top-level domains, but a resolver that cached the old one keeps using it until the TTL runs out. We checked these on 3 November 2026:

Top-level domain	DS record TTL
.com, .net, .de, .eu	86400 seconds (24 hours)
.dk	7200 seconds (2 hours)
.org, .uk, .nl, .se, .ch	3600 seconds (1 hour)

You can speed up the two biggest resolvers by hand. Google has a flush cache page and Cloudflare a purge cache page. Clear the domain name there for the record types A, AAAA and MX, then run the checker again.

Should you keep DNSSEC on?

Yes, if someone looks after the domain and knows it is signed. It stops forged DNS answers from sending your visitors or your mail somewhere else, and on Cloudflare it costs nothing and takes two minutes.

No, if the domain changes hands or DNS hosts often and nobody owns the checklist. A signed domain with a forgotten DS record is down for most of the internet, and an unsigned one is not. If you do keep it on, put a DNSSEC check on your list for the day after any DNS move. More fixes like this one are in the guides.

Questions

What does "DNSSEC validation failed" mean?

A resolver that checks signatures followed the chain from the registry's DS record to your zone's keys and signatures, and one link did not match. It then refuses to answer (SERVFAIL), so the domain does not load for anyone using that resolver.

How do I check if DNSSEC is enabled on a domain?

Look for a DS record at the registry: dig DS example.com +short. Any output means DNSSEC is switched on. To see whether it also validates, run the domain through the DNSSEC checker, or look for the ad flag in dig example.com @1.1.1.1 +dnssec.

Why does my site work for me but not for others?

Your resolver probably does not validate DNSSEC, and theirs does. Google Public DNS, Cloudflare 1.1.1.1, Quad9 and many mobile networks validate. Test with dig example.com @8.8.8.8: SERVFAIL there, and an answer with +cd added, means DNSSEC is the cause.

Is it safe to delete the DS record?

Yes. Without a DS record resolvers treat the domain as unsigned and stop checking, so a broken zone works again. You lose the protection DNSSEC gives until you add a correct DS record back, nothing else.

How long does a DS record change take?

The registry usually publishes it within minutes. Resolvers that cached the old record keep it for its TTL: 24 hours on .com, .net, .de and .eu, 1 hour on .org, .uk and .nl.