Resumo

  • O relatório de outubro da APNIC combina uma leitura de julho dos sinais de resolvedores RFC 8145 com novos testes RFC 8509 em sistemas finais. Os cerca de 90% e 70% descrevem caminhos de observação diferentes e não podem ser subtraídos ou tirados em média.
  • A tabela de redes é uma lista para orientar verificações, não uma nota de prontidão de um provedor nem uma estimativa de clientes em risco. Cada operador precisa testar seus próprios resolvedores validadores.

Análise

Um percentual precisa dizer o que observa

Dois dias antes de uma mudança programada na chave DNSSEC da raiz, um percentual de prontidão parece responder à pergunta que todos querem fazer. Se a maioria dos resolvedores já tiver a chave sucessora, a troca deverá ser segura; se não, alguém deveria interrompê-la. O problema está em “maioria”. Um sinal de resolvedor, um teste executado pela conexão de um usuário e as pessoas que dependem dessa rede são unidades distintas.

O relatório publicado pela APNIC em 9 de outubro, redigido no dia 8, reúne duas observações sobre a KSK-2024. A primeira usa a RFC 8145: resolvedores validadores podem sinalizar as etiquetas das chaves em que confiam por meio de consultas visíveis aos operadores de servidores autoritativos. A segunda usa o Root Key Trust Anchor Sentinel da RFC 8509. Um teste parte de um sistema final, e a resposta ajuda a inferir o estado de confiança do resolvedor. É a mesma chave e a mesma data, mas não o mesmo objeto medido.

Há uma nuance importante na descrição da RFC 8145. A APNIC diz que seu gráfico de julho mostra que cerca de 90% dos resolvedores que enviam sinais já haviam incluído a KSK-2024. A atualização da Verisign de 28 de julho diz que a adoção entre as fontes que enviam sinais ultrapassou 95% após cerca de 500 dias. A APNIC atribui o gráfico à Verisign, mas os textos públicos não informam uma data de extração e uma definição de métrica comuns que permitam conciliar os números. Eles podem se referir a recortes ou resumos diferentes; o texto disponível não permite concluir. É uma lacuna documental a preservar, não uma prova de falha de medição.

Os 70% recentes são ainda menos comparáveis diretamente. A APNIC informa que sua plataforma de medição baseada em publicidade realizou em média 16 milhões de testes de sistemas finais por dia. Cerca de 6 milhões mostraram um sistema atrás de um resolvedor recursivo que valida DNSSEC, e aproximadamente 1,8 milhão forneceram um sinal claro de suporte à RFC 8509. Entre os testes que pareciam dar suporte ao mecanismo sentinela, cerca de 70% indicaram que a KSK-2024 estava carregada. O denominador é o subconjunto testado com sinal claro, e não os 16 milhões de testes, todos os resolvedores validadores ou todos os usuários da Internet.

Dois mecanismos, duas perguntas

A RFC 8145 permite que um resolvedor validador informe as etiquetas de chave em sua cadeia de confiança. Ela define dois meios opcionais: uma opção EDNS ou uma consulta especial. No caso da zona raiz, operadores da infraestrutura autoritativa podem observar esses sinais. Os dados mostram como muda o estado declarado pelas fontes que os enviam.

Isso não revela quantas casas, empresas ou serviços dependem de cada resolvedor. Alguns resolvedores recursivos atendem milhões de usuários; outros, apenas uma organização ou um equipamento. Encaminhadores no caminho também podem alterar o que o operador da raiz vê. Portanto, a proporção de sinais enviados responde a uma pergunta sobre esses sinais, não sobre a exposição dos usuários.

A RFC 8509 segue outro caminho. O teste envia consultas DNS especiais; um resolvedor validador compatível responde de acordo com a confiança em determinada chave raiz. A APNIC usa uma plataforma baseada em anúncios para realizar esses testes a partir de sistemas finais. A observação se aproxima mais do caminho de resolução experimentado pelo sistema testado, mas depende da compatibilidade do resolvedor e da classificação da resposta. Ela não identifica todos os resolvedores atrás do sistema nem conta todos os usuários que compartilham um deles.

O teste RIPE Atlas de 5 de outubro oferece uma terceira perspectiva, não uma verificação universal. Probes em 2.900 sistemas autônomos produziram 1.230 comportamentos compatíveis com a nova chave carregada e 47 compatíveis com a chave ainda não carregada. São resultados de probes nessas redes. Não significam que os 2.900 sistemas foram examinados por completo nem mostram quantos clientes dependem de cada resultado.

