DNSSEC checker
Check whether a domain is signed with DNSSEC and whether a validating resolver authenticates its answers — the AD flag, plus the DS and DNSKEY records that back it up — straight from your browser over encrypted DNS-over-HTTPS.
Checks whether a domain is signed with DNSSEC and whether Cloudflare — a validating resolver — authenticates its answers. We read the AD flag plus the domain's DS and DNSKEY records. Nothing is stored.
The check runs in your browser against Cloudflare's validating DNS-over-HTTPS resolver. The AD flag reflects Cloudflare's validation, not ours — a non-validating resolver would not set it. We don't log the domains you check.
What DNSSEC actually proves
DNSSEC (DNS Security Extensions)
DNSSEC adds cryptographic signatures to DNS records so a resolver can verify that an answer is authentic and unaltered — that it's really the record the domain owner published, and not something injected on the network path.
- AD
- Authenticated Data — the flag a validating resolver sets once it has cryptographically verified an answer against the DNSSEC chain of trust. It's the resolver vouching for the data, not a signature you check yourself.
- DS
- Delegation Signer — a hash of the zone's signing key, published in the PARENT zone (like .com). It links a domain into the chain of trust. No DS at the parent means the domain isn't really signed, whatever keys it publishes.
- DNSKEY
- The public keys the zone uses to sign its records. Resolvers use them to verify signatures and match them against the parent's DS record.
- RRSIG
- Resource Record Signature — the actual cryptographic signature attached to each set of records. A validating resolver checks each RRSIG against the DNSKEY to confirm the data wasn't altered in transit.
How this check works
When you enter a domain, your browser sends three queries directly to Cloudflare's
DNS-over-HTTPS resolver: an A query with the DNSSEC "DO" bit set, plus DS and
DNSKEY queries. From the A response we read the AD flag
— Cloudflare's verdict on whether the answer validated. From the other two we show whether the
domain actually publishes signing records, and where: a DS lives at the parent zone,
a
DNSKEY lives in the domain's own zone.
We fix the resolver to Cloudflare on purpose. The AD flag only means something when
the resolver performs validation — a non-validating resolver would never set it, even for a flawlessly
signed domain. Cloudflare validates, so its flag is a trustworthy signal.
Because the check reads a live resolver, its verdict is only as honest as the resolver's
answer — and the tool reflects that. If Cloudflare can't be reached, or returns NXDOMAIN for a domain that doesn't exist, it says so rather than guessing. To read a domain's other records,
use the
DNS lookup; to see which public resolvers validate DNSSEC, see the
public DNS servers reference.
DNSSEC checker — frequently asked questions
What does "DNSSEC validated" mean here?
It means Cloudflare — a validating resolver — set the AD (Authenticated Data) flag on the answer. Cloudflare walked the chain of trust from the root down to the domain, checked the DS record at the parent, matched it to the zone's DNSKEY, and verified the RRSIG signatures. The green verdict is Cloudflare vouching that the answer is authentic; your browser is trusting Cloudflare to have done that check honestly over an encrypted connection.
Why does it say signed but not validated?
The domain publishes DNSSEC records (a DNSKEY, sometimes a DS), but Cloudflare would not authenticate the answer. The usual causes are a missing DS record at the parent zone — so the chain of trust is never linked — or an expired key or signature that puts the zone into a "bogus" state. Either way, strict validating resolvers will refuse the answer, which can make the domain unreachable for some users until it's fixed.
Does DNSSEC encrypt my DNS queries?
No. This is the most common misconception. DNSSEC signs DNS records so you can detect tampering, but it does not encrypt anything — anyone on the network path can still see which domains you look up and the answers you get. Privacy comes from an encrypted transport like DNS-over-HTTPS or DNS-over-TLS, which is a separate feature. A domain can have DNSSEC without encryption, encryption without DNSSEC, both, or neither.
My domain is signed but this shows not signed — why?
Almost always because the DS record hasn't been published at the registrar. You can sign a zone and generate DNSKEY records at your DNS host, but DNSSEC only takes effect once the matching DS record is added to the parent zone (usually through your domain registrar). Until then the domain is an "island of security" that resolvers can't connect to the chain of trust, so they treat it as unsigned. Adding the DS record at the registrar links it up.
Which resolver does this use, and why does it matter?
It uses Cloudflare's public DNS-over-HTTPS resolver, which performs DNSSEC validation and reports the result in the AD flag. The resolver matters because the AD flag only means something if the resolver actually validates — a non-validating resolver would never set it, even for a perfectly signed domain. We fix the resolver to Cloudflare so the flag is meaningful and the verdict is honest.
Is DNSSEC the same as the HTTPS padlock?
No. They protect different layers. DNSSEC authenticates DNS answers — it helps ensure the address you resolve for a domain is the real one the owner published. HTTPS (TLS) then encrypts and authenticates the connection to that address once you've resolved it. DNSSEC doesn't secure the web content, and HTTPS doesn't verify the DNS lookup that got you there. Strong setups use both.