Verificador de DNSSEC

Consulta o registro DNSKEY de um domínio em vários resolvedores DNS públicos (Google, Cloudflare e outros) para verificar se a cadeia de assinaturas DNSSEC é validada corretamente.

Dicas

  • A flag AD (Authenticated Data) só é ativada quando o próprio resolvedor DNS consultado realizou a validação DNSSEC. Resolvedores sem suporte a DNSSEC não conseguem fornecer um resultado significativo.
  • "DNSSEC não ativado" não é um erro — a maioria dos domínios ainda não usa DNSSEC, e isso não afeta diretamente o posicionamento nas buscas nem a entregabilidade de e-mails.
  • Se a validação falhar, verifique primeiro se a key tag e o digest do registro DS cadastrado no seu registrador correspondem ao seu DNSKEY atual.
  • As assinaturas DNSSEC (RRSIG) têm data de expiração. Confirme também se a reassinatura automática do seu software de DNS não parou.
  • Logo após ativar o DNSSEC, a validação pode aparecer temporariamente como "falhou" até que o registro DS se propague para a zona pai.

Perguntas frequentes

"DNSSEC não ativado" por si só não é perigoso — a grande maioria dos domínios ainda opera sem ele. Ainda assim, ativá-lo vale a pena ser considerado como defesa contra o envenenamento de cache DNS, se essa opção estiver disponível.

Usuários em resolvedores que exigem DNSSEC (muitas redes corporativas e alguns provedores de internet) podem não conseguir resolver o domínio de jeito nenhum, pois ele é tratado como SERVFAIL. A menos que seja um estado temporário logo após ativar o DNSSEC enquanto o registro DS se propaga, isso precisa de correção imediata.

Logo após uma troca (rollover) de DNSKEY, chaves antigas e novas podem coexistir brevemente nos caches dos resolvedores, causando resultados de validação temporariamente diferentes. Aguarde um pouco e verifique novamente.

Não. O DNSSEC garante que uma resposta de resolução de nomes não foi adulterada, enquanto o SSL/TLS garante que a própria conexão está criptografada e que o servidor possui o certificado apresentado. São independentes — um domínio pode ter um sem o outro.

Esta ferramenta verifica apenas o status superficial: se um DNSKEY está publicado e se os resolvedores reportam a flag AD. Para uma análise rigorosa de toda a cadeia de assinaturas (consistência de RRSIG/NSEC/NSEC3, etc.), combine com uma ferramenta especializada como o dnsviz.net.
ツールくん

Curiosidade — por que o DNS precisou de uma forma de impedir falsificações

Quando o DNS foi projetado em 1983, não havia nenhuma forma criptográfica de confirmar quem realmente enviou uma resposta. Um resolvedor confiava em qualquer pacote UDP que chegasse com um ID de transação de aparência plausível — um protocolo construído sobre boa-fé, vulnerável à falsificação de IP de origem e à adivinhação de IDs. Em 2008, o pesquisador de segurança Dan Kaminsky mostrou à indústria que essa fragilidade podia ser explorada para realizar ataques práticos e rápidos de envenenamento de cache (injetar registros forjados no cache de um resolvedor), uma descoberta que abalou toda a comunidade DNS.

O DNSSEC (DNS Security Extensions) é a resposta padronizada a esse problema. Ele usa criptografia de chave pública para provar que uma resposta foi assinada pelo operador legítimo da zona. Um domínio assina seus registros com sua DNSKEY, e um registro DS cadastrado na zona pai atesta o digest dessa chave, construindo uma cadeia de confiança ininterrupta desde a raiz do DNS até o domínio individual.

A flag AD (Authenticated Data) em uma resposta DoH (DNS sobre HTTPS) é o resultado de o resolvedor realizar essa validação DNSSEC em seu nome. As aplicações não precisam implementar a verificação de assinaturas por conta própria — consultar um resolvedor confiável e ver AD=true é uma garantia indireta de que a resposta não foi adulterada, desde que o transporte entre o resolvedor e a aplicação (HTTPS) esteja protegido separadamente.