A AFRINIC chama seu painel NS2 de “tempo real”. As 12 medições vinculadas são testes pontuais encerrados

Resumo

• A configuração pública do painel NS2 da AFRINIC reúne dezessete localidades. Seis têm pares completos de medições “antes” e “depois”; onze não têm nenhum dos dois identificadores e aparecem como pendentes na lógica da interface.
• As doze medições DNS vinculadas são execuções pontuais do RIPE Atlas e todas estão com status Stopped. Elas podem documentar comparações limitadas de implantação, mas não formam uma série contínua de saúde operacional.

Uma resposta recente do servidor pode conter um dado antigo

O termo que merece auditoria no painel de medições NS2 não é anycast, e sim “real-time”. O título vem acompanhado de latência média, contraste entre antes e depois, mapas de sondas e um horário de atualização. Esse arranjo comunica atualidade: sugere ao visitante que a rede acabou de ser observada e que os números mudariam se o serviço mudasse.

O mecanismo por trás da tela faz algo mais estreito. O JavaScript do aplicativo lê os IDs guardados no arquivo público de configuração dos nós e busca, para cada medição, o caminho /measurements/{id}/latest/. A chamada devolve o último resultado disponível daquele ID. Ela não certifica que a medição esteja em execução, que o resultado tenha sido produzido recentemente ou que a localidade continue coberta.

Essa distinção costuma desaparecer porque “último” e “atual” cabem no mesmo cartão. Mas são propriedades diferentes. O último extrato de uma conta pode ser perfeitamente autêntico e ainda assim não informar o saldo de hoje. Da mesma forma, o último pacote de uma campanha de medição encerrada é evidência histórica, não telemetria contínua. Data de coleta, duração e estado do experimento precisam viajar junto com o número.

A documentação da API de medições do RIPE Atlas permite conferir esse ciclo de vida. Nos doze registros que o painel usa, is_oneoff é verdadeiro e o status é Stopped. As janelas observadas vão de 8 de dezembro de 2025 a 16 de fevereiro de 2026; na maioria dos casos, duram por volta de cinco minutos. Isso descreve uma família de fotografias controladas, não uma câmera ligada permanentemente.

Uma fotografia pode responder bem à pergunta “o que mudou logo após a implantação?”. Para isso, é preciso garantir que alvos, sondas e condições dos dois lados sejam comparáveis. Ela não responde, sem uma nova coleta, “como o nó está hoje?”. A tela mistura essas perguntas ao manter o vocabulário do presente em torno de execuções encerradas.

Três inventários, três denominadores

O arquivo que alimenta o painel lista dezessete localidades. Angola, Benim, Botsuana, Quênia, Zimbábue e Maurício possuem um ID para “before” e outro para “after”. Burkina Faso, Cabo Verde, Camarões, Egito, Gabão, Gâmbia, Gana, Marrocos, Nigéria, Sudão e Tunísia não possuem nenhum dos dois. Para a interface, estas onze entradas estão pendentes.

Não há caso intermediário: nenhuma localidade tem apenas metade do par. A contabilidade verificável é, portanto, seis comparações completas, onze sem medição publicada e zero pares parciais. As doze medições correspondem a duas execuções para cada uma das seis localidades, e não a doze localidades monitoradas.

O mapa de infraestrutura DNS apresenta outro conjunto. Ele carrega vinte linhas de anfitriões CIP e vinte linhas de anfitriões NS2, totalizando quarenta registros de hospedagem. Nada obriga esse inventário a ter a mesma cardinalidade da configuração experimental. Um host no mapa pode não ter uma comparação vinculada; uma localidade de experimento pode representar um recorte que não coincide com a nomenclatura do inventário.

O script público do mapa confirma que esses dois inventários alimentam a visualização.

É possível, assim, dizer três coisas verdadeiras e incompatíveis se elas forem colocadas na mesma frase: há vinte linhas NS2 no mapa, dezessete localidades no painel e seis localidades com comparações. O problema nasce quando o leitor recebe apenas “nós” como unidade. Um registro de presença, um par de testes e uma observação atual são evidências de naturezas diferentes.

Essa separação é especialmente importante para um programa regional. Contar implantação recompensa alcance. Contar pares experimentais recompensa avaliação. Contar locais sob monitoramento recorrente recompensa capacidade operacional. Misturar os denominadores permite que o crescimento de uma lista pareça melhora de cobertura em outra, mesmo sem intenção de exagerar.

O que as doze medições autorizam afirmar

As páginas públicas do RIPE Atlas mostram de forma direta o estado de cada ID usado pela AFRINIC:

Localidade	Antes	Depois	Situação registrada
Angola	154055021	154055966	Duas medições pontuais encerradas
Benim	142730550	142730838	Duas medições pontuais encerradas
Botsuana	155156750	155156902	Duas medições pontuais encerradas
Quênia	143072543	147523251	Duas medições pontuais encerradas
Zimbábue	142775401	142775907	Duas medições pontuais; metadados pedem ressalva
Maurício	142741062	142740732	Duas medições pontuais; rótulos parecem invertidos

