Skip to content
ecdsa.com

DNSSEC Inspector

Enter a name to see how DNSSEC protects it: from the root's trust anchor, through each delegation, down to the records — or to the proof that they do not exist. The inspector checks every signature itself instead of trusting the resolver's word.

Signatures are verified in your browser. Inspecting a name sends DNS questions for it, its parent zones and their keys to the DNS-over-HTTPS resolver you choose (Cloudflare or Google), and nothing else; our servers receive nothing.

Any name, such as www.example.com; “.” is the root zone.

For example A, AAAA, MX, TXT, CAA, TLSA, HTTPS, DNSKEY.

Returns data the resolver would reject, so a broken chain can be inspected.

Recorded examples:

What this inspector does and does not do

  • It sees DNS through one public resolver, the one you choose, not through the zone’s own name servers: what that resolver returns is what gets validated. The resolver’s AD bit is shown for comparison only.
  • Signatures are verified for RSA/SHA-256 and SHA-512, ECDSA P-256 and P-384, Ed25519 and Ed448, and the deprecated RSA/SHA-1. Algorithms the IANA registry forbids validators to use (RSAMD5, DSA, GOST R 34.10-2001) make a zone insecure; SM2, ML-DSA and GOST R 34.10-2012 are not implemented and are reported as such.
  • One inspection makes at most 40 queries and 512 signature checks, so no zone can make the page do unbounded work; a walk that needs more is reported as incomplete.
  • Validity periods are checked against your computer’s clock; a saved transcript is checked at the moment it was recorded.
  • Meta-types such as ANY and RRSIG cannot be asked for, and a record whose exact signed bytes cannot be rebuilt from the resolver’s text is reported instead of approximated.

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.