DNSSEC Checker

Validate the DNSSEC chain of trust: DS, DNSKEY, and RRSIG records for any domain.

Try an example: cloudflare.com · bankofamerica.com · icann.org · nic.cz

How this DNSSEC checker works

DNSSEC (RFC 4033) signs every answer your domain returns from DNS. A validating resolver can then prove the bytes it received are the bytes you published. Without it, anyone on the path between a recipient and your nameservers can swap your MX, SPF, DKIM or TLSA records for their own, and the recipient has no way to tell.

DNSSEC does not encrypt your queries. It does not hide which records you publish. It guarantees integrity, nothing else. That guarantee is what DANE relies on. A TLSA pin without DNSSEC underneath proves nothing, because the TLSA record itself could have been swapped.

Type a domain above and the checker walks the chain of trust from the root zone down to your name. It confirms the parent zone (usually the TLD operator) publishes a DS record, that the DS digest matches the hash of your DNSKEY, and that each signed RRset carries a valid RRSIG. Signatures are verified against the public key, and their inception and expiry timestamps are checked.

KSK and ZSK do different jobs

Both halves of the key pair get inspected on their own. The KSK (Key Signing Key) is long-lived. It signs the DNSKEY RRset and is what the parent's DS points at. The ZSK (Zone Signing Key) rotates more often and signs everything else. The algorithm in use (RSA/SHA-256, ECDSA P-256, Ed25519, and a few legacy options) is shown alongside each key tag.

Multi-resolver validation

Validation runs against Google, Cloudflare and Quad9 in parallel. The AD (Authenticated Data) bit on each response tells you whether the resolver actually verified the chain or just relayed the answer. When a major resolver disagrees with the others, the disagreement is surfaced as a finding rather than averaged away. In practice that usually points at a stale signature one resolver still has cached, a partial DS rollover, or a nameserver answering inconsistently.

Signatures expire, and that is how most zones go dark

RRSIGs carry an explicit expiry. Once the window closes, every validating resolver treats the answer as bogus and resolution stops. The checker takes the earliest expiry across the answer set, shows what percent of the original validity window has been consumed, and colours a sparkline amber under 50% remaining, red under 10%, deeper red under 24 hours.

Our take: the typical DNSSEC outage is not a botched key rollover. It is a re-signing cron that quietly stopped running on a Friday and only fails on Tuesday, once the last signature ages out. The expiry strip is there to catch that a day or two before the zone breaks.

NSEC versus NSEC3

Asking for a record that doesn't exist still needs a signed answer. NSEC does this by naming the next existing label in the zone, which means anyone can walk the zone and enumerate every record. NSEC3 hashes the names first, so an outside observer can't easily list them, at the cost of a little extra work during validation.

Neither one is wrong. The checker tells you which is in use. If it is NSEC3, it also reports the iteration count. RFC 9276 recommends zero iterations, and resolvers are starting to refuse high counts.

Where chains usually break

If the chain breaks anywhere, the report names the step that failed. The two failure modes that account for most broken zones are a missing DS upload after a key rollover (the new DNSKEY is live but the registrar still holds the old DS) and a stale signature nobody re-signed.

What to do: if the chain shows broken, start at the lowest red arrow in the diagram. That is the zone whose parent doesn't trust it. From there, either the DS at the parent is wrong or the DNSKEY at the child has changed without telling the parent. Both are fixed at the registrar control panel, not at the nameserver.

CDS and CDNSKEY automate the rollover

RFC 7344 and RFC 8078 let the child zone publish the DS records the parent should hold. Registrars that consume them roll the parent DS automatically. If your registrar supports it, this is the most reliable way to get a key rotation right.

Where to go next

To inspect the raw records yourself across multiple resolvers, the DNS lookup tool exposes the same Google, Cloudflare and Quad9 queries this checker uses. For a refresher on what each record type carries, see the DNS record types reference. Once DNSSEC is healthy, DANE and MTA-STS are the next two standards worth turning on for mail.

Frequently Asked Questions

DNSSEC is like a "digital ID card" for your website's address. It adds a secure, verifiable signature to your DNS records to prove they are genuine. This prevents hackers from redirecting your visitors to fake websites, a trick called "DNS spoofing". It creates a chain of trust that ensures your visitors always reach the real site.

Many high-security sites use DNSSEC to protect their users. Try testing cloudflare.com, icann.org, or google.com to see what a healthy, validated setup looks like.

Most websites don't have DNSSEC enabled yet. While your site will still work perfectly fine without it, you won't have that extra layer of protection against hackers trying to hijack your traffic. If you handle sensitive information or payments, we recommend enabling it.

