A mudança da chave raiz do DNSSEC já ocorreu: o que os operadores devem verificar

A etapa de outubro de 2026 não foi uma transferência da operação da zona raiz do DNS. Foi um rollover da chave de assinatura de chave (KSK) que sustenta o DNSSEC: desde 11 de outubro, a nova KSK-2024, identificada pela etiqueta de chave 38696, assina o conjunto DNSKEY da raiz. A ICANN e a IANA haviam planejado a substituição como parte de uma transição gradual iniciada em 2024. A mudança foi em uma chave criptográfica, não na responsabilidade operacional.

Essa distinção importa. A zona raiz continua sendo o ponto de referência superior da hierarquia DNS, e sua operação não foi transferida para uma nova organização por causa dessa mudança. O que foi atualizado é a chave criptográfica que os resolvedores validadores usam como âncora de confiança para verificar a zona raiz e, por meio dela, a cadeia DNSSEC. Descrever o evento como uma mudança de operador confunde governança e infraestrutura com a renovação de uma chave.

O cronograma da ICANN definiu 11 de outubro de 2026 como a data em que a nova chave começaria a assinar; a retirada da chave anterior foi prevista para uma etapa posterior, esperada para janeiro de 2027. Portanto, em 9 de novembro de 2026, o evento principal já ocorreu, mas o ciclo de manutenção da chave ainda não terminou. As consequências práticas se concentram nos sistemas que fazem validação DNSSEC com configurações antigas ou mantidas manualmente.

O DNS organiza os nomes de domínio em uma hierarquia. No topo está a zona raiz, que publica referências aos domínios de nível superior — como .com, .org e extensões nacionais — e aos servidores responsáveis por eles. Um servidor raiz não armazena o endereço IP de cada site: ele direciona o resolvedor para a próxima etapa da busca.

Quando um resolvedor recursivo não encontra uma resposta no cache, pode consultar uma das identidades raiz. A resposta o direciona ao servidor do TLD correspondente; depois, o resolvedor continua até os servidores autoritativos do domínio. Se a informação já estiver em cache, a consulta pode ser resolvida sem chegar à raiz, que assim não participa de cada visita a uma página.

Também é importante distinguir as 13 identidades raiz nomeadas, de A a M, das máquinas físicas que as atendem. O sistema é distribuído por numerosas instâncias e operadores independentes; a ICANN descreve 13 identidades gerenciadas por 12 operadores e mais de 1.500 servidores individuais. A redundância e o roteamento anycast permitem atender consultas de vários locais, mas não transformam cada instância em um operador distinto nem eliminam a coordenação da zona raiz.

O DNSSEC acrescenta assinaturas criptográficas para que um resolvedor validador possa verificar a autenticidade e a integridade dos dados DNS. A KSK raiz valida o conjunto DNSKEY da zona raiz; outras chaves dessa zona são usadas na cadeia que verifica as referências aos domínios de nível superior. A nova chave não altera a estrutura dos domínios nem os registros dos sites: ela renova o ponto de partida criptográfico dessa verificação.

A KSK-2024 foi publicada na zona raiz em 11 de janeiro de 2025, com antecedência suficiente para que resolvedores compatíveis com a atualização automática de âncoras de confiança pudessem conhecê-la. Em 11 de outubro de 2026, ela começou a assinar a zona raiz. A chave anterior, KSK-2017, não deve ser confundida com a nova: começar a assinar e remover definitivamente uma chave são etapas distintas do processo.

Essa substituição não representa uma migração para um algoritmo criptográfico diferente. A ICANN e a Cloudflare descrevem a KSK-2017 e a KSK-2024 como chaves que usam RSA/SHA-256. Assim, o rollover atual testa e renova a distribuição da confiança, mas não significa que a raiz tenha passado para a criptografia pós-quântica. Uma mudança de algoritmo exigiria compatibilidade adicional nos resolvedores e seria um processo separado.

A maioria das pessoas não precisa fazer nada no telefone, no computador ou no roteador. Quem usa resolvedores administrados pelo provedor de Internet ou por um serviço público de DNS depende desses operadores para manter o software e as âncoras de confiança atualizados. Não é necessário trocar de servidor DNS simplesmente porque a KSK foi renovada.

O trabalho cabe principalmente aos administradores de resolvedores recursivos que validam DNSSEC, sobretudo quando mantêm âncoras manuais, executam software antigo ou gerenciam equipamentos que ficaram desconectados por longos períodos. Se o resolvedor não confiar na KSK-2024, poderá rejeitar a validação de respostas corretamente assinadas. Para quem depende desse resolvedor, um possível sintoma é que alguns nomes não sejam resolvidos, mesmo que os sites e seus servidores estejam funcionando.

Uma resposta SERVFAIL, por si só, não prova que a nova chave esteja ausente: outros problemas de configuração ou validação podem produzir a mesma resposta. A verificação relevante é o estado de confiança efetivamente usado pelo resolvedor, não apenas a presença da chave em uma resposta DNS. A ICANN identifica a KSK-2024 pela etiqueta 38696. Os administradores devem compará-la com os procedimentos e arquivos de âncoras do software e não remover manualmente a chave antiga fora do cronograma oficial.

A renovação da KSK diz respeito à validação criptográfica do DNSSEC. A latência de uma consulta depende, entre outros fatores, da localização do resolvedor, das rotas da Internet e de a resposta estar ou não em cache; o rollover, por si só, não permite concluir que haverá uma melhoria geral de latência.

A função de segurança do DNSSEC é ajudar a detectar respostas DNS não autênticas ou alteradas, e não criptografar as consultas por conta própria nem ocultar o nome solicitado. A troca da chave mantém a capacidade de validar a zona raiz com uma chave renovada, mas não substitui outras medidas de segurança, como a manutenção do resolvedor, a proteção dos sistemas ou a criptografia do transporte DNS quando apropriado.

O processo também testa a coordenação entre publicar uma nova chave, adotá-la nos resolvedores e retirar a anterior. O primeiro rollover da KSK raiz ocorreu em 2018; a transição atual é a segunda. A continuidade depende de os sistemas validadores terem uma âncora válida, enquanto a arquitetura distribuída e os caches aumentam a resiliência em outras partes da resolução. São mecanismos complementares, não intercambiáveis.

Se você administra um resolvedor com validação DNSSEC, verifique se a configuração confia na KSK-2024 (etiqueta de chave 38696) e se o mecanismo de atualização das âncoras de confiança está funcionando. Consulte a documentação da versão instalada e o estado persistente do serviço: a presença da chave na zona pública não garante que o software a tenha incorporado como âncora de confiança.

Para equipamentos que usam resolvedores de terceiros, diante de erros persistentes de resolução é razoável consultar o estado do serviço ou os avisos do provedor. Não altere os registros de um domínio nem desative o DNSSEC como primeira resposta a SERVFAIL sem identificar antes onde a validação falha. O problema pode estar no resolvedor, em uma zona específica ou em outra parte da cadeia.

A próxima etapa do cronograma descrito pela ICANN é a retirada da KSK-2017, prevista para janeiro de 2027. Até lá, administradores e provedores devem seguir as instruções oficiais e manter as atualizações de segurança habituais. Para os usuários finais, a mensagem é mais simples: não é preciso reconfigurar a conexão por causa deste rollover; a mudança deve ser gerenciada na infraestrutura que valida as consultas.