DNSSEC Checker

Query a domain's DNSKEY record against multiple public DNS resolvers (Google, Cloudflare, and more) to check whether its DNSSEC signature chain validates correctly.

Last updated: 2026-09-20

Diagnosing a DNSSEC chain of trust

This tool queries a domain's DNSKEY records against several public resolvers and reports whether the DNSSEC signatures verify all the way up. It finds the state in which DNSSEC was meant to be enabled but the chain breaks somewhere along the way.

**What DNSSEC protects is that an answer has not been tampered with, not that its contents are secret.** What travels remains as visible as ever; only authenticity is guaranteed. **The omission that occurs most often is forgetting to register the DS record with the parent zone.** You may place keys in your own zone and sign it, but **unless a DS is registered with the parent, `.com` for instance, through your registrar, the chain of trust breaks there and nothing is verified.** Conversely, where a key rollover goes wrong and leaves an inconsistency, **the whole domain becomes unreachable from any resolver that validates.** A half-finished state can therefore be more dangerous than never having enabled it at all.

How to use it

Enter the domain Give the domain alone, in the form `example.com`.
Read the result of the validation **It judges whether the chain of signatures reaches the parent.**
Confirm whether a DS record exists **Where this is missing, nothing is verified however many keys you have placed.**
Compare the answers from several resolvers A discrepancy points either to a cache or to the configuration.

Tips for getting more out of it

The AD (Authenticated Data) flag is only set when the DNS resolver you queried performed DNSSEC validation itself. Resolvers that don't support DNSSEC can't give a meaningful result.
"DNSSEC not enabled" is not an error — most domains still don't use DNSSEC, and it has no direct effect on search ranking or email deliverability.
If validation fails, first check whether the key tag and digest in the DS record registered at your registrar match your current DNSKEY.
DNSSEC signatures (RRSIG) have an expiration date. Confirm that your DNS software's automatic re-signing hasn't stopped.
Right after enabling DNSSEC, validation may briefly show as "failed" until the DS record propagates to the parent zone.

Where it comes in useful

Checking after enabling DNSSEC

**Ticking the box on a control panel very often leaves the job unfinished.**

Seeing a key rollover through

You can confirm across the change of keys that validation has not broken.

Isolating why a name will not resolve

**A DNSSEC inconsistency makes the domain look, to some users alone, as though it had vanished.**

Examining a correspondent's domain

It tells you how far they have taken their own measures.

DNSSEC terms

DNSKEY: The record holding a zone's public key, used in verifying the signatures.
DS record: **The record registering the fingerprint of a child zone's key with the parent zone.** Without it the chain of trust breaks.
RRSIG: The signature itself, attached to each record. It carries an expiry and is renewed at intervals.
Chain of trust: The structure by which signatures link from the root through the parent to the child. **A break at any single point makes validation impossible.**
Key rollover: The work of replacing a key with a new one. **Getting the procedure wrong makes the whole domain unreachable.**
Validating resolver: A resolver that actually checks the DNSSEC signatures. **Where an inconsistency exists, it returns no answer at all.**

Frequently Asked Questions

"DNSSEC not enabled" by itself is not dangerous — the large majority of domains still operate without it. That said, enabling it is worth considering as a defense against DNS cache poisoning if you have the option.

Users on resolvers that enforce DNSSEC (many corporate networks and some ISPs) may be unable to resolve the domain at all, since it gets treated as SERVFAIL. Unless this is a temporary state right after enabling DNSSEC while the DS record propagates, it needs prompt fixing.

Right after a DNSKEY rollover (key rotation), old and new keys can briefly coexist across resolver caches, causing validation results to differ temporarily. Wait a while and check again.

No. DNSSEC guarantees that a name-resolution response hasn't been tampered with, while SSL/TLS guarantees that the connection itself is encrypted and that the server holds the certificate it presents. They're independent — a domain can have one without the other.

This tool only checks surface-level status: whether a DNSKEY is published and whether resolvers report the AD flag. For a rigorous analysis of the full signature chain (RRSIG/NSEC/NSEC3 consistency, etc.), pair this with a specialized tool such as dnsviz.net.

Side Note — Why DNS needed a way to stop spoofing

When DNS was designed in 1983, it had no cryptographic way to confirm who actually sent a response. A resolver trusted any UDP packet that arrived with a plausible-looking transaction ID — a protocol built on good faith, vulnerable to source-IP spoofing and ID guessing. In 2008, security researcher Dan Kaminsky showed the industry that this weakness could be exploited to perform practical, fast cache poisoning attacks (injecting forged records into a resolver's cache), a discovery that sent shockwaves through the DNS community.

DNSSEC (DNS Security Extensions) is the standardized answer to that problem. It uses public-key cryptography to prove that a response was signed by the zone's legitimate operator. A domain signs its records with its DNSKEY, and a DS record registered in the parent zone attests to that key's digest — building an unbroken chain of trust from the DNS root down to the individual domain.

The AD (Authenticated Data) flag in a DoH (DNS over HTTPS) response is the result of the resolver performing that DNSSEC validation on your behalf. Applications don't need to implement signature verification themselves — querying a trusted resolver and seeing AD=true is an indirect assurance that the response wasn't tampered with, provided the transport between the resolver and the app (HTTPS) is separately secured.

Browse all trivia