DNSSEC Check

Check DNSSEC validation across 14 global resolvers at once. See exactly which resolvers cryptographically verified your domain — and catch a broken signature chain before it takes you offline.

What this checks

Most DNSSEC tools ask one question: is this zone signed? This one asks a more useful question: which resolvers actually validated it? Every lookup queries 14 public resolvers in parallel and reads the AD (Authenticated Data) bit each one returns — the flag a resolver sets when it has cryptographically verified the answer against the DNSSEC chain of trust.

That distinction matters because signing and validating are different things, done by different parties. Cloudflare Radar data for July 2026 put 8.22% of DNS queries against signed domains but only 0.62% validated end-to-end — a roughly 13× gap between "protected in theory" and "protected in practice."

How to read the DNSSEC column

• ✓ signed — this resolver validated the answer. This is the only positive proof of anything.
• not validated — the resolver did not assert validation. Ambiguous on purpose: it means either the zone is unsigned or that resolver doesn't validate DNSSEC. We don't guess which.
• bogus? — the resolver returned SERVFAIL, which on a validating resolver usually means the signature chain failed.
• — — the resolver didn't report the AD bit, so we say nothing.

The split that reveals a broken signature

A broken DNSSEC chain doesn't produce a warning. It fails closed: validating resolvers return SERVFAIL and the domain simply vanishes for their users, while non-validating resolvers keep serving the record as if nothing is wrong. If you test from a network using a non-validating resolver, the site looks perfectly fine to you while a large share of the internet cannot reach it at all.

That split is the fingerprint, and querying one resolver can never show it. Try the known-broken test domain dnssec-failed.org: most resolvers return SERVFAIL, while a handful still answer with an IP address. Seeing both halves side by side is the fastest way to confirm you're looking at a signature problem and not a propagation delay.

Common causes of a DNSSEC failure

• Expired RRSIG — signatures have their own expiry, separate from the record's TTL. If automatic re-signing breaks, the zone goes bogus on a timer.
• DS / DNSKEY mismatch — the DS record at the parent registry no longer matches the zone's DNSKEY. Usually caused by a key rollover, or by moving DNS providers without updating the DS record at the registrar.
• Enabling DNSSEC at the registrar before the new provider is serving signed data, or disabling signing while the DS record is still published.

FAQ

What does the AD bit actually mean?

AD stands for Authenticated Data (RFC 4035). When a resolver sets it, it is asserting that it verified the record's signatures up the chain of trust to the root. It is the resolver's claim about its own validation, not a property of the zone itself.

Why does one resolver say validated and another doesn't?

Because validation is the resolver's choice. Many large public resolvers validate by default; plenty of others don't validate at all. In practice this splits along regional lines too — some national resolvers return answers for domains that validating resolvers reject.

Is "not validated" a problem?

Not necessarily. Most domains on the internet are still unsigned, and an unsigned domain works normally — it just isn't protected against forged DNS answers. It's only a red flag when you expect the zone to be signed and no resolver confirms it.

My domain returns SERVFAIL everywhere. What do I do?

Check whether the DS record at your registrar matches your current DNSKEY. If they've drifted apart — typically after a provider migration or key rollover — removing the DS record restores resolution immediately (unsigned but reachable), and you can re-enable DNSSEC once the new keys are correct. Use the DS lookup and DNSKEY lookup to compare them.

Does DNSSEC encrypt my DNS queries?

No, and this is the most common misconception. DNSSEC provides authenticity — proof an answer wasn't forged — but the queries are still plaintext. Encryption is a separate transport concern handled by DoH or DoT, which is what this site uses to reach every resolver.

Background reading

See the DNSSEC glossary entry and the DNS Records Explained guide. To inspect the underlying records directly, use the DNSKEY and DS lookups.