Uma mudança silenciosa, mas importante, está marcada para 11 de outubro de 2026: a chave criptográfica que sustenta a validação DNSSEC na raiz da internet será trocada. Para a maioria das pessoas, nada deve mudar. Para uma rede com resolvedor próprio desatualizado, porém, o efeito pode parecer uma queda total da internet — sites, e-mail e aplicativos deixam de encontrar seus servidores mesmo que a conexão continue ativa.
A ICANN reforçou o alerta no fim de julho de 2026. Segundo a organização, mais de 95% dos resolvedores que enviam os sinais analisados já reconhecem a nova chave. É um número tranquilizador, mas não elimina o risco em equipamentos antigos, appliances sem atualização, instalações isoladas e configurações que mantêm a âncora de confiança manualmente.
É justamente aí que o benchmark entra: antes da mudança, ele estabelece a latência e a disponibilidade normais dos resolvedores usados pela rede. No dia do rollover, permite separar rapidamente um problema de DNS de uma falha de Wi-Fi, operadora ou aplicação.
O que vai mudar em 11 de outubro de 2026?
O DNSSEC acrescenta assinaturas criptográficas ao DNS. O resolvedor usa essas assinaturas para verificar se a resposta recebida é autêntica e não foi alterada no caminho. No topo dessa cadeia está a Key Signing Key da zona raiz, ou KSK, que funciona como uma âncora de confiança global.
A chave atual, chamada KSK-2017, tem o identificador 20326. Sua substituta, KSK-2024, usa o identificador 38696. A nova chave foi publicada com antecedência para que resolvedores compatíveis com a atualização automática definida pela RFC 5011 pudessem aprendê-la sem interrupção.
| Etapa | Data | O que acontece |
|---|---|---|
| Pré-publicação | 11 de janeiro de 2025 | A KSK-2024 aparece na zona raiz |
| Confiança automática | a partir de 10 de fevereiro de 2025 | Resolvedores compatíveis podem passar a confiar na nova chave |
| Rollover | 11 de outubro de 2026 | A KSK-2024 passa a assinar a raiz |
| Retirada da chave antiga | janeiro de 2027 | A KSK anterior sai do conjunto ativo |
Não se trata de mudar o algoritmo criptográfico: o rollover de 2026 continua usando RSA com SHA-256. É a troca do par de chaves dentro do processo normal de manutenção do DNSSEC.
Quem precisa tomar alguma providência?
Usuários domésticos
Se você usa o DNS recebido automaticamente da operadora ou um serviço público como Cloudflare, Google Public DNS ou Quad9, a atualização é responsabilidade do operador. Não é necessário alterar senhas, registrar novamente domínios nem trocar o endereço DNS só por causa do rollover.
Ainda assim, vale conhecer a data. Se muitos sites pararem de abrir ao mesmo tempo em 11 de outubro, mas mensagens já carregadas e conexões por IP continuarem funcionando, o resolvedor DNS deve entrar cedo na investigação.
Empresas, provedores e laboratórios
É preciso agir se a organização opera um resolvedor recursivo que valida DNSSEC, especialmente quando ele:
- usa uma âncora de confiança configurada manualmente;
- roda uma versão antiga de BIND, Unbound, PowerDNS Recursor ou Knot Resolver;
- ficou desligado ou sem acesso à zona raiz durante longos períodos;
- está embutido em firewall, roteador, appliance de segurança ou firmware sem suporte;
- não consegue gravar no diretório em que mantém as chaves atualizadas.
A orientação publicada pela ICANN é procurar a key tag 38696 no arquivo de âncoras usado pelo software. Os nomes mais comuns são bind.keys no BIND, root.key no Unbound e PowerDNS Recursor, e root.keys no Knot Resolver. O caminho exato e o procedimento de atualização variam; siga a documentação da versão instalada.
Como testar se o resolvedor valida DNSSEC
O teste abaixo, recomendado pela ICANN, deve ser feito por quem administra o servidor. Substitua ENDERECO_DO_DNS pelo IP do resolvedor:
dig @ENDERECO_DO_DNS dnssec-failed.org A +dnssecO domínio de teste tem uma validação propositalmente inválida. Por isso:
status: SERVFAILindica que o resolvedor detectou a assinatura inválida e está validando DNSSEC;status: NOERRORindica que ele entregou a resposta sem validar DNSSEC.
Esse comando confirma se há validação, mas não prova sozinho que a KSK-2024 está salva. A etapa decisiva é conferir a key tag 38696 no arquivo de âncoras e nos logs do software. Reinicie ou recarregue o serviço apenas conforme o procedimento do fornecedor; uma alteração improvisada na âncora de confiança pode causar exatamente a falha que se pretende evitar.
Como preparar uma linha de base com DNS Benchmark
Uma auditoria curta agora torna o diagnóstico de outubro muito mais rápido:
- Teste o DNS realmente usado pela rede. Inclua o resolvedor corporativo, o DNS do provedor e os resolvedores públicos aprovados pela sua política.
- Registre latência média, P95, jitter e disponibilidade. Uma média baixa não compensa consultas que falham. Para este evento, disponibilidade e taxa de erro têm prioridade.
- Repita em horários diferentes. Faça medições em horário comercial e fora do pico para não confundir congestionamento comum com comportamento anormal.
- Guarde os resultados de agosto e setembro. Eles serão a referência anterior ao rollover.
- Repita o mesmo conjunto em 11 e 12 de outubro. Mudanças bruscas em um único resolvedor apontam para ele; falhas amplas pedem investigação da cadeia DNSSEC e da conectividade.
Para uma rotina mais detalhada de auditoria, veja o guia de DNS Benchmark para profissionais de TI.
Quais sintomas indicam uma âncora desatualizada?
Um resolvedor validador que não confia na nova KSK pode deixar de validar a raiz. Como toda a cadeia DNSSEC parte dela, o problema não fica restrito a um domínio específico.
Os sinais típicos são:
- vários sites não abrem ao mesmo tempo;
- aplicativos exibem “servidor não encontrado” mesmo com a rede conectada;
- consultas retornam
SERVFAIL; - outro resolvedor atualizado responde normalmente na mesma conexão;
- ping para um IP conhecido funciona, mas nomes de domínio não resolvem;
- os logs do resolvedor citam falha de validação, trust anchor ou DNSKEY.
Esses sintomas também podem ter outras causas. O diagnóstico deve comparar resultados, códigos de resposta e logs, em vez de concluir apenas pela latência.
Trocar para o DNS mais rápido resolve?
Só se o problema estiver no resolvedor atual. O rollover não torna automaticamente Cloudflare, Google ou Quad9 mais rápido; ele testa se cada operador mantém sua cadeia de confiança atualizada.
Em uma rede doméstica, comparar resolvedores públicos pode revelar rapidamente que o DNS fornecido pelo roteador deixou de responder. Em uma empresa, trocar o DNS sem autorização pode quebrar nomes internos, filtragem e políticas de segurança. O caminho correto é manter um resolvedor alternativo aprovado e previamente testado, com o mesmo nível esperado de validação DNSSEC.
Também não é boa prática misturar um resolvedor validador com outro que ignora DNSSEC. Dependendo do sistema operacional, as consultas podem alternar entre eles, produzindo resultados inconsistentes e enfraquecendo a proteção.
O ponto principal é simples: para o usuário comum, a troca deve ser invisível. Para quem opera DNS, “provavelmente atualizou sozinho” não substitui uma verificação. Cinco minutos para localizar a key tag correta e uma linha de base de benchmark podem evitar horas de diagnóstico no dia da mudança.
