O DNS responde a cada cliente onde está o servidor que ele quer alcançar — e, sem assinaturas, qualquer resposta pode ser forjada por quem conseguir se intrometer no caminho. O DNSSEC é o conjunto de extensões que fecha essa lacuna: ele permite provar que uma resposta veio da zona autoritativa e que não foi alterada em trânsito. Equipes que administram domínios públicos e resolvedores internos devem tratar o tema como configuração de base, não como projeto futuro: a ação prioritária é assinar as zonas próprias e ativar a validação nos resolvedores que a empresa consome.
O ataque que a extensão interrompe é o envenenamento de cache: o invasor injeta respostas falsas para desviar usuários a servidores dele, colhendo credenciais e cookies. O abuso do DNS também sustenta a infraestrutura criminosa que troca de endereço constantemente, como no fast flux usado pela hospedagem de golpes. A resposta criptográfica segue a mesma lógica de verificação em cadeia que já protege artefatos de software, como no controle de admissão de imagens no Kubernetes: quem consome confere a assinatura antes de confiar no conteúdo.
O que a extensão garante
A norma do IETF que define o serviço, a RFC 4033, é direta: o DNSSEC acrescenta autenticação de origem e proteção de integridade aos dados do DNS, além de distribuir as chaves públicas usadas na verificação. O documento também delimita o que não entra no pacote: as extensões não fornecem confidencialidade, ou seja, a consulta continua legível para quem observa a rede. Quem precisa de sigilo no transporte deve combinar a validação com DNS sobre TLS ou DNS sobre HTTPS — são camadas independentes.
Há limites que a operação precisa conhecer antes de prometer proteção. A assinatura prova a origem dos registros, não a idoneidade do operador da zona: um servidor autoritativo comprometido pode publicar registros maliciosos perfeitamente assinados. Também não há defesa contra indisponibilidade — um ataque de negação de serviço continua derrubando a resolução. Por isso o DNSSEC é um controle de integridade, e não um substituto de filtragem, monitoramento e resposta a incidentes.
Como funciona a cadeia
A validação parte da chave pública da zona raiz, distribuída junto com o software resolvedor. A partir dela, uma sequência alternada de registros DNSKEY e DS forma a cadeia de confiança na qual cada elo atesta o próximo até a zona raiz. O registro DS, publicado na zona pai, guarda um hash da chave da zona filha; o resolvedor segue essa amarração de ponta a ponta, verificando as assinaturas (registros RRSIG) em cada nível. Se qualquer elo falhar — assinatura inválida, chave divergente ou DS ausente onde a zona declara estar assinada — a resposta inteira é descartada.
A cadeia também prova inexistência: registros NSEC e NSEC3 permitem verificar de forma assinada que um nome ou tipo não existe na zona, o que fecha a brecha de o atacante simplesmente inventar um subdomínio. Sem essa prova, “não existe” não seria verificável — e a garantia ficaria incompleta.
É essa amarração que torna o DS o registro mais sensível da operação: publicá-lo no registrador liga a zona à cadeia; removê-lo devolve a zona ao estado não assinado, mas com atraso de propagação. Tratar qualquer mudança de DS como alteração sensível, com janela de propagação e reversão planejadas, evita as indisponibilidades clássicas de migração malfeita.
Como assinar a zona
Em provedores gerenciados, o trabalho pesado é do fornecedor: ao ativar o DNSSEC, a plataforma assina a zona, publica as chaves e gera o registro DS que você cadastra no painel do registrador. A documentação de DNSSEC da Cloudflare descreve exatamente esse fluxo e adota o algoritmo 13, o ECDSA Curve P-256 com SHA-256, como opção preferida — compacto, moderno e aceito pela ampla maioria dos TLDs.
| Etapa | Onde acontece | Como verificar |
|---|---|---|
| Gerar e publicar chaves | Provedor autoritativo | consulta ao registro DNSKEY do domínio retorna as chaves |
| Assinar os registros | Provedor autoritativo | resposta com a opção +dnssec traz registros RRSIG |
| Publicar o DS | Painel do registrador | consulta ao registro DS do domínio retorna o dado cadastrado |
| Confirmar a cadeia | Verificador externo | resultado seguro em testador público de DNSSEC |
| Vigiar expiração | Operação contínua | alerta quando o RRSIG estiver perto de vencer |
O erro comum é a migração: ao trocar os servidores de nome de um domínio já assinado, o DS antigo precisa sair antes, e a documentação da Cloudflare registra que a expiração do TTL do DS costuma levar de 24 a 48 horas na maioria dos TLDs. Ignorar essa janela deixa o domínio inacessível para quem valida — e como grande parte da internet valida, o efeito é de queda geral, não de incidente isolado. Na reversão, a ordem importa: remova o DS e mantenha a assinatura ativa até o TTL expirar por completo.
Erros comuns de operação
Alguns tropeços se repetem em toda implantação. O primeiro é o registrador que não aceita o algoritmo moderno: quando o painel não oferece o ECDSA Curve P-256 com SHA-256, a orientação da Cloudflare é exigir suporte do registrador, transferir o domínio ou comunicar o caso à ICANN. O segundo é a troca de provedor sem plano: existe um caminho de migração ativa com multiassinatura (multi-signer DNSSEC) que evita tempo de inatividade, desde que o provedor atual aceite registros DNSKEY externos; sem esse suporte, resta a janela sem proteção descrita acima. O terceiro é esquecer que zonas secundárias e subdomínios delegados têm requisitos próprios de assinatura e de publicação de DS — cada zona precisa da própria amarração na cadeia.
Validação no resolvedor interno
Assinar a zona só protege quem, do outro lado, valida. Resolvedores públicos de grande escala já validam por padrão, mas o ambiente corporativo costuma encaminhar consultas para caches e encaminhadores sem verificação. O caminho recomendado é consolidar a saída DNS em um resolvedor próprio com validação: o Unbound, da NLnet Labs, é um resolvedor DNS recursivo, com cache e validação DNSSEC integrada, distribuído como software livre e empacotado nas principais distribuições Linux e BSD.
Em um ambiente de teste próprio, a checagem leva minutos: consulte um domínio sabidamente assinado e confirme a presença da flag “ad” (authenticated data) na resposta; depois provoque uma falha deliberada, com um DS incorreto na bancada, e verifique se o resolvedor responde SERVFAIL em vez de entregar a resposta corrompida. Esse comportamento de recusar é o que protege o usuário final — e também é o que expõe a operação quando uma zona legítima quebra a assinatura, porque a falha aparece do lado de quem valida.
Prioridades e sinais a monitorar
- P1 — assinar os domínios de produção: comece pelo domínio principal e pelos usados em login, e-mail e pagamentos.
- P1 — ativar validação na saída DNS corporativa: um resolvedor validador na borda protege toda a rede interna.
- P2 — automatizar rotação e expiração: chaves e RRSIG vencem; alertas de vencimento evitam queda silenciosa.
- P2 — documentar a reversão: o procedimento de remoção do DS, com janela de TTL, precisa estar escrito antes da crise.
Dois sinais merecem painel próprio: pico de SERVFAIL no resolvedor (cadeia quebrada em zona legítima ou resposta forjada sendo bloqueada) e domínios próprios com RRSIG próximo do vencimento. Ambos são baratos de monitorar e antecipam os dois modos de falha reais da operação: indisponibilidade por assinatura vencida e perda da proteção por remoção acidental do DS. A base normativa de todo o processo está na RFC 4033 do IETF, que define os serviços entregues e os que ficam de fora.