Está previsto que a raiz do Sistema de Nomes de Domínio (DNS) altere a chave de assinatura de chaves pela segunda vez em toda a sua história, quando a KSK-2024, com o identificador de chave 38696, substituir a KSK-2017, com o identificador 20326, em 11 de outubro de 2026. A alteração é especialmente relevante para os operadores de resolvedores DNS que validam DNSSEC, pois não confiar na nova chave poderá tornar sites legítimos inacessíveis aos usuários desses resolvedores.
O que muda na cadeia de confiança?
O DNSSEC usa assinaturas criptográficas para verificar se os registros DNS são autênticos e não foram alterados. A cadeia de confiança começa com uma chave pública previamente confiável no resolvedor, conhecida como âncora de confiança, e então se estende da raiz do DNS aos domínios de primeiro nível, como .com, e deles aos domínios finais.
A chave de assinatura de zona (ZSK) assina os registros da raiz, enquanto a chave de assinatura de chaves (KSK) assina o conjunto de registros DNSKEY que inclui as chaves da raiz. Portanto, a troca da KSK altera o ponto de partida usado pelo resolvedor para validar o restante da cadeia, mesmo com a permanência do mesmo algoritmo de assinatura.
Os operadores de sites precisam tomar alguma medida?
A maioria dos operadores de sites não precisa alterar as configurações de seus domínios. Já aqueles que administram resolvedores DNSSEC devem confirmar que o resolvedor confia na KSK-2024 e seguir as instruções do fornecedor do software para atualizar as âncoras de confiança caso a chave esteja ausente.
A Cloudflare afirma que os usuários do DNS de seus domínios, ou dos serviços 1.1.1.1 e Gateway DNS, não precisam tomar nenhuma medida, pois seus sistemas confiam na nova chave. A KSK-2024 foi incluída na zona raiz em 11 de janeiro de 2025, dando tempo suficiente para que os resolvedores compatíveis com a atualização automática segundo a RFC 5011 a detectassem e aceitassem. A Cloudflare também adicionou a chave às âncoras de confiança incorporadas ao software de seu resolvedor desde julho de 2024.
Como testar a preparação
A Cloudflare disponibiliza um teste em dnstest.dev/ksk-2024 que pergunta ao resolvedor usado pelo navegador se ele confia na nova chave. O teste baseia-se na RFC 8509, que define um mecanismo chamado Root Key Trust Anchor Sentinel para consultar o estado da âncora de confiança.
O teste usa dois nomes opostos: is-ta-38696 para verificar se a chave é confiável, e not-ta-38696 para verificar se ela não é confiável. Para um resolvedor que valida DNSSEC e oferece suporte ao mecanismo, a resposta bem-sucedida ao primeiro nome é válida, enquanto a resposta ao segundo nome é SERVFAIL quando a KSK-2024 é confiável.
No entanto, um resultado inconclusivo não significa necessariamente que a chave esteja ausente; o resolvedor pode não oferecer suporte ao mecanismo sentinel. Além disso, o teste do navegador mede o caminho do resolvedor usado efetivamente pelo navegador e pode ser afetado pelo recurso Secure DNS ou por uma rede VPN. Como alternativa, é possível enviar as consultas diretamente ao 1.1.1.1 usando a ferramenta dig.
A alteração da chave não é uma alteração do algoritmo
A KSK-2017 e a KSK-2024 usam o mesmo algoritmo RSA/SHA-256; portanto, o evento de outubro não representa uma transição para um novo algoritmo. A alteração continuará em 2027, quando a ICANN planeja revogar a KSK-2017, removê-la da zona raiz e excluir sua chave privada; essas são etapas separadas da interrupção de seu uso para assinar o conjunto DNSKEY.
A Cloudflare afirma que a rotação periódica das chaves limita o período de uso de uma única chave privada e treina os operadores para distribuir e testar âncoras de confiança antes de transições mais complexas. A ICANN está estudando uma futura transição para ECDSA P-256, e a transição para a criptografia pós-quântica também exigirá uma nova chave raiz e uma cadeia de confiança atualizada.
Por que esta notícia é importante?
O risco prático não está na interrupção dos próprios sites, mas na falha de validação em um resolvedor DNS despreparado, o que poderá aparecer para o usuário como uma impossibilidade de acessar vários domínios. Por isso, o teste da RFC 8509 oferece um indicador prático de que o resolvedor mantém a nova chave, mas depende do suporte do fornecedor a esse mecanismo e não substitui a revisão das configurações das âncoras de confiança pelos operadores da infraestrutura.