DNSSEC: a disponibilidade da aplicação também depende da âncora do resolvedor
A troca da KSK da raiz exige verificar confiança e persistência no resolvedor, não apenas acompanhar a saúde da aplicação.
A raiz do DNS está programada para começar a assinar seu conjunto DNSKEY com a KSK-2024 em 11 de outubro de 2026, substituindo a KSK-2017.[1] Um resolvedor que valida DNSSEC e não confia na nova âncora pode interromper a resolução de domínios, mesmo com servidores e aplicações funcionando.[1] O risco merece entrar no checklist de continuidade, não ficar perdido entre notícias de criptografia.
O que muda para quem desenvolve
A mudança está no início da cadeia de confiança do DNS: a KSK autentica as chaves da raiz, enquanto a ZSK assina outros registros, incluindo os DS dos domínios de primeiro nível.[1] Os identificadores relevantes são 38696 para a chave nova e 20326 para a antiga.[1] Ambas usam RSA/SHA-256; esta troca não introduz um algoritmo pós-quântico.[1]
A leitura de engenharia é simples: um monitor que consulta apenas um endereço IP pode não enxergar o problema vivido por clientes que dependem de resolução de nomes. Vale separar disponibilidade da aplicação, resolução DNS e validação da resposta. São perguntas diferentes no diagnóstico.
O aprendizado automático pelo RFC 5011 exige observar a nova chave por pelo menos 30 dias e validá-la novamente antes de aceitá-la.[1] A Cloudflare lembra que atualizações e trocas de máquina podem apagar esse estado aprendido.[1] Portanto, confiar na automação sem conferir persistência deixa uma hipótese importante sem teste.
Como aplicar
Proponha uma verificação pequena e documentada para cada resolvedor sob sua administração:
- Confirme na configuração ou no estado do software a presença da âncora 38696.
- Registre quais clientes realmente usam esse resolvedor, incluindo os efeitos de VPN e DNS seguro.
- Em um ambiente controlado, verifique se a confiança permanece depois de reiniciar ou atualizar o serviço.
- Compare uma consulta direta ao resolvedor com o caminho usado pelo navegador. Não trate esses resultados como equivalentes.
O teste sentinel apresentado pela Cloudflare faz perguntas opostas sobre a âncora usando is-ta-38696 e not-ta-38696.[1] Em um validador compatível que já confia na chave, a primeira consulta funciona e a segunda retorna SERVFAIL deliberadamente.[1] Aqui, um erro esperado pode ser evidência de funcionamento correto. Registre a expectativa antes de executar o teste.
Cuidados e limites
Sem suporte comprovado ao sentinel, o teste é inconclusivo, não prova de chave ausente.[1] Não use essa incerteza como motivo automático para desligar DNSSEC. Consulte a configuração e o fornecedor.
Segundo a Cloudflare, usuários de 1.1.1.1, Gateway DNS e de seu DNS autoritativo não precisam alterar nada para essa troca.[1] Isso não confirma a prontidão de outros resolvedores. A revogação e a retirada da chave antiga são etapas previstas para 2027.[1] O trabalho não termina quando a primeira assinatura nova aparece.
Fonte
[1] Fonte: Cloudflare Blog. Data/hora no feed: 06/10/2026 às 14:50:11.