UtilityKit

500+ fast, free tools. Most run in your browser only; Image & PDF tools upload files to the backend when you run them.

DNSSEC Checker

Look up DS, DNSKEY, and RRSIG records for a domain to confirm DNSSEC is enabled and inspect the chain-of-trust artifacts.

About DNSSEC Checker

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 DNSSEC Checker

  • 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 DNSSEC Checker

  1. Enter the apex domain — for example, example.com.
  2. Click Check DNSSEC to run three parallel queries (DS, DNSKEY, RRSIG).
  3. If all three return rows, the zone is signed and chained to the root.
  4. Inspect the DS records to confirm your registrar published the right delegation signer.
  5. Inspect the DNSKEY records to see the KSK and ZSK published in your zone.
  6. If the result is unsigned, enable DNSSEC at your registrar and DNS provider, then re-run.

When to use DNSSEC Checker

  • 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

Fully signed zone

Input: cloudflare.com

Output: DS: 2 records · DNSKEY: 4 records · RRSIG: many → signed

Unsigned zone

Input: old-corporate.example

Output: DS: 0 · DNSKEY: 0 · RRSIG: 0 → not signed

Broken delegation (DNSKEY but no DS)

Input: newsigner.example

Output: DS: 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.

Explore the category

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.