DNSSEC Checker
Check whether a domain's DNSSEC chain of trust validates. Lists the DNSKEY records in the zone and the DS at the parent, matches them by key tag, and asks a validating resolver for the verdict.
How the check works
- DNSKEY in the zone. Each key is listed with its key tag, role (KSK signs the key set, ZSK signs the rest) and algorithm.
- DS at the parent. The DS record at the registry is the parent's hash of the KSK. Its key tag must match a published key, or the chain is broken.
- A validating resolver's verdict. Google Public DNS is asked for the domain's SOA. "Secure" means the chain validates end to end; "bogus" means resolvers return SERVFAIL, and the extended DNS error names the reason.
Common DNSSEC errors and how to fix them
DS record does not match any DNSKEY
Seen as: "No DNSKEY matches DS RRs", EDE 9 "DNSKEY Missing", SERVFAIL from 8.8.8.8 and 1.1.1.1
Cause. The DS record at the registrar still points at a key the zone no longer publishes. It happens after a KSK rollover where the new DS was never submitted, or after moving DNS hosting to a provider that signs with its own keys while the old provider's DS stays at the registrar.
Fix. Take the current DS record from your DNS host (Cloudflare, Route 53 and most hosts show it on the DNSSEC page), replace the old DS at the registrar with it, and wait out the DS TTL at the parent (one day on .com). If you cannot get a DS quickly, delete the DS at the registrar: the domain becomes unsigned but reachable again.
DS record at the parent, no DNSKEY in the zone
Seen as: SERVFAIL on validating resolvers, EDE 9 "DNSKEY Missing"
Cause. DNSSEC was switched off at the DNS host, or DNS moved to a provider that does not sign, while the registrar kept publishing the DS. The parent says "this zone is signed" and the zone serves no keys to prove it.
Fix. Remove the DS record at the registrar, or turn signing on at the current DNS host and submit its DS. When changing DNS providers, remove the DS first, wait for the parent TTL to pass, then move the nameservers.
RRSIG signatures expired
Seen as: EDE 7 "Signature Expired", SERVFAIL that appears days after a working setup
Cause. Signatures carry an expiry date, usually one to four weeks out, and the signer must re-sign before then. Self-hosted signers (BIND inline-signing, Knot, OpenDNSSEC, PowerDNS) stop doing that when the service, its cron or its key files break; a hidden primary that stopped transferring to the secondaries has the same effect.
Fix. Restart signing and force a re-sign of the zone, then confirm the secondaries pulled the new serial. Monitor signature expiry, not just uptime: the zone answers normally right up to the moment it goes bogus.
RRSIG signatures not valid yet
Seen as: EDE 8 "Signature Not Yet Valid"
Cause. The signing server's clock runs ahead, so the inception time on fresh signatures lies in the future for everyone else.
Fix. Fix NTP on the signing host and re-sign. Most signers backdate inception by an hour to absorb small skews; larger ones need the clock fixed.
Records served without signatures
Seen as: EDE 10 "RRSIGs Missing"
Cause. One of the nameservers serves an unsigned copy of the zone - typically a secondary that transfers from the unsigned source, or a provider in a multi-provider setup that was never configured for DNSSEC.
Fix. Query each nameserver directly (dig +dnssec @ns1... SOA example.com) and find the one that answers without RRSIG. Point its zone transfer at the signed zone, or take it out of the NS set.
NSEC/NSEC3 proof missing
Seen as: EDE 12 "NSEC Missing", failures only on names that do not exist
Cause. Answers for nonexistent names or record types must carry a signed NSEC or NSEC3 proof. A signer bug, a mismatched NSEC3 parameter set between nameservers, or a load balancer synthesizing answers outside the signed zone breaks it.
Fix. Check the NSEC3PARAM record on every nameserver, re-sign the zone, and keep synthesized answers (geo-DNS, wildcards from a proxy) inside the signer.
Validation fails for another reason
Seen as: SERVFAIL on validating resolvers without a specific extended error
Cause. The chain breaks somewhere the resolver did not name: an algorithm mismatch between DS and key, a broken key rollover, or a parent zone problem.
Fix. Open the domain in DNSViz, which draws the whole chain and marks the broken link, and fix the first red arrow from the top.
Zone signed, no DS at the parent
Seen as: Insecure (no AD flag), DNSKEY present
Cause. Signing is on at the DNS host but nobody published the DS at the registrar, so resolvers never learn the zone is meant to be signed. Nothing breaks, nothing is protected.
Fix. Copy the DS record (key tag, algorithm, digest type, digest) from the DNS host into the registrar's DNSSEC settings. Cloudflare Registrar and Route 53 Domains do this automatically for their own DNS.
Deprecated SHA-1 algorithm or digest
Seen as: Valid today; algorithm 5 or 7, or DS digest type 1
Cause. RFC 8624 marks RSASHA1 (5) and RSASHA1-NSEC3-SHA1 (7) as not recommended for signing and SHA-1 DS digests as not recommended. Some validators already treat SHA-1 zones as insecure.
Fix. Roll to ECDSAP256SHA256 (13) with a SHA-256 DS (digest type 2). On a managed host this is usually a re-enable of DNSSEC; self-hosted, follow the algorithm rollover procedure in RFC 6781 so the chain never breaks halfway.
Domain is not signed
Seen as: No DNSKEY, no DS
Cause. DNSSEC was never enabled. This is the state of most domains on the internet.
Fix. Turn on DNSSEC at the DNS host and publish the DS at the registrar. Worth it for domains that handle mail or logins; read the trade-offs before enabling it on a domain you cannot watch.
Background on what DNSSEC protects and when to enable it: DNSSEC explained.
Frequently asked questions
How do I check if DNSSEC is enabled for a domain?
Enter the domain above. The checker looks for DNSKEY records in the zone and a DS record at the parent, then asks a validating resolver (Google Public DNS) whether the chain of trust holds. Signed and validating means DNSSEC is on; DNSKEY without DS means it is half set up.
What is a DS record?
The Delegation Signer record sits in the parent zone (the .com registry for example.com) and holds a hash of the domain's key-signing key. It is what links the domain into the DNSSEC chain of trust. You publish it through your registrar; your DNS host shows the values to copy.
How do I check a DS record?
Enter the domain above. The checker reads the DS records at the parent and shows each one's key tag, algorithm and digest type, then marks whether a DNSKEY in the zone matches it. A DS with no matching key is what makes a domain bogus.
What does DNSSEC bogus mean?
A validating resolver found signatures it cannot verify, so it refuses to answer and returns SERVFAIL. For anyone behind Google, Cloudflare, Quad9 or a validating ISP resolver the domain stops resolving - website and mail alike. Bogus is worse than unsigned.
How do I fix "No DNSKEY matches DS RRs"?
The DS record at your registrar points at a key your zone no longer has. Replace it with the DS your current DNS host shows, or delete it to fall back to unsigned. The fix takes effect when the old DS expires from resolver caches, usually within a day.
Should I remove the DS record before changing DNS providers?
Yes, unless both providers support a multi-signer transfer. Remove the DS at the registrar, wait for the parent TTL (24 hours on .com), move the nameservers, then enable DNSSEC at the new host and publish its DS.
What is the difference between a KSK and a ZSK?
The key-signing key (KSK, DNSKEY flags 257) signs only the DNSKEY set, and its hash is what the DS record at the parent contains. The zone-signing key (ZSK, flags 256) signs every other record. Many managed hosts use a single combined key; the checker shows the role and key tag of each.
Which DNSSEC algorithm should I use?
ECDSAP256SHA256 (algorithm 13) with a SHA-256 DS digest. It is the default at Cloudflare and Route 53, gives small signatures, and every validator supports it. Avoid algorithms 5 and 7 and SHA-1 digests.
Does this checker verify the signatures itself?
No. It parses the records and relies on Google Public DNS, a validating resolver, for the verdict and the extended DNS error that names the cause. For a link-by-link picture of the chain, DNSViz is the standard tool.