Medições parciais continuam úteis quando a pergunta de cada uma fica explícita. A RFC 8145 mostra o que os resolvedores que enviam sinais à raiz reportam; a RFC 8509 testa o comportamento de caminhos compatíveis atrás de sistemas finais; a RIPE Atlas acrescenta pontos de observação situados de outra forma. Nenhuma, isoladamente, oferece um denominador completo e ponderado por usuários para toda a Internet.

Uma lista de acompanhamento não é um veredito

A parte mais prática do relatório da APNIC não é o percentual geral. A Tabela 3 lista 50 redes com as menores taxas observadas de aceitação da KSK-2024 na semana anterior, após filtrar redes com menos de 1.000 testes que indicaram suporte ao mecanismo sentinela. O filtro torna as linhas mais informativas que uma observação única, mas não transforma a tabela em auditoria de prontidão.

A lista inclui redes da Ásia-Pacífico, entre elas a National Telecom, na Tailândia, e a Teletalk, em Bangladesh. A APNIC informa 48,4% para a National Telecom em 1.355 testes compatíveis com o sentinela e 48,2% para a Teletalk em 2.046. São números que apontam grupos de testes onde uma verificação adicional pode ser útil. Não provam que todos os resolvedores desses operadores tenham o mesmo estado, que cada resposta corresponda a uma pessoa diferente ou que a mesma proporção de clientes perderá acesso.

A APNIC sugere que as redes listadas testem o próprio caminho, inclusive pela página de verificação operada pela Cloudflare, e revisem suas configurações DNS. Esse é o uso adequado da tabela: uma pista para o operador, não um parecer externo. Um provedor pode executar vários serviços recursivos, encaminhar parte do tráfego ou depender de chaves distribuídas por fornecedores. A tabela pública não resolve essas configurações.

O calendário tem três transições distintas

O calendário atual da IANA diz que a KSK-2024 entrou na zona raiz em 11 de janeiro de 2025. Esperava-se que resolvedores que seguem a RFC 5011 começassem a confiar nela um mês depois. Em 11 de outubro de 2026, a KSK-2024 deve começar a assinar a raiz e a KSK-2017 deve parar de assinar. A revogação da chave antiga está prevista para 11 de janeiro de 2027 e sua remoção para 22 de março.

Essas datas representam estados diferentes. “A nova chave assina” não significa “a antiga foi revogada”, e a revogação não quer dizer que ela já foi removida da zona. O período de espera da RFC 5011 dá tempo ao resolvedor para observar e validar a chave sucessora antes de aceitá-la automaticamente. Mas a existência do protocolo não comprova que uma implantação específica o habilitou, preservou estado gravável ou recebeu as observações necessárias.

As responsabilidades também são distintas. A IANA publica os arquivos de âncoras de confiança e o cronograma; a ICANN/PTI opera o processo da KSK raiz; a Verisign cuida, entre outras funções, da manutenção da zona raiz e de um ponto de observação nos servidores raiz; a APNIC publica suas análises. Cada operador de rede continua responsável pelos resolvedores recursivos usados por seus clientes. A APNIC pode fornecer evidências, mas não controla a chave raiz nem decide se a transição global continua.

Para o operador, a verificação imediata é local: confirmar que o resolvedor implantado confia na chave sucessora correta, testar se a atualização automática ou a via manual aprovada funciona e verificar os caminhos DNS usados em produção. A IANA publica os arquivos de âncoras; os fornecedores documentam seus próprios procedimentos. Uma medição pública pode sugerir onde olhar, mas não realiza esse teste pela organização.

As evidências disponíveis em 9 de outubro sustentam uma conclusão limitada. A chave sucessora está publicada há mais de um ano, uma grande parcela dos sinais e caminhos testados informa que ela foi carregada e a APNIC identificou redes onde uma verificação direcionada pode ajudar. As descrições de 90%, mais de 95% e 70% não formam uma única nota de prontidão. Em 11 de outubro, a pergunta operacional será se determinado caminho validador aceita a nova raiz assinada, e não qual percentual vira manchete.

Fontes

relatório de medição da APNIC de 9 de outubro; cronograma de âncoras e rollovers da IANA; RFC 8145; RFC 8509; RFC 5011; atualização da Verisign de 28 de julho; FAQ operacional da ICANN 2026; teste de resolvedor da Cloudflare.