When DNSSEC breaks a domain: SERVFAIL, DS records and how to recover
The most confusing DNSSEC failure looks like an outage that only some people see. A site loads fine for you and fails for a customer. It works on your phone's mobile data and not on the office network. Nothing in your records looks wrong, and dig returns the right answer.
That pattern, working on some resolvers and failing on others, is the signature of a DNSSEC problem. This post explains why it happens, the three ways it goes wrong, and how to find and fix each one. For what DNSSEC is and how to enable it in the first place, start with DNSSEC explained.
Why it fails for some people only
A DNSSEC signature is only checked by a resolver that validates. Many large public resolvers do, including Cloudflare's and Google's, and many internet providers do. Some do not. When the chain of trust for a domain is broken, a validating resolver does not return the data with a warning. It returns an error, usually SERVFAIL, and the domain fails to resolve. A resolver that does not validate happily returns the same records and everything looks fine.
So the symptoms split by resolver, not by anything you did recently, which is why the problem is easy to misdiagnose as a network issue.
The chain, briefly
The chain runs from the root down. The root vouches for the top level domain, the top level domain vouches for your domain through a DS record published in the parent zone, and the DS record points to a key your own zone publishes as a DNSKEY. That key signs the rest of your zone's keys. Break any link and a validating resolver refuses everything below it.
The DNSSEC Validator walks this chain, verifying each signature from the root trust anchor down and reporting which link fails and why.
Failure one: the DS record points at nothing
This is the most common way a domain goes dark. DNSSEC is switched off at the DNS provider, which removes the zone's keys, but the DS record at the registrar stays. The parent still says "this zone is signed", the zone no longer is, and every validating resolver rejects it.
It also happens when you move DNS to a new provider that does not sign your zone, or has signed it with different keys. The old DS record no longer matches anything.
What the validator shows: the parent publishes a DS record for your domain, but the zone publishes no keys, or none that match.
The fix: either re-enable signing at your DNS provider and update the DS record to match its keys, or remove the DS record at your registrar so the domain is simply unsigned.
Failure two: the DS record does not match the keys
A key rollover goes wrong, or you switch providers and publish the new provider's keys without updating the DS record. The zone has keys, the parent has a DS record, but they refer to different keys.
The DNS provider and the registrar are two separate systems, and the DS record is the one value that has to be correct in both worlds. That is why this fails so often.
As a concrete example, dnssec-failed.org is a deliberately broken domain used to test whether a resolver validates. Checked on 4 November 2026, its parent published a DS record for key tag 42069 while the zone published keys with tags 50719 and 32784. Nothing matches, so validating resolvers reject it. The tool reports exactly that mismatch.
The fix: get the current key signing key details from your DNS provider and update the DS record at your registrar to match. Or remove the DS record if you no longer want DNSSEC.
Failure three: the signatures expired
DNSSEC signatures are valid for a limited time and must be renewed. If the system that signs your zone stops, the signatures lapse and the domain breaks on the day they do, with no change on your side and no warning.
This is more common with self run signing than with a managed provider, but it affects both. The date a signature expires is shown in the validator's report so you can see how much time you have, and a domain with a few days left is one to look at.
The fix: get the zone re-signed. With a managed provider, contact them. If you run your own, check that the signer is running and that its key files are readable.
How to diagnose
You can reproduce the symptom yourself with dig. The +cd flag means "checking disabled" and asks a validating resolver to return the data without validating it:
dig @1.1.1.1 example.com A # SERVFAIL if the chain is broken
dig @1.1.1.1 example.com A +cd # returns the records anyway
If the first query fails and the second succeeds, the data is fine and DNSSEC is the problem. If both fail, it is something else. The ad flag in a normal response means the resolver validated the answer.
The validator uses the same technique, which is why it can still diagnose a domain that validating resolvers refuse to answer for.
The safe order for moving DNS providers
Most DNSSEC outages are self inflicted during a move. The safe order is:
- Remove the DS record at your registrar first.
- Wait for the old DS record to expire from caches. Resolvers keep it for its TTL, which is commonly a day for popular top level domains, so wait at least that long.
- Change the nameservers to the new provider.
- Confirm the zone resolves correctly without DNSSEC.
- Enable signing at the new provider, and publish its DS record at your registrar.
- Verify the chain with the validator once the new DS record has propagated.
The key idea is that the parent's DS record should never point at keys that are not live. Doing it in the opposite order, or all at once, is what creates the window of failure. For planning the timing, see DNS TTL planning for a migration, and DNS propagation explained for why changes appear at different times in different places.
What the validator does and does not check
It verifies the chain of trust: the root keys against the published trust anchor, each DS record's signature, that a DS record matches a key the zone really publishes, and that the zone's key set is signed. It reports the algorithm and when the signature expires.
It does not verify the signature on each individual record such as A or MX, and it does not verify the proofs a zone gives that a name does not exist. A domain can pass the chain check and still have a problem at that level, though the failures above account for the large majority of real outages. It supports RSA, ECDSA and Ed25519, and flags SHA-1 based RSA as deprecated.
An unsigned domain is reported as unprotected, not as broken. Not using DNSSEC is a valid choice, and the validator treats it that way.
A routine
If a domain works on some networks and not others, run the validator before anything else. If it reports broken, read which link and the plain explanation, and fix that one thing. If you are about to change providers or roll a key, follow the order above and verify afterwards. Look at the rest of the domain with Domain X-ray, and read each record with DNS Lookup.