A troca de chaves do DNS raiz que pode derrubar seus aplicativos em outubro (e o que fazer antes do dia 11)
O Grande Dia Está Chegando: Rollover da Chave Raiz do DNS
Se você mexe com infraestrutura de DNS, anota na agenda: 11 de outubro de 2026. Num domingo qualquer, a ICANN vai fazer a troca da chave de assinatura da zona raiz — a famosa Root KSK. Isso pode parecer coisa de bastidores técnicos, mas o impacto é bem real.
O problema? Se o seu resolver não estiver preparado para a nova chave, ele não vai simplesmente falhar na validação de algumas assinaturas. Vai parar de resolver tudo. Ponto final. Tela preta.
Vou te explicar o que está rolando e, mais importante, o que você precisa fazer antes desse dia chegar.
Primeiro: O Que É Essa Tal de Root KSK?
Imagina a hierarquia do DNS como uma corrente. Cada elo confia no anterior, e assim por diante. No topo dessa corrente está a zona raiz, e é lá que fica a Root KSK — uma chave criptográfica que amarra toda a validação DNSSEC da internet.
Quando o seu resolver faz uma consulta num domínio assinado com DNSSEC, ele rastreia a cadeia de assinaturas até chegar nessa chave raiz. Se o seu resolver não reconhece a Root KSK atual, a corrente quebra. Simples assim.
A ICANN faz essa rotação periodicamente por uma razão de segurança. Trocar chaves regularmente reduz o risco de comprometimento a longo prazo e mantém a infraestrutura criptográfica firme contra ameaças que só ficam mais sofisticadas com o tempo.
Como Funciona Essa Troca de Chaves?
Durante o rollover, a chave que assina a chave de zona (ZSK) muda. A nova KSK gera novas assinaturas, e os trust anchors — os registros que dizem "confie nessa chave" — precisam ser atualizados.
Aqui está o detalhe crítico: quando um resolver com validação DNSSEC encontra uma assinatura que não consegue verificar porque a chave raiz não está no seu armazenamento de confiança, ele retorna SERVFAIL. Na prática, isso significa NXDOMAIN para toda e qualquer consulta. Seja o domínio real ou não. Nada funciona.
Não é teoria. Isso já aconteceu antes, e sempre tem resolver desatualizado que dá problema.
Quem Precisa se Preocupar?
Se você roda BIND, Unbound, Knot Resolver ou qualquer resolver que faz validação DNSSEC, preste atenção.
Para a maioria dos casos, a atualização é automática. Sistemas operacionais e distribuições de software DNS normais recebem as chaves via mecanismos padrões de atualização.
Agora, se você cai numa dessas situações, precisa agir manualmente:
- Infraestrutura DNS customizada, montada do zero
- Dispositivos IoT ou embarcados com mecanismos de update limitados ou inexistentes
- Resolvers internos com configurações trancadas que ninguém mexe há anos
- Sistemas isolados (air-gapped) que não recebem updates regulares
Como Saber Se O Seu Resolver Está Preparado?
Boa notícia: verificar é simples. Faz uma query direto no seu resolver pedindo o registro DNSKEY da raiz:
dig @<ip-do-seu-resolver> DNSKEY . +multi
Procura pelas entradas KSK — elas têm o flag com valor 257. Compara com a KSK atual publicada pela ICANN na documentação deles.
Se usa BIND, verifica a configuração de trusted-keys ou dnssec-validation auto. Versões modernas do BIND com dnssec-validation auto buscam e atualizam as chaves raiz automaticamente usando o RFC 5011.
DNSSEC: Por Que Isso Importa Tanto?
O DNS foi criado numa era de inocencia. Não tinha verificação criptográfica. Quando você pergunta "qual o IP do exemplo.com?", como sabe que a resposta veio dos servidores legítimos e não de alguém no meio do caminho inventando números?
DNSSEC resolve isso adicionando assinaturas digitais aos registros DNS. Cada zona assina os seus registros, e zonas pai autenticam as chaves das zonas filho. A raiz é o ponto de partida de tudo.
Sem validação DNSSEC, suas aplicações estão expostas a envenenamento de cache DNS, ataques man-in-the-middle e desvio de tráfego. Nos últimos anos, a adoção de validação DNSSEC entre grandes provedores só aumentou — o que torna esses rollovers cada vez mais críticos para manter a internet funcionando.
Checklist Para as Próximas Semanas
- Inventaria os seus resolvers — Descobre quais fazem validação DNSSEC
- Checa a configuração de trust anchors — Asegura que referenciam a chave atual e a nova
- Testa num ambiente controlado — Se for fazer mudanças, valida antes do domingo
- Monitora depois do rollover — Fica de olho em picos de SERVFAIL ou falhas de resolução
- Documenta tudo — Essa dança se repete a cada cinco anos aproximadamente
E Se Você Não Se Preparar?
No melhor cenário, você vê falhas intermitentes de resolução. No pior, o seu resolver vira um tijolo para.domínios assinados com DNSSEC — que, convenhamos, é cada vez mais a internet inteira.
Esse rollover não é só problema da ICANN. É responsabilidade compartilhada. Dedica trinta minutos essa semana para auditar os teus resolvers. Os teus usuários vão agradecer quando domingo chegar e tudo继续 funcionando.
Fica seguro. Fica validado.
Quer saber mais sobre DNSSEC e práticas de DNS? Dá uma olhada nos nossos guias de infraestrutura e serviços de DNS gerenciado.