Resumo

  • Uma observação de 13 de setembro constatou que o glue IPv6 de .ps na raiz coincide com o endereço atual do hostname da RIPE NCC; as divergências de .ne, .sd e .tj permanecem.
  • A RIPE NCC informou que a IANA não podia processar os pedidos sem a aprovação dos contatos dos ccTLDs. O desfecho desigual é compatível com quatro fluxos de autorização independentes.
  • Não há demonstração de indisponibilidade. Todas as delegações mantinham glues IPv6 e IPv4 alternativos. Falta um recibo público e seguro que registre o estado de cada caso.

A diferença entre quatro e três parece pequena demais para mudar uma avaliação de risco. No entanto, ela muda a interpretação do trabalho. Se uma entrada convergiu e três não, a lista nunca foi uma unidade operacional — apenas quatro dependências reunidas pela mesma origem técnica.

Em 15 de agosto, Patrik Wallstrom relatou ao grupo de trabalho DNS da RIPE que a zona raiz ainda continha glues IPv6 antigos para ne.cctld.authdns.ripe.net, ps.cctld.authdns.ripe.net, sd.cctld.authdns.ripe.net e tj.cctld.authdns.ripe.net. Em janeiro, a RIPE NCC havia anunciado a conclusão da renumeração IPv6 do AuthDNS, a retirada completa do /48 anterior e o encerramento da maior parte da limpeza.

A resposta da RIPE NCC em 20 de agosto expôs o limite institucional. A organização tentou e-mail, telefone e contatos regionais, além de abrir pedidos na IANA. Eles não podiam ser processados sem a aprovação dos contatos dos ccTLDs. Cabe aos administradores de cada TLD manter seus dados de delegação na raiz.

Essa exigência não é um atraso acidental. Ela impede que o operador de um servidor altere unilateralmente uma delegação administrada por outra parte, mesmo quando conhece melhor que ninguém o novo endereço de sua infraestrutura.

O quarto caso tomou outro rumo

A coleta congelada ocorreu às 17h14 UTC de 12 de setembro, já 13 de setembro em Xangai. Ela comparou referências de a.root-servers.net e b.root-servers.net com respostas dos hostnames obtidas em 1.1.1.1 e 8.8.8.8.

Para .ps, os dois servidores raiz retornaram 2a13:27c0:30::105 como glue. Os dois resolvedores devolveram o mesmo AAAA atual para ps.cctld.authdns.ripe.net. A página de delegação da IANA também exibia esse endereço e registrava 8 de setembro como data geral de atualização.

Os outros três pares não coincidiam. Em .ne, a raiz serviu 2001:67c:e0::101 e o hostname respondeu 2a13:27c0:30::101. Em .sd, os valores foram 2001:67c:e0::109 e 2a13:27c0:30::109; em .tj, 2001:67c:e0::117 e 2a13:27c0:30::117. Os endereços IPv4 coincidiram em 193.0.9.101, .109 e .117.

Isso demonstra que as quatro divergências de agosto haviam se tornado três no momento observado. Não revela quem apresentou ou aprovou a alteração de .ps, nem quando a raiz começou a publicá-la. A data de uma página inteira tampouco identifica qual campo mudou. O resultado separado, porém, corresponde ao modelo de autorização descrito pela RIPE NCC.

Continuidade não absolve o dado antigo

Segundo a RIPE NCC, cada delegação possuía pelo menos outro glue IPv6 em funcionamento e vários glues IPv4, permitindo aos resolvedores seguir a delegação e localizar o serviço autoritativo. Portanto, um glue antigo não prova queda do ccTLD.

Esta pesquisa não enviou pacotes aos endereços IPv6 antigos. Não mediu alcance, atraso de novas tentativas nem efeito para usuários. Não há evidência de delegação defeituosa, falha de DNSSEC, problema dos resolvedores ou perda do serviço autoritativo. Por sua vez, as rotas alternativas não garantem que todo resolvedor tenha seguido o mesmo caminho sem latência.

O controle de continuidade deve ser preservado, e o registro incorreto deve ser corrigido. Não há contradição. A contradição surgiria se a pressa para limpar uma referência ao prefixo retirado fosse usada para contornar a autorização do administrador do TLD.

Um encerramento histórico não é um estado atual

A auditoria de operações da raiz da IANA de julho de 2025 lista pedidos de mudança envolvendo os quatro hostnames, marcados como Administratively Closed em 18 de julho de 2025. A tabela pública não fornece o motivo individual. São resultados históricos, não o painel dos pedidos posteriores mencionados pela RIPE NCC, e não explicam o alinhamento de .ps.

Hoje, cada registro público conta apenas um trecho. A auditoria mostra que um pedido antigo terminou. A página de delegação mostra o dado publicado. A consulta DNS mostra a resposta em um instante. Nenhum deles une solicitante, autorização do administrador, verificação técnica, desfecho e observação da raiz em uma única história de caso.

Um recibo por delegação

Um recibo que preserve a privacidade pode identificar TLD, hostname, endereço antigo e solicitado, papel do solicitante e referência pública segura. Deve registrar estado e horário da autorização, resultado das verificações técnicas, implementação, retirada, encerramento ou substituição, além de uma categoria de motivo.

Para fechar o ciclo, incluiria serial da zona raiz ou horário de observação, glue servido no momento, próxima ação e pedido sucessor. Não é necessário publicar nomes pessoais ou correspondência. O objetivo é distinguir “aguarda autorização” de “falhou na validação”, “retirado” ou “implementado”.

As atas do grupo DNS na RIPE 91 descrevem a renumeração como melhoria operacional e registram o plano de capturar consultas ainda enviadas aos antigos endereços IPv6 depois do desligamento. A telemetria mostra uso residual. O recibo mostra a autoridade e a decisão necessárias para encerrá-lo.

O total pode ser três. A responsabilidade continua dividida em quatro casos.

Fontes