Atualizado em 18 de outubro de 2026. A troca prevista neste artigo aconteceu: a KSK-2024, identificador 38696, começou a assinar a zona raiz em 11 de outubro. A IANA confirmou a entrada em uso da nova chave. Comunicado da IANA.
Em 15 de outubro, a ICANN informou que a troca ocorreu conforme planejado. Há relatos de problemas em um número limitado de sistemas, cuja possível relação com o rollover continua em avaliação. Isso não equivale a uma falha generalizada. Balanço da ICANN.
O que mudou e o que ainda falta?
DNSSEC permite verificar a autenticidade dos dados DNS por uma cadeia de assinaturas. A KSK da raiz é a âncora no topo dessa cadeia. Um resolvedor que valida DNSSEC precisa confiar na chave correta para verificar as respostas.
| Marco | Situação |
|---|---|
| Publicação antecipada da KSK-2024 | Realizada para permitir a atualização dos resolvedores |
| Uso da KSK-2024 para assinar a raiz | Iniciado em 11 de outubro de 2026 |
| Revogação da KSK anterior | Prevista para janeiro de 2027 |
A IANA mantém o cronograma e as âncoras oficiais. A ativação da chave nova não encerra todas as etapas de manutenção.
Quem precisa verificar o ambiente agora?
Usuários de resolvedores mantidos pela operadora ou por serviços públicos normalmente dependem da atualização feita pelo operador. Não há motivo para trocar senhas ou alterar o endereço DNS apenas porque a chave mudou.
Administradores de resolvedores próprios devem conferir a key tag 38696 no estado de confiança efetivamente usado pelo software. Priorize instalações antigas, âncoras manuais, appliances sem suporte e servidores que ficaram desligados por muito tempo.
O mecanismo da RFC 5011 permite atualizar âncoras automaticamente, mas a operação depende de o resolvedor manter o estado e acompanhar as mudanças. Verifique a documentação da versão instalada antes de recarregar o serviço ou editar arquivos.
Como investigar SERVFAIL após a troca
Nossa recomendação é começar por duas consultas ao mesmo resolvedor, substituindo ENDERECO_DO_DNS:
dig @ENDERECO_DO_DNS cloudflare.com A +dnssec
dig @ENDERECO_DO_DNS dnssec-failed.org A +dnssecO segundo domínio tem DNSSEC propositalmente inválido. Uma resposta SERVFAIL nele, isoladamente, não comprova que o servidor está validando: um resolvedor com a âncora quebrada também pode falhar em todas as consultas.
Confira se o primeiro domínio resolve, se há indicação de autenticação (ad, quando aplicável), e se o domínio inválido é rejeitado. Depois examine os logs de validação, o relógio do servidor e as âncoras. Nem esse par de testes substitui a inspeção da configuração nem qualquer SERVFAIL prova relação com o rollover.
Como usar o benchmark depois do evento
Compare os resultados atuais com medições anteriores, se disponíveis. Sem histórico, registre uma referência agora: mesmo conjunto de domínios, mesma rede e horários comparáveis. Observe disponibilidade, erros, mediana, P95 e jitter quando disponíveis.
A latência ajuda a investigar, mas não identifica sozinha uma falha criptográfica. Para a rotina operacional, consulte DNS Benchmark para profissionais de TI. Em empresas, use somente alternativas DNS aprovadas para preservar nomes internos e políticas de acesso.
Esta troca tornou o DNS pós-quântico?
Não. Substituir uma chave e migrar o algoritmo de assinatura são processos diferentes. Leia também o que muda com DNSSEC pós-quântico no 1.1.1.1.
