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
About this tool
The DNSSEC Checker queries the three records that prove 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). When all three exist, the resolver path is signed end-to-end and validating resolvers (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9) can detect cache poisoning and forged answers. The tool reports each record set count, surfaces the raw values, and flags a domain as unsigned when none exist. Because DNSSEC gates many compliance regimes (federal .gov, finance audits, the baseline for any zone hosting sensitive APIs), confirming the signing posture in seconds is the difference between a passing audit and a back-and-forth. Queries run from our backend against public DNS; nothing is forwarded externally.
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.
Reports per-record-set errors when a query fails, so you can pinpoint a broken delegation.
Confirms chain of trust 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).
- If all three return rows, the zone is signed and chained to the root.
- Inspect the DS records to confirm your registrar published the right delegation signer.
- 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 resultDS: 2 records · DNSKEY: 4 records · RRSIG: many → signed
Inputold-corporate.example
Expected resultDS: 0 · DNSKEY: 0 · RRSIG: 0 → not signed
03Broken delegation (DNSKEY but no DS)
Expected resultDS: 0 · DNSKEY: 4 · RRSIG: many → signed in zone but not chained — registrar missing 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?⌄
No. The lookups run from our backend directly against public DNS resolvers. The domain is not stored, logged, or shared.
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. Validating resolvers will treat it as insecure (not signed). 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.