DNSSEC Inspector — inspecteur DNSSEC

The chain it rebuilds

DNSSEC (RFC 4033, 4034, 4035) protects DNS answers with signatures that chain up to one key everyone agrees on: the root zone's. The root's key-signing key is published by IANA as a trust anchor (RFC 9718). From there, every zone holds a DNSKEY set signed by its own key, and its parent vouches for that key with a DS record — a digest of it — that the parent signs. An answer is secure when every link from the anchor down holds: the DS matches a key, the key signs the DNSKEY set, a key of that set signs the records.

The inspector asks a DNS-over-HTTPS resolver for exactly the pieces of that chain. For www.example.com it asks for the root's DNSKEY set, for the DS records of com, example.com and www.example.com — which also reveal where the zone cuts are — and for the records you asked about; then for the DNSKEY sets of the zones it found. Names reached through a CNAME or DNAME get a walk of their own. Independent questions go out together, so a typical inspection takes two or three rounds of a few dozen queries.

Why it verifies instead of trusting the resolver

A validating resolver says "this answer is authentic" with one bit, AD. The inspector shows that bit, but never relies on it: it rebuilds the signed data in wire format from the resolver's text, computes each DS digest, and verifies each RRSIG with its own implementations of RSA/SHA-256 and SHA-512, ECDSA P-256 and P-384, Ed25519 and Ed448 — the algorithms that sign almost every zone today. When its result and the AD bit disagree, the page says so: either the resolver cannot validate an algorithm in the chain, or the inspector found a problem the resolver accepted. With checking disabled (cd=1) a resolver returns data it would otherwise refuse with SERVFAIL, which is how a broken chain — dnssec-failed.org is a permanent example — can still be taken apart.

Proving that something does not exist

An attacker who can delete answers is as dangerous as one who can forge them, so DNSSEC also signs absence. NSEC records list the next existing name in the zone and the types at each name; NSEC3 (RFC 5155) does the same with hashed names, so the zone cannot be enumerated as easily. The inspector checks the proof the zone returns: that it covers the queried name or type, that no wildcard could have produced an answer, and, for NSEC3, the closest-encloser proof and the opt-out flag that makes an unsigned delegation possible. Online signers that answer with a single NXNAME record (RFC 9824) are understood too.

Reading the result

Secure means a complete chain from the anchor. Insecure means the chain ends with a proof that a zone on the way is not signed — the common case, and not an error. Bogus means a link is broken: a DS that matches no key, an expired or invalid signature, a missing proof; validating resolvers return SERVFAIL, and certificate authorities must refuse to issue for such names (see the CAA checker). Indeterminate means the walk could not finish — a resolver error, a query that failed, or the query budget running out. Each link of the chain lists its keys, DS records, signatures with their validity windows, and the records themselves.

The limits are stated under the tool: one resolver's view, the algorithms implemented, a budget of 40 queries and 512 signature checks per inspection — the bound that keeps a hostile zone from making the page do unbounded work (the KeyTrap problem). For the same walk done by hand with dig and delv, and what each typical mistake looks like, read DNSSEC chain of trust: DS, DNSKEY, RRSIG and what breaks.

What leaves your browser

The inspector sends DNS questions — the name, its parent zones and their keys — to the resolver you choose, Cloudflare at cloudflare-dns.com or Google at dns.google, from your browser, without cookies or referrer. Our servers are not involved and see nothing. The IANA root anchors ship with the page. Every exchange is kept in a transcript you can download; pasting it back into Saved transcript repeats the validation offline, at the moment it was recorded. Share links carry only the question, after the # of the address, and do not start a lookup by themselves.