O estado encerrado não apaga os resultados. Apenas fixa seu lugar no tempo. Uma análise responsável ainda poderia comparar distribuições de latência, respostas DNS e seleção de instância, desde que declarasse o desenho do experimento. O painel, no entanto, não coloca na frente do leitor as datas nem o fato de que se trata de execuções únicas.

Dois pares também mostram por que o ID não deve ser tratado como um selo autossuficiente. No caso do Zimbábue, a medição 142775401, configurada como “antes”, traz uma descrição terminada em “After”. A suposta parceira posterior, 142775907, usa uma descrição genérica sobre o Zimbábue e aponta para ASN e endereço IP diferentes. Isso não prova que o teste esteja errado. Indica que houve uma mudança ou uma atribuição que precisa de explicação antes de se comparar os números.

No caso de Maurício, a assimetria parece um cruzamento: 142741062 ocupa o campo “antes” no arquivo da AFRINIC, mas a descrição da medição diz “After”; 142740732 ocupa o campo “depois”, mas a descrição diz “before”. Sem um registro de correção, um observador externo não tem base para escolher qual ordem representa a intenção operacional. A atitude adequada é preservar a dúvida, não resolvê-la por adivinhação.

Há uma lição maior nesses dois casos. Metadados de uma medição incluem tanto propriedades técnicas quanto decisões editoriais: nome, alvo, fase, grupo de sondas e vínculo com uma localidade. Se esses elementos são copiados manualmente para uma interface, o painel deve registrar a origem e a revisão. Caso contrário, uma correção silenciosa pode melhorar a tela atual e destruir a capacidade de auditar relatórios antigos.

Anycast torna a procedência mais necessária

A iniciativa DNS da AFRINIC busca fortalecer resiliência e desempenho ao apoiar infraestrutura distribuída no continente. A organização também descreve um programa de cópias de servidores raiz. Implantar uma instância mais perto dos usuários pode reduzir caminhos, manter consultas na região e ampliar diversidade. Mas “mais perto” não é apenas uma coordenada: depende de anúncios BGP, políticas de roteamento, peering e seleção de melhor caminho.

A RFC 4786 explica que anycast anuncia o mesmo endereço a partir de múltiplos pontos. Uma sonda não mede uma etiqueta no mapa; ela mede a instância para a qual o roteamento a levou naquele momento. Se o anúncio ou a topologia mudar, a mesma sonda pode alcançar outro lugar. Logo, uma comparação curta precisa conservar o alvo efetivo e o contexto de rota para continuar interpretável.

A RFC 6304, ao tratar de instâncias locais do sistema de servidores raiz, reforça que implantação e benefício observado não são sinônimos. Uma cópia pode estar fisicamente presente sem ser alcançada por uma determinada população; pode servir uma região maior ou menor que a fronteira do país; pode oferecer resiliência mesmo sem produzir uma queda dramática de latência. O painel deveria permitir essas nuances, não achatá-las em um único marcador verde.

Também há limites firmes para esta apuração. O status Stopped das medições não demonstra indisponibilidade do NS2, falha de DNS, retirada de rota, problema de ccTLD ou degradação de uma instância. Não foram conduzidas aqui consultas ativas, verificação BGP atual nem entrevistas com os anfitriões. O achado é sobre o material probatório publicado e sobre a promessa semântica da interface.

Um painel deve escolher entre arquivo e sensor — ou identificar ambos

O site atual reúne três camadas. O mapa é um inventário de implantação. Os pares antes/depois são um arquivo de avaliação. O título de “tempo real” promete um sensor de saúde. Nenhuma dessas camadas é inferior às demais, mas cada uma exige campos diferentes.

No inventário, o essencial é saber quem hospeda, qual serviço está presente, desde quando e quando o registro foi confirmado. Na avaliação, importam intervenção, alvo, grupo de sondas, janelas e método de comparação. No monitoramento, importam recorrência, atraso, perda, janela de frescor e tratamento de lacunas. Usar o resultado mais recente de uma medição única preserva apenas uma fração da segunda camada e não cria a terceira.

Uma correção de curto prazo poderia renomear a página para “comparações históricas de implantação do NS2”. Cada cartão mostraria início, fim, condição pontual e status. As onze localidades sem IDs receberiam o texto “comparação ainda não publicada”. Se houver de fato uma fonte de saúde contínua, ela poderia ganhar uma área separada e um indicador que se torna explicitamente obsoleto quando a idade ultrapassa o limite.

O passo durável seria anexar a cada nó um recibo de observação. O recibo teria dados suficientes para provar qual pergunta o gráfico responde e manteria a história das correções. Dessa forma, o programa poderia crescer sem transformar automaticamente presença em desempenho, nem desempenho em disponibilidade.