DNSSEC Checker

Por que verificar DNSSEC?

DNSSEC (DNS Security Extensions) adiciona uma verificação criptográfica às respostas DNS. Sem essa proteção, um atacante pode falsificar as respostas e redirecionar seu tráfego para os próprios servidores. É o princípio do cache poisoning.

O perigo é silencioso. Um DS órfão ou uma rotação de chaves incompleta faz um domínio desaparecer. Nenhum monitoramento HTTP, nenhum ping, nenhum uptime check detectará esse problema. Essas falhas silenciosas persistem por dias. Os resolvedores validantes (Google, Cloudflare, Quad9) retornam SERVFAIL no lugar da resposta esperada.

Quatro razões para verificar seu DNSSEC:

• Segurança: Confirmar que a cadeia está intacta. Seus visitantes alcançam seus servidores, não os de um atacante.
• Disponibilidade: Um DNSSEC quebrado bloqueia os resolvedores validantes, ou seja, cerca de um terço a 40 % das consultas mundiais segundo as medições da APNIC. Google, Cloudflare e Quad9 rejeitam a resposta.
• Conformidade: Bancos, governos, saúde e e-commerce exigem DNSSEC nos domínios críticos.
• Detecção proativa: Identificar DS órfãos, algoritmos fracos e assinaturas expiradas antes da indisponibilidade.

Como usar o DNSSEC Checker em 3 passos

Passo 1: Insira seu domínio

Digite o nome de domínio a verificar (por exemplo cloudflare.com ou nic.fr). A ferramenta aceita qualquer domínio, assinado com DNSSEC ou não. Se DNSSEC não estiver ativo, o resultado indica isso imediatamente.

Passo 2: Escolha o modo de análise

• Modo Simples (padrão): Verifica a cadeia de confiança completa por meio de um servidor autoritativo por zona. Resultado em 1 a 3 segundos.
• Modo Completo: Adiciona a consistência DNSKEY entre todos os servidores autoritativos. Valida também as assinaturas RRSIG em SOA, NS, A e MX. Resultado em 5 a 10 segundos.

Na dúvida, comece pelo modo Simples. Use o modo Completo após um key rollover, uma migração DNS ou para uma auditoria de segurança.

Passo 3: Analise o relatório e corrija

O relatório classifica cada anomalia por severidade:

• Os erros bloqueiam a resolução. Cadeia quebrada, assinaturas inválidas, inconsistência entre servidores.
• Os avisos exigem uma ação. DS órfãos, algoritmos fracos, RRSIG expirando em breve.
• As informações não exigem nenhuma ação. CSK detectada, NS fora de bailiwick, quantidade de DS no parent.

O que é a cadeia de confiança (chain of trust) DNSSEC?

A cadeia de confiança DNSSEC funciona como um revezamento de verificações criptográficas em cascata. Cada zona atesta a próxima, da raiz DNS até seu domínio:

Raiz (.)
  |-- DS do TLD --> verifica a DNSKEY do TLD (KSK)
  |-- A ZSK do TLD assina o DS do seu domínio
        |-- DS do seu domínio --> verifica sua DNSKEY (KSK)
        |-- Sua KSK assina o DNSKEY RRSet
        |-- Sua ZSK assina os dados (A, MX, SOA, NS)

Os registros-chave:

Cada elo depende do anterior. Um único elo quebrado e toda a cadeia desmorona. Os resolvedores validantes retornam então SERVFAIL.

NSEC e NSEC3: a prova autenticada de inexistência

O DNSSEC não assina apenas os registros existentes. Ele também prova, de forma autenticada, que um nome ou um tipo de registro não existe. Sem essa prova, um atacante poderia negar a existência de um registro que na verdade está assinado. Dois mecanismos garantem essa prova de inexistência:

• NSEC (Next Secure) encadeia os nomes da zona em ordem alfabética. Cada registro NSEC indica o próximo nome existente. A desvantagem: ao seguir essa cadeia de nome em nome, qualquer pessoa pode enumerar todos os nomes da zona. É o zone walking.
• NSEC3 (RFC 5155) corrige esse problema publicando hashes dos nomes em vez dos nomes em texto claro. O zone walking fica muito mais custoso, pois é preciso quebrar os hashes. NSEC3 adiciona um sal (salt) e um número de iterações.

