DNSSEC check: is this domain signed, and does the chain validate?
Enter a domain and AdminKit's free tool asks a validating resolver whether that zone publishes DNSSEC key material (DNSKEY, DS records) and whether the signature chain actually validates, returning a live secure, insecure or bogus verdict today rather than guessing from record syntax alone, backed by a real DNS query, not a static parser.
Part of the DNS cluster — more tools, guides and terms on dns.
AI explanation Run a check below, then sign in to ask AI to explain the result in plain language.
What the result means
"Insecure" just means unsigned — nothing is broken. "Bogus" means the zone is signed but the chain doesn't validate right now, which breaks resolution the moment a caller's resolver actually enforces DNSSEC.
Next step
See the domain's raw DNSKEY, DS and RRSIG records to find exactly what's signed, or compare how different public resolvers answer the same query.
Keep this result
Copy a link to this check so you can share it or run it again later. Want a heads-up if something changes? That's early access, not a live feature yet — tell us and we'll set it up by hand.
How it works and limits
This tool sends a real DNS query through AdminKit’s live Check API (POST /v1/check/dns with options.dnssec: true) rather than only parsing a record’s syntax offline. It looks for DNSKEY and DS records
to confirm the zone is signed at all, then probes an A record through a validating resolver and reads back
whether the resolver’s authenticated-data (AD) flag came back set — the same signal a validating resolver gives
any client, without this tool re-implementing DNSSEC signature cryptography itself.
How it works
- Secure: the zone publishes DNSKEY/DS key material and the probe query’s AD flag is set — the RRSIG/DNSKEY/DS chain validates end to end (RFC 4033, RFC 4035).
- Insecure: no DNSKEY or DS records exist for this zone at all. This is not a failure — most of the internet is still unsigned — just a hardening opportunity left on the table.
- Bogus: the zone publishes DNSKEY/DS key material, but the probe query either fails outright (a validating resolver SERVFAILs when signature validation breaks) or succeeds without the AD flag set. This is a real outage-in-waiting: the moment a caller’s own resolver starts validating, every query against this zone starts failing for them.
Limits
- This checks one resolver’s live validation verdict for one record type at one moment — it does not independently re-verify every RRSIG in the chain itself, and a different resolver could in principle behave differently if it doesn’t validate DNSSEC at all.
- A “bogus” result means something is broken in the signing chain right now (expired signature, mismatched DS after a key rollover) — it does not diagnose which specific step broke; use the DNS lookup tool to inspect the zone’s actual DNSKEY, DS and RRSIG records directly.
- No query is logged; see /legal/privacy/.
See DNSSEC: what it actually protects — and what it doesn’t for the full threat model and common misconceptions (it authenticates, it does not encrypt). The glossary entry for DNSSEC covers the DNSKEY/RRSIG/DS terms in one place, and the DNS resolver test lets you compare how different public resolvers answer the same query if you suspect only your own resolver isn’t validating.
Frequently asked questions
What does a 'secure' DNSSEC verdict actually guarantee?
It means the zone publishes DNSKEY/DS key material and a validating resolver's query for this domain came back with the authenticated-data (AD) flag set — RFC 4033 defines this as the resolver cryptographically confirming the answer really came from the domain's authoritative owner and wasn't forged or altered in transit (RFC 4033 §2). It says nothing about the content behind the domain, only that the DNS answer itself is genuine.
Why would an already-signed domain show 'bogus' instead of 'secure'?
Bogus means the zone publishes DNSKEY/DS records but the signature chain doesn't validate — RFC 4035 §5 describes a validating resolver either refusing to answer (SERVFAIL) or returning an answer without the AD flag set when a response's RRSIGs don't check out. The most common real-world cause is an expired RRSIG or a DS record at the registrar that no longer matches the zone's current DNSKEY after a key rollover.
Does DNSSEC encrypt my DNS queries?
No — DNSSEC (RFC 4033 §3) only adds authenticity, letting a resolver verify a response wasn't forged or tampered with; queries and answers still travel in plaintext, visible to anyone on the network path. DNS-over-HTTPS or DNS-over-TLS address confidentiality, which is a separate problem DNSSEC does not solve.
Is DNSSEC mandatory for a domain to resolve normally?
No — it's opt-in at both ends: the domain's DNS provider has to sign the zone and publish a DS record at the registrar, and the resolver doing the lookup has to actually validate rather than just accept unsigned answers. RFC 9364 (BCP 237) recommends operators deploy and validate DNSSEC as current best practice, but an unsigned ('insecure') zone still resolves completely normally everywhere — it's a missed hardening opportunity, not a broken domain.