Skip to content
ProbeDNS

DNSSEC Checker

DNSSEC signs DNS answers so resolvers can prove they were not tampered with. This checker reports three distinct states — signed and validating, signed but failing validation, and unsigned — by reading the DS and DNSKEY records a zone publishes and comparing what a validating resolver does with them against a resolver that ignores signatures.

The chain of trust, in the order it breaks

DNSSEC works by delegation, exactly like DNS itself. The root zone's key is trusted implicitly (it is shipped with every validating resolver). The root signs a DS record for .com, which is a hash of .com's key-signing key. .com signs a DS record for example.com. Inside example.com, a key-signing key (KSK) signs the zone-signing key (ZSK), and the ZSK signs every record set. Each link is a hash or a signature over the next one down.

  • DS record — lives in the parent zone, published through your registrar. It is a digest of your KSK, and it is what anchors your zone to the chain.
  • DNSKEY records — live in your zone. Flags 257 marks a KSK, 256 a ZSK.
  • RRSIG records — the signatures themselves, one per signed record set.
  • AD bit — set by a validating resolver on an answer whose chain it verified all the way to the root. It is the resolver's assertion, not the zone's.

The break almost always happens at the DS record, because it is the one link that lives outside your DNS provider. Rotate your KSK without updating the DS at the registrar and the digest no longer matches any key you publish. Validation then fails — not with a warning, but with SERVFAIL, which validating resolvers return in place of any answer at all.

How this tool decides

Verdicts here are measured, never inferred from a single flag. Three things are queried in parallel: the DS record set at the parent, the DNSKEY set in the zone, and the zone apex through a validating resolver (Cloudflare 1.1.1.1). If the validating resolver returns SERVFAIL, the same question is repeated with CD=1 (checking disabled) against a second resolver. A zone that answers with checking disabled but SERVFAILs with checking enabled has data that is perfectly reachable and signatures that do not verify — that is a validation failure, and nothing else looks like it.

Read the full explanation of dnssec checker results ↓

The key tags shown are computed locally from each DNSKEY's RDATA using the RFC 4034 Appendix B checksum, so the "matched by DS" column is arithmetic performed here, not a claim repeated from a resolver. When a DS points at a key tag the zone does not publish, you are looking at the cause of the outage directly.

VerdictWhat was observedWhat to do
Signed and validatingDS present, DNSKEY present, AD bit set on the apex answerNothing. Watch key rollovers.
DNSSEC validation failingValidating resolver SERVFAILs; the same query with CD=1 answersUrgent. The domain is invisible to roughly a third of the internet.
Signed, chain incompleteDNSKEY published but no DS at the parent, or no AD bitAdd the DS record at your registrar. Until then the signing does nothing.
Not signedNo DS and no DNSKEYNormal. Enable DNSSEC if you want authenticated answers.
A DNSSEC failure is not a partial outage. Validating resolvers — Google, Cloudflare, Quad9, and most ISPs in Europe — return SERVFAIL for everything in the zone: web, mail, APIs. Non-validating resolvers see nothing wrong at all, which is why the reports say "it works for me" while a large share of your users cannot reach you.

Reading a broken zone

dnssec-failed.org is maintained deliberately broken as a test target, and it shows the classic pattern. The parent publishes a DS record with key tag 42069; the zone publishes a KSK with key tag 50719. No published key hashes to the published DS, so the chain snaps at the parent boundary:

# A validating resolver refuses to answer at all
dig @1.1.1.1 dnssec-failed.org A +noall +comments
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 23932

# The same query with checking disabled answers fine —
# the data is reachable, only the signatures fail
dig @1.1.1.1 +cd +short dnssec-failed.org A
96.99.227.255

# A healthy signed zone: note the "ad" flag
dig +dnssec cloudflare.com A +noall +comments
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

# The DS record the parent publishes for a working zone
dig +noall +answer cloudflare.com DS
cloudflare.com.	10328 IN DS 2371 13 2 32996839A6D808AFE3EB4A795A0E6A7A39A76FC52FF228B22B76F6D63826F2B9
The +cd comparison is the single most useful DNSSEC diagnostic: it separates "signatures broken" from "servers down".