O opt-out NSEC3 é uma opção destinada a zonas muito grandes (TLD, zonas com muitas delegações não assinadas). Ele evita gerar uma prova NSEC3 para as delegações não seguras, o que reduz o tamanho da zona e o custo de assinatura. Em contrapartida, o opt-out não autentica a ausência dessas delegações.

Para a maioria dos domínios, NSEC ou NSEC3 servem bem. NSEC3 é preferível se a enumeração da sua zona for uma preocupação.

O que exatamente esta ferramenta verifica?

Modo Simples

Modo Completo (verificações adicionais)

Diagnósticos comuns e soluções

DS órfão (DNSSEC_DS_ORPHAN)

Sintoma: DS publicado no parent sem DNSKEY correspondente na sua zona.

Causa provável: Key rollover incompleto. A chave antiga foi removida antes da atualização do DS no registrador.

Ação: Remova o DS órfão pelo painel do registrador ou re-adicione a DNSKEY correspondente na zona. Execute o teste novamente para confirmar.

Algoritmo fraco (DNSSEC_WEAK_ALGO)

Sintoma: Sua zona utiliza um algoritmo de assinatura considerado inseguro pela RFC 8624.

Algoritmos afetados: RSAMD5 (1), DSA (3) e DSA-NSEC3-SHA1 (6) são proibidos para assinatura. RSASHA1 (5) e RSASHA1-NSEC3-SHA1 (7) são desaconselhados.

Ação: Migre para um algoritmo recomendado: RSASHA256 (8), ECDSAP256SHA256 (13), ECDSAP384SHA384 (14) ou Ed25519 (15). Execute o teste novamente para confirmar.

Digest SHA-1 (DNSSEC_WEAK_DIGEST)

Sintoma: Seu DS usa SHA-1 (tipo 1) como tipo de digest.

Ação: Adicione um DS SHA-256 (tipo 2), ou SHA-384 (tipo 4) se seu registrador suportar, em paralelo. Aguarde 48h de propagação e depois remova o DS SHA-1. Execute o teste novamente para confirmar.

SERVFAIL após ativação de DNSSEC

Sintoma: Seu domínio retorna SERVFAIL para os resolvedores validantes após ativar DNSSEC.

Causas frequentes:

• DS no registrador não corresponde à DNSKEY da sua zona
• Assinaturas RRSIG não geradas ou expiradas
• Servidores autoritativos não servindo os registros DNSKEY

Ação: Execute o teste em modo Completo para identificar o elo quebrado. Verifique se o DS corresponde à DNSKEY KSK. Execute o teste novamente para confirmar.

Inconsistência DNSKEY entre servidores (DNSSEC_SERVER_INCONSISTENT)

Sintoma: Os servidores autoritativos da sua zona não servem as mesmas chaves DNSKEY. Detectado apenas em modo Completo.

Causa provável: Propagação incompleta entre o servidor primário e os secundários, ou configuração diferente em um servidor.

Ação: Verifique a replicação entre servidores. Force uma transferência de zona (AXFR/IXFR) se necessário. Execute o teste novamente para confirmar.

Verificar DNSSEC na linha de comando (delv e dig)

Para administradores de sistema, duas ferramentas permitem verificar DNSSEC manualmente. O delv (incluído no BIND 9.10 e mais recente) faz uma validação completa da cadeia de confiança e exibe um veredito final. O dig consulta os registros brutos (DS, DNSKEY, RRSIG), mas não valida a cadeia por si só.

Nota: as antigas opções dig +sigchase e +trusted-key foram removidas das versões modernas do BIND. Use o delv no lugar delas para a validação.

# Validar a cadeia de confiança completa (veredito final)
delv captaindns.com A

# Rastrear cada etapa da validação
delv @1.1.1.1 captaindns.com A +rtrace

# Validar e exibir as DNSKEY da zona
delv captaindns.com DNSKEY

# Ver os registros DS publicados no parent
dig DS captaindns.com +short

# Ver as DNSKEY e suas assinaturas RRSIG (sem validação)
dig DNSKEY captaindns.com +dnssec

# Ver as RRSIG em um registro A
dig A captaindns.com +dnssec

Uma resposta delv validada exibe ; fully validated; uma falha de validação exibe ; resolution failed. Esses comandos exigem acesso ao terminal e conhecimento de DNS. O DNSSEC Checker acima automatiza todo o processo e apresenta os resultados visualmente, sem linha de comando.

DNSSEC por provedor DNS

A ativação de DNSSEC depende da cooperação entre seu provedor DNS e seu registrador. Veja como os principais se comparam:

