Inspetor de DNSSEC (DNSSEC Inspector)
Informe um nome para ver como o DNSSEC o protege: da âncora de confiança da raiz, passando por cada delegação, até os registros — ou até a prova de que eles não existem. O inspetor verifica cada assinatura por conta própria em vez de confiar na palavra do resolvedor.
As assinaturas são verificadas no seu navegador. Inspecionar um nome envia consultas DNS sobre ele, as zonas pai e as chaves delas ao resolvedor DNS-over-HTTPS que você escolher (Cloudflare ou Google), e nada mais; nossos servidores não recebem nada.
Qualquer nome, como www.example.com; “.” é a zona raiz.
Por exemplo, A, AAAA, MX, TXT, CAA, TLSA, HTTPS, DNSKEY.
Retorna dados que o resolvedor rejeitaria, para que uma cadeia quebrada possa ser inspecionada.
O que este inspetor faz e não faz
- Ele enxerga o DNS por meio de um único resolvedor público, o que você escolher, e não pelos servidores de nomes da própria zona: o que esse resolvedor retorna é o que é validado. O bit AD do resolvedor é exibido apenas para comparação.
- As assinaturas são verificadas para RSA/SHA-256 e SHA-512, ECDSA P-256 e P-384, Ed25519 e Ed448 e o obsoleto RSA/SHA-1. Algoritmos que o registro da IANA proíbe os validadores de usar (RSAMD5, DSA, GOST R 34.10-2001) tornam a zona insegura; SM2, ML-DSA e GOST R 34.10-2012 não estão implementados e são informados como tal.
- Uma inspeção faz no máximo 40 consultas e 512 verificações de assinatura, para que nenhuma zona consiga fazer a página trabalhar sem limite; um percurso que precise de mais é informado como incompleto.
- Os períodos de validade são verificados pelo relógio do seu computador; uma transcrição salva é verificada considerando o momento em que foi gravada.
- Metatipos como ANY e RRSIG não podem ser consultados, e um registro cujos bytes assinados exatos não podem ser reconstruídos a partir do texto do resolvedor é informado, em vez de aproximado.
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.