A confusão mais comum sobre DNSSEC é descrevê-lo como "criptografia do DNS". Times que partem dessa premissa errada chegam a duas conclusões igualmente equivocadas: ou dispensam o recurso porque "já temos TLS", ou o ativam sem entender a dependência operacional que acabam de introduzir. DNSSEC assina respostas DNS para provar autenticidade — não cifra nada. O ataque que ele interrompe, a consequência de uma configuração mal gerenciada, e o que ele simplesmente não cobre são três assuntos distintos que merecem tratamento separado.
O que DNSSEC realmente faz
Quando um resolver recursivo consulta um servidor autoritativo e recebe uma resposta, não existe, no DNS tradicional, nenhum mecanismo para verificar que aquela resposta é legítima. O ataque de cache poisoning descrito por Dan Kaminsky em 2008 — e variantes posteriores — explora exatamente isso: um atacante injeta registros falsos no cache de um resolver, redirecionando tráfego para IPs sob seu controle sem que o dono do domínio saiba. Usuários consultam o resolver comprometido, recebem um IP malicioso com resposta aparentemente normal, e seguem adiante. TLS não resolve esse problema por conta própria: se o usuário foi levado a um servidor que tem um certificado válido para o domínio — obtido, por exemplo, via DV em outra CA — a cadeia HTTPS parece íntegra mesmo que o destino seja fraudulento.
DNSSEC resolve o problema na camada de DNS, antes de qualquer conexão TCP. Cada resposta DNS passa a carregar registros RRSIG — assinaturas criptográficas geradas com a chave privada da zona. O resolver que suporta validação DNSSEC verifica a assinatura usando a chave pública publicada na zona (registro DNSKEY), e verifica que essa chave pública é legítima checando o registro DS na zona pai — a cadeia de confiança desce da raiz, passa pela zona TLD (.com, .com.br), e chega à sua zona. Um registro com assinatura inválida ou ausente, em uma zona que declara suporte a DNSSEC, resulta em SERVFAIL: o resolver recusa a resposta em vez de repassar dados potencialmente adulterados.
O que DNSSEC não cobre
DNSSEC não cifra consultas DNS. Um observador na rede ainda enxerga quais domínios você está consultando — para isso existem DNS over HTTPS (DoH) e DNS over TLS (DoT), protocolos separados que encriptam o transporte. DNSSEC também não protege o conteúdo do seu serviço, não mitiga DDoS contra seus servidores autoritativos, e não impede typosquatting ou phishing em domínios que simplesmente se parecem com o seu. A garantia é estreita e específica: respostas DNS para sua zona, quando assinadas corretamente, chegam ao resolver sem adulteração.
Ativando no Cloudflare
O processo técnico no Cloudflare é simples: um botão no painel DNS da zona gera o par de chaves, passa a assinar todos os registros da zona e começa a servir registros RRSIG automaticamente. O recurso está disponível em todos os planos, incluindo o gratuito. O que você faz depois é o que determina se DNSSEC vai funcionar ou vai quebrar produção.
Após ativar no painel, o Cloudflare exibe o registro DS que você precisa cadastrar no seu registrador. Esse registro DS, publicado na zona TLD pelo registrador, é o elo que conecta a confiança do TLD à sua zona — sem ele, a cadeia de confiança está incompleta e resolvers com validação DNSSEC tratam sua zona como não assinada, não como inválida. O processo de cadastro do DS varia por registrador: alguns têm interface gráfica no painel de controle, outros exigem que você passe os campos manualmente — Key Tag, Algorithm, Digest Type e Digest. O Cloudflare exibe todos esses valores formatados depois que você ativa DNSSEC.
O problema da rotação de chaves
O risco operacional de DNSSEC não está na ativação — está na manutenção. O Cloudflare rotaciona as chaves DNSSEC da zona periodicamente. Quando isso acontece, o registro DS cadastrado no registrador precisa ser atualizado para refletir a nova chave. Se o registrador suporta atualização automática de DS via API — como é o caso do Cloudflare Registrar, do Amazon Route 53 em modo de domínio registrado e do Namecheap com API habilitada — a rotação acontece sem intervenção manual. Se o registrador não suporta, o Cloudflare envia um alerta e você tem uma janela de tempo para fazer a atualização manualmente.
Perder essa janela tem consequência direta: o DS no registrador aponta para uma chave que a zona não usa mais. Resolvers com validação DNSSEC começam a receber RRSIG assinado por uma chave diferente do DS publicado, concluem que houve adulteração e retornam SERVFAIL para qualquer consulta ao seu domínio. Do ponto de vista do usuário, o domínio simplesmente para de resolver. A correção exige atualizar o DS no registrador e esperar a propagação do TTL da zona TLD — que costuma ser longa, da ordem de horas, porque você não controla esse TTL.
Ativar com segurança: o que verificar antes e depois
Antes de ativar DNSSEC, confirme se o seu registrador aceita DS records para o domínio em questão. Para domínios .com.br, o Registro.br passou a suportar DNSSEC, mas o suporte histórico foi inconsistente — vale verificar diretamente no painel se a opção de DS está disponível para o seu domínio específico antes de ativar no Cloudflare. Ativar no Cloudflare sem conseguir cadastrar o DS no registrador deixa a zona assinada mas sem a cadeia de confiança completa, o que não oferece nenhuma proteção adicional e ainda cria um estado que pode gerar confusão em diagnósticos futuros.
Depois de ativar e cadastrar o DS, teste a validação com ferramentas como dnssec-analyzer.verisignlabs.com ou dnsviz.net antes de considerar o processo concluído. Essas ferramentas mostram cada elo da cadeia de confiança e identificam registros RRSIG inválidos, expirados ou faltando. Configure alertas para a rotação de chaves — o painel do Cloudflare oferece notificações por email — e documente o processo de atualização do DS no seu runbook de operações DNS. Uma rotação mal gerenciada às três da manhã, com o domínio principal da empresa retornando SERVFAIL, é o tipo de incidente que deveria estar no runbook antes de acontecer, não depois.
Considere ativar registros CAA em paralelo. CAA especifica quais autoridades certificadoras estão autorizadas a emitir certificados para o domínio, e o Cloudflare suporta o tipo de registro sem restrições. Combinado com DNSSEC, CAA fecha uma segunda superfície de ataque: mesmo que um atacante consiga enganar uma CA via outra vulnerabilidade, o registro CAA limita quais CAs podem emitir para o domínio.
Leia também
- DNS proxied vs DNS only: o que muda e quando cada modo faz sentido
- Cloudflare DNS: infraestrutura de rede que vai muito além de resolver nomes
- Cloudflare Load Balancing e Geo Steering: quando o DNS vira camada de tráfego inteligente
- Cloudflare Email Routing: receber email no seu domínio — e o que não vem junto
- Cloudflare WAF: o que a proteção gerenciada realmente bloqueia e o que passa
- WAF + Rate Limiting + Bot Management: a trifeta de proteção no edge