Após ativar DNSSEC no seu provedor, sempre verifique a cadeia de confiança com o checker acima. O erro nº 1: DS no registrador que não corresponde à DNSKEY gerada pelo provedor.

Boas práticas DNSSEC

Algoritmo de assinatura: Prefira um algoritmo de curva elíptica, ECDSAP256SHA256 (13) ou Ed25519 (15). RSASHA256 (8) e ECDSAP384SHA384 (14) continuam amplamente implantados e aceitos. ECDSA produz assinaturas cerca de 3,5 a 4 vezes mais compactas que RSA-2048, o que reduz o tamanho das respostas.

Digest DS: Publique um DS com SHA-256 (tipo 2); SHA-384 (tipo 4) também é aceito. SHA-1 (tipo 1) está obsoleto: não publique mais um DS SHA-1 sozinho.

Rotação de chaves: Siga as práticas das RFC 6781 e 7583 (veja a seção dedicada mais abaixo). Nunca remova o DS antigo antes da propagação do novo.

Monitoramento: Verifique a cadeia após cada modificação DNS. Uma zona não reassinada a tempo provoca SERVFAIL.

Migração de provedor: Confirme que o novo provedor suporta o mesmo algoritmo. Os dois conjuntos de chaves devem coexistir durante a propagação.

Rotação das chaves de assinatura (rollover)

Uma chave DNSSEC não é eterna. É preciso substituí-la periodicamente (rollover) sem quebrar a cadeia de confiança. As RFC 6781 (operational practices) e 7583 (timing) descrevem esses procedimentos. O modo de operação difere conforme o tipo de chave.

Rollover de KSK (Key Signing Key). A KSK é referenciada pelo DS no parent. O método comum é o double-DS: publique o DS da nova KSK no parent, aguarde que todos os caches tenham considerado os dois DS, troque a assinatura do DNSKEY RRSet para a nova KSK e depois remova o DS antigo. O prazo depende do TTL do DS no parent.

Rollover de ZSK (Zone Signing Key). A ZSK assina os dados e não está ligada ao parent. Dois métodos:

• Pre-publish: publique a nova ZSK no DNSKEY RRSet antes de usá-la, aguarde a propagação, assine os dados com a nova chave e depois remova a antiga. É o método recomendado para a ZSK.
• Dupla assinatura: assine os dados com a ZSK antiga e a nova ao mesmo tempo. Mais simples de compreender, mas dobra o número de assinaturas e deixa as respostas mais pesadas.

Riscos de um rollover malsucedido. Remover uma chave ou um DS antes da expiração dos caches que se referem a eles quebra a cadeia: os resolvedores validantes retornam SERVFAIL. Nunca remova a chave antiga ou o DS antigo antes que todos os TTL envolvidos tenham expirado. Verifique a ausência de DS órfão após cada rollover de KSK.

CDS e CDNSKEY: automatizar o DS no parent

O ponto fraco de um rollover de KSK é a atualização manual do DS no registrador. Um copiar e colar errado quebra a cadeia. Os registros CDS e CDNSKEY (RFC 7344 e 8078) automatizam essa etapa.

A zona filha publica um CDS (Child DS) ou um CDNSKEY (Child DNSKEY) que indica ao parent o DS a publicar. O registrador ou o registry escaneia periodicamente esses registros e atualiza o DS automaticamente, sem intervenção manual. Dois usos:

• Bootstrapping (RFC 8078): a primeira ativação de DNSSEC, quando ainda não existe nenhum DS no parent.
• Manutenção: a atualização do DS nos rollovers de KSK seguintes.

Nem todos os registries ainda suportam CDS/CDNSKEY, mas a adoção avança. Quando são suportados, eles eliminam a principal fonte de erro dos rollovers de KSK. Verifique em seguida a cadeia com o DNSSEC Checker para confirmar que o DS publicado corresponde de fato à sua KSK.

Casos de uso concretos

Ativação de DNSSEC em um novo registrador

Acabou de ativar DNSSEC? Execute uma verificação em modo Simples. Confirme que o DS no parent corresponde à DNSKEY da sua zona. A cadeia deve estar completa de ponta a ponta.

Rotação de chaves (key rollover)

Está fazendo um key rollover? Verifique a ausência de DS órfãos com o modo Simples. Um DS antigo não removido não quebra a resolução. Mas complica os próximos rollovers.

Migração de provedor DNS