A "broken" status means DNSSEC is active but the security signatures are wrong. This is actually worse than not having it at all! To protect users, many providers (like Google and Cloudflare) will block your site entirely if the signatures don't match. This usually happens if your DNS records are changed but your registrar isn't updated.

Enabling DNSSEC is a two-step process. First, you enable it at your DNS host (like Cloudflare or Route 53) to sign your records. Then, you give a special "DS record" to your domain registrar (where you bought the domain) to link the security chain. You can check your registrar's current DNS configuration with our WHOIS Checker.

The Chain Walk traces DNSSEC zone by zone, starting at the root (.) and walking down through the TLD (e.g. .com) to your domain. At each step you see what the parent publishes about the child (the DS records), what the child publishes about itself (DNSKEY records), whether the key tags actually match up, whether the DNSKEY set is properly signed, and what a validating resolver thinks of it all. Same idea as the Verisign DNSSEC Debugger. It's the fastest way to point at the exact zone where trust stops.

Watch the AD bit badge on each zone. The first zone that flips from "AD bit set" to "AD bit clear" is where trust stops. If it stops at the TLD, the parent has no DS record for your domain. If it stops at your domain, the DS at the registrar is probably pointing at a key tag that no longer matches any DNSKEY in your zone. That usually means somebody rolled the key without updating the registrar afterwards.

The KSK (Key Signing Key, marked SEP) only signs the DNSKEY set. It's the one your registrar's DS record points at. The ZSK (Zone Signing Key) signs everything else in the zone: A, MX, TXT, and so on. The reason for the split is purely operational: ZSKs can be rotated often without coordinating with the registrar, while the KSK stays put so the DS record stays valid. The Chain Walk lists both with their key tags so you can confirm the DS matches the right KSK.

A DS record at the parent is a hash of a specific DNSKEY at the child, computed as SHA-1, SHA-256, or SHA-384 over the canonical owner name plus the DNSKEY's wire bytes (RFC 4034 §5.1.4). We recompute that hash for every DS and every published DNSKEY at the zone, and report which DNSKEY (if any) each DS actually hashes to. The green arrows in the Chain of Trust diagram mean "match found"; a red arrow is the real chain break, even when a cached AD bit still looks healthy. Usually it means a key was rolled at the DNS host and nobody pushed the new DS to the registrar afterwards.

We send the same DS query in parallel to Cloudflare, Google, Quad9, and OpenDNS, and read the AD bit each one sets in its reply. AD=1 means that resolver walked the chain and trusts the answer; AD=0 on a signed domain means it does not. When at least one resolver validates and at least one calls it bogus, you get a real picture of who will deliver your records and who will return SERVFAIL. Healthy zones rarely show disagreement here. When it shows up, the cause is usually a half-finished KSK rollover, a stale DS at the parent, or a signer pipeline that has fallen behind.

CDS and CDNSKEY (RFC 7344) are records the child publishes to tell the parent what its DS should be. Registrars that support RFC 7344 poll for these and rotate the parent DS automatically, which removes the most error-prone step in a KSK rollover. If the checker says "CDS published," you have automated DS rotation wired up; if it says "Delete sentinel," the child has published the RFC 8078 deletion marker and the registrar will remove the parent DS at the next poll.

NSEC3 proves the non-existence of a name by publishing hashed labels rather than the labels themselves. Each lookup costs the resolver one SHA-1 hash per iteration. RFC 9276 (2022) recommends zero iterations because the originally claimed security benefit of higher counts never materialised, and high counts let attackers amplify CPU load on validating resolvers. We flag iterations 1–99 as info, 100–499 as warning, and 500+ as error. If your zone shows a non-zero iteration count, drop it to zero on the next NSEC3PARAM rotation.

The grade combines verdict, algorithm modernity, DS digest strength, RRSIG freshness, and the warning count into a single letter. A requires the chain to validate, a modern algorithm (ECDSAP256SHA256, ECDSAP384SHA384, or Ed25519), no SHA-1 DS, no warning-level findings, and at least 25% of each signature's lifetime remaining. B drops the modern-algorithm requirement. C means signed but with warnings or aging signatures. F is reserved for unsigned, broken, or error states. The grade is derived purely from data on the page; nothing is hidden.

Every RRSIG carries an inception and an expiration timestamp. The sparkline visualises that window: the leftmost edge is when the signature was issued, the rightmost is when it expires, and the vertical marker shows now. The percentage indicates how much of the window has been consumed. An online signer (Cloudflare, Route 53) typically reissues at the 30–50% mark and rarely lets you see anything past 60%. A manually signed zone with a 30-day window might sit at 80% legitimately right before the scheduled resign. Past 90% with no fresh signature is the early warning for an outage.