DNSSEC Debugger

About the DNSSEC Debugger

This DNSSEC debugger does what a validating resolver does, but shows its work. It starts at the root servers and follows the delegation down, TLD by TLD, asking the authoritative nameservers directly rather than a cache. At every zone it fetches the DNSKEY RRset, compares the DS records the parent publishes against those keys (recomputing the SHA-256 or SHA-384 digest itself), checks that the DNSKEY RRset is signed by the key the DS points at, that the DS RRset is signed by the parent, and finally that the answer for your name is signed by a zone key. Signatures are verified cryptographically, RSA, ECDSA P-256/P-384 and Ed25519 alike, and their inception and expiration windows are checked against the clock.

The reason to run it is almost always the same: a domain suddenly returns SERVFAIL on Cloudflare, Google or Quad9 while the nameservers themselves look healthy. That is the classic DNSSEC outage, usually caused by a stale DS record at the registry after a nameserver or DNS-provider change, a key rollover that removed a key the DS still references, or signatures that were never refreshed and have expired. The debugger names the exact zone and the exact link where the chain breaks, so you know whether to update the DS at the registrar, re-sign the zone, or simply wait for propagation.

Just as important, it tells you when the problem is not DNSSEC. Every nameserver of the target zone is queried individually for SOA serial and DNSKEY set, so a secondary that serves old keys, a server that is not authoritative, or one that fails outright is visible at a glance. And three public validating resolvers are asked twice: once normally and once with the checking-disabled (CD) bit set. A SERVFAIL that turns into a normal answer with CD=1 is a validation failure; a SERVFAIL both ways means the zone itself is broken, and fixing DNSSEC will not bring the domain back. Nothing is stored, and the tool only ever talks to port 53 of public nameservers and resolvers.

How to use it

1. Enter the domain (or hostname) that is failing or that you want to verify.
2. Read the verdict first: SECURE, INSECURE (unsigned, nothing broken), BOGUS (signed but the chain does not validate) or DNS ERROR (the nameservers do not serve the zone at all).
3. Follow the chain of trust zone by zone; the first red line is where the break is.
4. Open the DS / DNSKEY details to compare the key tags the parent publishes with the keys the zone actually serves.
5. Check the authoritative-servers table for servers that disagree on serial or key set, or that answer SERVFAIL or non-authoritatively.
6. Use the resolver table to see what real-world validators (Cloudflare, Google, Quad9) make of it, including their Extended DNS Error text.
7. After fixing the DS at the registrar or re-signing, re-run and wait for the parent's DS TTL to expire before expecting resolvers to recover.

Examples

• internetsociety.org -> SECURE: root anchor verifies the root KSK, DS at the root matches the org KSK, DS in org matches the zone KSK, every RRSIG verifies, resolvers answer with the AD bit.
• example.com without DNSSEC -> INSECURE: com publishes no DS for the zone (with an NSEC3 proof of absence), which is the normal, unbroken state for an unsigned domain.
• Domain moved to a new DNS provider without removing the old DS -> BOGUS at the zone: the DS at the registry points at key tag 12345, but the zone only serves key 54321; validating resolvers SERVFAIL, and the fix is updating or removing the DS at the registrar.
• RRSIG over the DNSKEY RRset expired three days ago -> BOGUS with 'signature expired': the signer stopped re-signing, re-sign the zone or check the signing software.
• Both nameservers answer SERVFAIL for the zone even with CD=1 -> DNS ERROR: the zone is not loaded on the nameservers (a permissions error on a signed zone file, for instance); not a chain-of-trust problem.

Secure, insecure, bogus: what the verdicts mean

A validating resolver ends up in one of three states for any name. Secure means an unbroken chain of DS and DNSKEY records from the root trust anchor down to the answer, with every signature valid; the resolver sets the AD (authenticated data) flag. Insecure means that somewhere along the way a parent published no DS for its child, and proved that absence with NSEC or NSEC3; the resolver stops validating and simply returns the data, exactly as for any unsigned domain. Bogus means there is a DS, so the resolver expects signatures, but they do not validate: wrong key, expired signature, missing RRSIG. Bogus answers are withheld and the client sees SERVFAIL. This tool adds a fourth label, DNS ERROR, for the case where the authoritative servers do not serve the zone at all; it looks identical to bogus from the outside, but the cure is completely different.

Why a nameserver change breaks DNSSEC

The DS record lives at the parent (the registry) and is a hash of the child's key-signing key. When you move a domain to another DNS provider, the new provider signs with its own keys, but the DS at the registry still describes the old provider's key. Validating resolvers see a DS that matches nothing in the DNSKEY RRset and declare the zone bogus. The same happens when DNSSEC is switched off at the new provider while the old DS remains. The fix is always at the registrar: replace the DS with the new provider's DS, or remove it entirely if the zone is no longer signed. Until the parent's DS TTL (often 1 hour for .nl, 1 day for .com) expires, resolvers keep failing.

Reading the authoritative-server table

• SOA SERVFAIL or REFUSED on one server: that server does not have the zone loaded; the others may be carrying the domain alone.
• Different serials: zone transfers lag or a secondary is stale; check the primary's notify/transfer settings.
• Different DNSKEY tags: servers signing with different keys, or one server still serving a pre-rollover key set; validation becomes intermittent depending on which server a resolver hits.
• 'not authoritative': the server answers but without the AA flag, typically a resolver or a decommissioned host still listed in the delegation.
• No public IPv4: the NS name does not resolve, or only to a private address, and is useless to the outside world.

How the signatures are verified

For every RRSIG the tool rebuilds the exact byte string the signer signed: the RRSIG rdata up to the signer name, followed by each record of the RRset in canonical form (owner name lowercased, wildcard re-expanded, records sorted by rdata, original TTL from the RRSIG), and verifies it with the public key from the DNSKEY record using Node's crypto library. RSA/SHA-1, RSA/SHA-256, RSA/SHA-512, ECDSA P-256 and P-384, Ed25519 and Ed448 are supported; obsolete algorithms such as RSAMD5, DSA and GOST are reported as unsupported rather than silently trusted. Validity windows are checked with no clock skew allowance, so a signature flagged as expired here is already expired for everyone.

Frequently asked questions