Migrando para o Cloudflare? Route 53? Execute o teste em modo Completo. Verifique se os DS apontam para as novas DNSKEY. Confirme a validade das assinaturas em todos os servidores autoritativos.

Auditoria de segurança

O modo Completo cobre os três pilares de uma auditoria DNSSEC. Consistência DNSKEY entre servidores. Assinaturas válidas em SOA, NS, A e MX. Alerta sobre as RRSIG próximas da expiração.

Domínio retornando SERVFAIL

Seu site está inacessível em certas redes? Essas redes provavelmente usam resolvedores validantes. Execute o teste imediatamente para identificar se DNSSEC é a causa.

FAQ - Perguntas frequentes

P: O que é DNSSEC e por que ativá-lo?

R: DNSSEC adiciona assinaturas criptográficas às respostas DNS. Sem DNSSEC, um atacante pode falsificar as respostas e redirecionar o tráfego. Ativar DNSSEC garante que os visitantes alcancem seus servidores, e não os de um atacante.

P: Como verificar se DNSSEC está ativo no meu domínio?

R: Insira seu domínio na ferramenta acima. Se mostrar "DNSSEC não está ativo", nenhum DS está publicado no parent. Entre em contato com seu registrador para ativar DNSSEC.

P: O que é um DS órfão?

R: Um DS no parent sem DNSKEY correspondente na zona filha. Isso acontece em uma rotação de chaves incompleta. Não é bloqueante enquanto outro DS válido existir, mas indica configuração incompleta.

P: Por que meu domínio retorna SERVFAIL após ativar DNSSEC?

R: A cadeia de confiança está quebrada. Causas frequentes: DS não correspondendo à DNSKEY, RRSIG ausentes ou expiradas, DNSKEY não servidas. Execute o modo Completo para identificar o elo defeituoso.

P: Qual a diferença entre os modos Simples e Completo?

R: Simples verifica a cadeia DS/DNSKEY/RRSIG em um servidor por zona. Completo adiciona a consistência DNSKEY multi-servidor e valida as RRSIG em SOA, NS, A e MX.

P: Quais algoritmos DNSSEC são recomendados?

R: Os algoritmos comuns e recomendados são RSASHA256 (8), ECDSAP256SHA256 (13), ECDSAP384SHA384 (14) e Ed25519 (15). Conforme a RFC 8624, RSAMD5 (1), DSA (3) e DSA-NSEC3-SHA1 (6) são proibidos; RSASHA1 (5) e RSASHA1-NSEC3-SHA1 (7) são desaconselhados.

P: NSEC ou NSEC3: o que é o zone walking?

R: NSEC e NSEC3 provam de forma autenticada que um nome não existe. NSEC lista os nomes em texto claro, o que permite enumerar toda a zona (zone walking). NSEC3 (RFC 5155) publica hashes no lugar dos nomes para impedir essa enumeração.

P: Para que servem os registros CDS e CDNSKEY?

R: CDS e CDNSKEY (RFC 7344 e 8078) permitem que a zona filha sinalize ao parent o DS a publicar. O registrador ou o registry escaneia esses registros para criar e depois manter o DS automaticamente, sem copiar e colar manual a cada rotação de KSK.

P: DNSSEC deixa a resolução DNS mais lenta?

R: O impacto é limitado, mas as respostas assinadas são maiores. Elas podem ultrapassar o tamanho de um pacote UDP e provocar fragmentação ou um fallback para TCP. Os resolvedores armazenam em cache os resultados validados, o que amortiza o custo após a primeira consulta.

Ferramentas complementares

Recursos úteis

• RFC 4033 - DNS Security Introduction: Introdução e requisitos das extensões DNSSEC
• RFC 4034 - Resource Records for DNSSEC: Especificação dos registros DS, DNSKEY, RRSIG, NSEC
• RFC 4035 - Protocol Modifications for DNSSEC: Comportamento dos resolvedores e servidores validantes
• RFC 5155 - DNSSEC Hashed Authenticated Denial of Existence: Especificação do NSEC3
• RFC 6781 - DNSSEC Operational Practices: Boas práticas operacionais e rollovers
• RFC 7583 - DNSSEC Key Rollover Timing: Cronograma de rotação das chaves
• RFC 8624 - Algorithm Implementation Requirements: Requisitos sobre os algoritmos DNSSEC
• Verisign DNSSEC Debugger: Ferramenta de referência para debug DNSSEC
• DNSViz: Visualização avançada da cadeia DNSSEC