Embed this tool on your site
About this tool
The DNSSEC Checker looks up the three record types that show a zone is cryptographically signed: DS at the parent (delegation signer, links your zone into the chain of trust), DNSKEY at your zone (public KSK and ZSK), and RRSIG (signatures over each RRset). The queries are sent from our backend to Cloudflare's public DNS-over-HTTPS resolver, so Cloudflare sees the domain name. The tool prints each record set with a count and its raw values, and shows a Signed banner when DS or DNSKEY records exist or Cloudflare flags the answer as validated, or Not signed when none exist. It checks presence only: it does not verify signatures or confirm the chain of trust, and a zone with DNSKEY but no DS still shows Signed, so look at the DS block yourself. When all three exist, validating resolvers (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9) can use them to detect cache poisoning and forged answers. DNSSEC is required by some compliance regimes, such as federal .gov domains.
Why use it
Three parallel record-set lookups give a fast yes/no on DNSSEC posture.
Surfaces raw DS, DNSKEY, and RRSIG content for offline auditing.
Lists the error for any record type whose lookup failed or timed out.
Shows DS, DNSKEY and RRSIG presence without needing dig +dnssec on the command line.
Pairs with our DNS Lookup Tool and DNS Propagation Checker for full zone diagnostics.
Backend queries are hardened against SSRF — only valid public hostnames pass through.
How to use
- Enter the apex domain — for example, example.com.
- Click Check DNSSEC to run three parallel queries (DS, DNSKEY, RRSIG).
- Read the banner: Signed means DS or DNSKEY records were found (or the resolver validated the answer); Not signed means none were.
- Inspect the DS block to confirm your registrar published a delegation signer — an empty DS block means the zone is not chained to its parent.
- Inspect the DNSKEY records to see the KSK and ZSK published in your zone.
- If the result is unsigned, enable DNSSEC at your registrar and DNS provider, then re-run.
When it helps
- When a compliance regime (federal .gov, certain financial audits) requires DNSSEC.
- After enabling DNSSEC at your registrar, to verify the DS record propagated.
- While debugging resolver failures that point to broken DNSSEC signatures.
- Before issuing a certificate that depends on DANE (TLSA records).
- During a registrar transfer to confirm DNSSEC continuity (or detect a broken handoff).
- On any domain hosting sensitive APIs as a zero-cost defense against cache poisoning.
Examples
Expected resultGreen "Signed (DNSSEC records present)" banner, then DS, DNSKEY and RRSIG blocks, each with a record count and the raw records returned.
Inputold-corporate.example
Expected resultDS: 0 · DNSKEY: 0 · RRSIG: 0 → not signed
Expected resultBanner still reads "Signed (DNSSEC records present)" because DNSKEY records exist; the DS block shows (0) and "No records." — the sign that the registrar has not published DS.
Tips
- Both DS at the parent and DNSKEY at the zone are required — neither alone makes the zone signed.
- If RRSIG appears but DS does not, the zone is signed but not chained — registrar didn't publish DS.
- Use a validating resolver (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9) when testing — non-validating resolvers won't catch broken signatures.
- Schedule DNSSEC-key rollovers carefully; a stale DS at the parent breaks resolution for everyone.
- Pair DNSSEC with DANE (TLSA) for full email-transport authentication on top of MTA-STS.
Frequently Asked Questions
Is the queried domain forwarded to any third party?⌄
Yes, to Cloudflare. Our backend sends the DS, DNSKEY and RRSIG queries to Cloudflare's public DNS-over-HTTPS resolver (cloudflare-dns.com), so Cloudflare sees the domain name. UtilityKit does not store it.
How does this compare to dnschecker.org or mxtoolbox?⌄
Functionally similar — both check DS/DNSKEY/RRSIG. Ours is free, signup-free, and shows the raw record content alongside the signed/unsigned banner. We don't (yet) verify each RRSIG cryptographically — the existence check is the practical baseline.
What does it mean if DNSKEY exists but DS does not?⌄
Your zone is signed internally but not chained to the parent, and validating resolvers will treat it as insecure. Note that this tool still shows the Signed banner in that case; check whether the DS block is empty. Fix it by publishing the DS record at your registrar.
Can this detect a broken DNSSEC chain or expired RRSIG?⌄
It detects record-set absence (a chain break by absence). It does not yet verify each signature cryptographically — for that, dig +dnssec @<validator> example.com is more thorough.
Why is DNSSEC important for email and TLS?⌄
DNSSEC underpins DANE (TLSA records), MTA-STS resilience, and any DNS-based proof. It also protects against cache poisoning that could redirect traffic to an attacker-controlled IP.
What's the difference between KSK and ZSK?⌄
KSK (Key Signing Key) signs the DNSKEY RRset only — it's the trust anchor. ZSK (Zone Signing Key) signs all other RRsets and is rotated more frequently. Both appear in the DNSKEY query output.
Does enabling DNSSEC slow down DNS queries?⌄
Negligibly. Modern resolvers add a few milliseconds for signature verification. The latency win from anycast caching dominates.
What does it mean if my registrar doesn't support DNSSEC?⌄
You cannot publish a DS record, so even a self-signed zone is not chained to the root. Move to a registrar that supports DS publishing — most major ones do.
Glossary
- DNSSEC
- DNS Security Extensions — RFC 4033/4034/4035 — adds cryptographic signatures to DNS responses, defeating cache poisoning and forged answers when validating resolvers are used.
- DS record
- Delegation Signer — published in the parent zone — links your zone into the chain of trust by hashing one of your DNSKEYs.
- DNSKEY record
- Public-key material published in your zone. KSK (Key Signing Key) signs the DNSKEY set; ZSK (Zone Signing Key) signs every other RRset.
- RRSIG record
- Cryptographic signature over an RRset, generated by the ZSK. Validating resolvers verify RRSIGs against the DNSKEY before trusting an answer.
- Chain of trust
- The sequence DS at parent → DNSKEY at zone → RRSIG over RRset. A break anywhere downgrades the zone to insecure.
- Anycast DNS
- An IP-routing technique where many physical servers share one IP — useful for global DNS but unrelated to DNSSEC. Validating resolvers run on anycast clouds.
A LITTLE HELP. A LOT DONE.
Good tools.
Great flow.
Your shortcut to the everyday. Create, convert, calculate,
and get back to what you love.
✳
✳
✓ Free to use✓ No sign-up✓ 500+ possibilities