Check DNSSEC for a domain: keys, the DS at the parent, signature expiry and the AD verdict
Runs in your browser. Only the lookup you start is sent to cloudflare-dns.com or dns.google; nothing else leaves your device. Updated on 18 Oct 2026.A DNSSEC checker asks a validating resolver for a domain's DNSKEY, its DS record at the parent and the RRSIG signatures, then reads the AD flag. Key 257 is the key-signing key the DS must match; algorithm 13 (ECDSA P-256) is what most zones use today. SERVFAIL that answers with checking disabled means validation is failing.
Type the zone in Domain name (the zone, such as example.com) and press Check DNSSEC.
Read the verdict at the top and whether the resolver set the AD (Authenticated Data) flag.
Check the DS table: Matches a DNSKEY should say Yes, digest recomputed.
Read the RRSIG table to see how long each signature has left.
Press Copy report to copy the whole result.
Type a domain and the page asks one public resolver, Cloudflare or Google, four questions over DNS-over-HTTPS with the DNSSEC bit set: the zone's DNSKEY records, the DS record its parent publishes, the NSEC3PARAM record, and the signatures that come back with each. Those answers are then read for you.
The verdict comes from the resolver itself. A validating resolver sets the AD (Authenticated Data) flag only when every signature from the root down to your domain checked out. When the DNSKEY question fails with SERVFAIL, the page asks again with the CD (checking disabled) flag; if that second answer works, the zone is signed but broken, and the page says plainly that validation is failing. Cloudflare's extended error text, such as "DNSKEY Missing", is shown when it gives one.
Keys are listed with their flags decoded (256 is a zone-signing key, 257 a key-signing key), the algorithm by number and name, and the key size. Each algorithm is shown against RFC 8624's signing column and the IANA registry that replaced it in 2025, so RSA/SHA-1 (algorithms 5 and 7), now marked MUST NOT, stands out.
Key tags and DS digests are recomputed in your browser. The tag is worked out from the key bytes as RFC 4034 Appendix B describes, and the DS digest is hashed again with WebCrypto, so "the DS matches the key" is checked here, not taken on trust.
Signatures show their inception and expiration in UTC and the days left. NSEC3 settings are compared with RFC 9276, which asks for zero extra iterations and no salt.
What it does not do: it does not verify the signatures itself (the resolver does that), it does not walk the chain above the parent, and it cannot see a problem that only one of your nameservers has, because a resolver's cache may hide it. Only the domain name is sent, and only to the resolver you pick.
Enter the domain and press Check DNSSEC. A green Secure verdict means the resolver validated the answer and set the AD flag. Unsigned means there is no DS record at the parent. Not linked means the zone has keys but the registrar never received the DS record, so nobody trusts them yet.
The resolver answered SERVFAIL with validation on, yet answered normally with checking disabled. So the zone is signed but something does not check out: the DS at the registrar points at a key the zone no longer publishes, or a signature has expired. Validating resolvers then refuse to answer for the whole domain.
Both are DNSKEY records. Flags 257 mark the key-signing key, whose hash the parent holds as the DS record and which signs only the key set. Flags 256 mark the zone-signing key, which signs every other record. Splitting them lets the zone key change often without touching the registrar.
Algorithm 13, ECDSA P-256 with SHA-256, is marked MUST in RFC 8624 and is what most DNS hosts use. Algorithm 8, RSA/SHA-256, is also fine, and 15, Ed25519, is recommended. Algorithms 5 and 7 use SHA-1 and must no longer be used for signing.
RFC 4034 Appendix B defines it: the DNSKEY data (flags, protocol, algorithm and key) is added up as 16-bit numbers, the overflow is folded back in, and the low 16 bits are the tag. The page does this in your browser and uses it to find which key each DS record points at.
No. The domain name goes to the resolver you choose, Cloudflare or Google, as four DNS questions over HTTPS. The key tags and digests are then worked out on your own device with the browser's WebCrypto. Nothing is stored, and no other server is contacted.
Still stuck? Ask about DNSSEC Checker and anybody who knows can answer. No account needed.
Same job, other tools: AAAA Record Lookup (IPv6) – Check whether a domain has an IPv6 address, and what it is · NS Lookup – Find the name servers a domain is delegated to, and how long resolvers cache them · AS Number Lookup – Turn an AS number into the network name, registry and allocation date · IP to ASN Lookup – Map an IP address to the ASN that announces it, with the BGP prefix.
On the related tools: Open Port Checker – See if a port forwarded on your router is reachable from the internet.
Also works as: RRSIG Lookup · NSEC3PARAM Lookup.