Inspector de DNSSEC online
Escribe un nombre para ver cómo lo protege DNSSEC: desde el ancla de confianza de la raíz, a través de cada delegación, hasta los registros o hasta la prueba de que no existen. El inspector comprueba cada firma por sí mismo en lugar de fiarse de lo que dice el resolvedor.
Las firmas se verifican en tu navegador. Al inspeccionar un nombre, se envían consultas DNS sobre él, sus zonas padre y sus claves al resolvedor DNS-over-HTTPS que elijas (Cloudflare o Google), y nada más; nuestros servidores no reciben nada.
Cualquier nombre, como www.example.com; «.» es la zona raíz.
Por ejemplo, A, AAAA, MX, TXT, CAA, TLSA, HTTPS, DNSKEY.
Devuelve los datos que el resolvedor rechazaría, para poder inspeccionar una cadena rota.
Qué hace y qué no hace este inspector
- Ve el DNS a través de un único resolvedor público, el que elijas, y no a través de los servidores de nombres de la propia zona: se valida lo que devuelve ese resolvedor. El bit AD del resolvedor se muestra solo a modo de comparación.
- Se verifican firmas RSA/SHA-256 y SHA-512, ECDSA P-256 y P-384, Ed25519 y Ed448, y RSA/SHA-1, que está obsoleto. Los algoritmos que el registro de la IANA prohíbe usar a los validadores (RSAMD5, DSA, GOST R 34.10-2001) hacen que una zona sea insegura; SM2, ML-DSA y GOST R 34.10-2012 no están implementados y se indican como tales.
- Una inspección hace como máximo 40 consultas y 512 comprobaciones de firmas, así que ninguna zona puede obligar a la página a trabajar sin límite; un recorrido que necesite más se indica como incompleto.
- Los períodos de validez se comprueban con el reloj de tu equipo; una transcripción guardada se comprueba en el momento en que se grabó.
- No se pueden consultar metatipos como ANY y RRSIG, y un registro cuyos bytes firmados exactos no pueden reconstruirse a partir del texto del resolvedor se notifica en lugar de reconstruirse de forma aproximada.
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.