Add dig +sigchase or, more practically on modern systems, delv example.com A +rtrace to walk the chain link by link and see precisely which delegation fails to verify.

Common failures and fixes

  1. Stale DS after a KSK rollover. The commonest DNSSEC outage. Publish the new DS at the registrar, wait for the parent TTL, and only then retire the old key. Never remove the old key first.
  2. Nameserver change with DNSSEC enabled. Moving providers while a DS record exists breaks the zone instantly, because the new provider signs with different keys. Disable DNSSEC at the registrar (remove the DS), wait out the DS TTL, migrate, then re-enable with the new provider's DS.
  3. Expired signatures. RRSIGs have absolute expiry dates, typically 14–30 days. If signing automation stops, the zone works until the day the signatures lapse and then fails everywhere at once, with no configuration change to point at.
  4. DNSKEY published, no DS. The zone is signed but not anchored — resolvers treat it as unsigned. Harmless, but you have none of the protection you think you have. Add the DS at the registrar.
  5. Registrar does not support DNSSEC. Some do not, or support only specific algorithms. Nothing you do in the zone can substitute; the DS must be in the parent.
  6. Algorithm mismatch. The DS digest type or key algorithm the registrar accepts may differ from what your provider generates. Algorithm 13 (ECDSAP256SHA256) with digest type 2 (SHA-256) is the safe modern default.

If a domain is returning SERVFAIL from every resolver and you have ruled out DNSSEC here, the next suspects are the delegation and the nameservers themselves — check both with the NS lookup and the full DNS lookup.

Frequently asked questions

What does it mean if my domain is not signed?
It means the zone publishes no DNSSEC material and resolvers accept its answers without cryptographic verification — the situation for the large majority of domains. It is not an error or a vulnerability in itself. It does mean an attacker who can inject responses on the path between a user and their resolver can forge answers undetectably.
Why does my site work for me but not for others?
That asymmetry is the signature of a DNSSEC failure. Validating resolvers return SERVFAIL for the whole zone while non-validating ones answer normally, so whether a given user can reach you depends entirely on which resolver they use. If this tool reports validation failing, that is your explanation.
How do I fix a DNSSEC validation failure?
Compare the DS records at the parent with the DNSKEY records in the zone — this tool shows both, with computed key tags. If no DS matches a published key, update the DS at your registrar to match your current KSK. If you cannot do that quickly, removing the DS entirely restores service by making the zone unsigned, which is the safe emergency action.
Should I enable DNSSEC?
If your DNS provider signs automatically and your registrar supports DS updates through an API, yes — the ongoing effort is near zero and you gain authenticated answers. If you manage keys by hand, weigh it carefully: an expired signature or a mishandled rollover is a total outage, and DNSSEC outages are harder to diagnose than most.
What is the AD bit?
Authenticated Data: a flag a validating resolver sets on a response whose entire chain of trust it verified back to the root. It is an assertion by the resolver, not by the zone, so it is only meaningful over a trusted path between you and that resolver. This tool reports it alongside the published DS and DNSKEY records rather than relying on it alone.
What is the difference between a KSK and a ZSK?
The key-signing key (flags 257) signs only the DNSKEY record set and is the key your DS record hashes. The zone-signing key (flags 256) signs everything else. Splitting them lets you rotate the ZSK frequently without touching the registrar, while the KSK — the one that requires a parent update — changes rarely.
Does DNSSEC encrypt my DNS queries?
No. DNSSEC provides authentication and integrity, not confidentiality: every record stays publicly readable and every query stays visible on the wire. Encryption of the query path is a separate mechanism — DNS over HTTPS or DNS over TLS — and the two solve different problems.
How long after fixing the DS record will my domain work again?
Up to the TTL of the parent's DS record, usually 3600 to 86400 seconds, plus the negative-cache time for the SERVFAILs already stored. Resolvers cache validation failures for a shorter period than normal answers, so recovery is often faster than the raw TTL suggests — but it is not instant.

Related guides

SERVFAIL vs NXDOMAIN: What Each DNS Error Means

Telling a broken zone apart from a name that simply does not exist.