DNSSEC Checker

Porque 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 o 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. Nenhuma monitorização HTTP, nenhum ping, nenhum uptime check detetará 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 o seu DNSSEC:

• Segurança: Confirmar que a cadeia está intacta. Os seus visitantes alcançam os 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.
• Deteção proativa: Identificar DS órfãos, algoritmos fracos e assinaturas expiradas antes da indisponibilidade.

Como usar o DNSSEC Checker em 3 passos

Passo 1: Introduza o seu domínio

Introduza 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 detetada, 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é ao 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 a sua DNSKEY (KSK)
        |-- Sua KSK assina o DNSKEY RRSet
        |-- Sua ZSK assina os dados (A, MX, SOA, NS)

Os registos-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 registos existentes. Também prova, de forma autenticada, que um nome ou um tipo de registo não existe. Sem essa prova, um atacante poderia negar a existência de um registo 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 registo 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). 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 registrar.

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

Algoritmo fraco (DNSSEC_WEAK_ALGO)

Sintoma: A 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: O 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 o seu registrar 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: O seu domínio retorna SERVFAIL para os resolvedores validantes após ativar DNSSEC.

Causas frequentes:

• DS no registrar não corresponde à DNSKEY da sua zona
• Assinaturas RRSIG não geradas ou expiradas
• Servidores autoritativos não servindo os registos 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. Detetado apenas em modo Completo.

Causa provável: Propagação incompleta entre o servidor primário e os secundários, ou configuração diferente num 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 veredicto final. O dig consulta os registos 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 em vez delas para a validação.

# Validar a cadeia de confiança completa (veredicto 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 registos 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 num registo 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 fornecedor de DNS

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

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

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 aceites. 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 é aceite. SHA-1 (tipo 1) está obsoleto: não volte a publicar um DS SHA-1 sozinho.

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

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

Migração de fornecedor: Confirme que o novo fornecedor 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 registrar. Um copiar e colar errado quebra a cadeia. Os registos 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 registrar ou o registry consulta periodicamente esses registos 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, 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 facto à sua KSK.

Casos de uso concretos

Ativação de DNSSEC num novo registrar

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á a fazer 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 fornecedor de DNS

A migrar para o Cloudflare? Para a 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 a retornar SERVFAIL

O 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 porque 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 os seus servidores, e não os de um atacante.

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

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

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

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

P: Porque é que o meu domínio retorna SERVFAIL após ativar DNSSEC?

R: A cadeia de confiança está quebrada. Causas frequentes: DS que não corresponde à DNSKEY, RRSIG em falta 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 num 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 em vez dos nomes para impedir essa enumeração.

P: Para que servem os registos CDS e CDNSKEY?

R: CDS e CDNSKEY (RFC 7344 e 8078) permitem que a zona filha sinalize ao parent o DS a publicar. O registrar ou o registry consulta esses registos 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 registos 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