Resumo

  • No retrato de 8 de setembro, entre 14h e 15h UTC, a APNIC informa 3.192.583 consultas WHOIS; os sete tipos visíveis somam 3.183.463. A diferença é de 9.120, enquanto o bloco RDAP do mesmo arquivo fecha exatamente.
  • O exame de 1.691 horas arquivadas encontrou divergência em todas as 1.690 horas que contêm tráfego WHOIS. O total é maior em 1.011 arquivos e menor em 679, portanto uma categoria residual não explica os dois sentidos.
  • Um material publicado para a APNIC 62 diz que a prop-167 ainda está em implementação e que problemas de exatidão estão sendo resolvidos. O documento não liga a frase a este cálculo. O controle adequado é uma conciliação horária com etapas, exclusões, validação e histórico de correções.

Há duas maneiras de ler um número público. A primeira é perguntar se ele parece plausível. A segunda é perguntar se os outros números que o acompanham conseguem reconstruí-lo. O arquivo horário da APNIC passa no primeiro teste: milhões de consultas WHOIS são compatíveis com um serviço regional intensamente automatizado. No segundo, a própria estrutura oferece respostas diferentes.

O arquivo atual congelado para esta análise cobre o intervalo entre 14h e 15h UTC de 8 de setembro de 2026. Em WHOIS, total_queries vale 3.192.583. O mapa de tipos mostra 1.670.618 para inetnum, 1.284.709 para route, 93.537 para aut-num, 88.530 para domain, 31.500 para organisation, 13.888 para as-set e 721 para inet6num. A adição chega a 3.183.463.

O intervalo entre as medidas é de 9.120, ou 0,2857% do total declarado. O MD5 oferecido pela APNIC é igual ao calculado sobre o JSON capturado. Isso elimina uma transferência defeituosa como explicação. O bloco RDAP, no mesmo documento, elimina outra desculpa: seus cinco tipos somam 588.346, exatamente o total exibido.

Não sabemos ainda o que representam as 9.120 unidades. Sabemos que o leitor não recebeu a equação necessária para interpretá-las.

A série inteira repete o desacordo

O arquivo mensal começa às 03h UTC de 30 de junho, data que a página da prop-167 registra como conclusão da implementação. A verificação enumerou cada hora até o arquivo encerrado às 14h UTC de 8 de setembro. Foram encontrados 1.691 arquivos, o mesmo número de intervalos esperados. A sequência de nomes é contínua. Todos os arquivos gzip foram abertos, todos os JSON foram interpretados, todas as janelas internas coincidem com os nomes e não houve repetição de conteúdo descompactado.

O teste não depende de modelo estatístico. Em cada serviço, somam-se os valores de query_type_distribution e subtrai-se a soma de total_queries. Em cada uma das linhas ASN apresentadas, somam-se os valores de query_count_by_type e comparam-se com query_count.

O resultado do RDAP é uma referência de qualidade dentro do próprio conjunto. As 1.691 horas fecham no nível do serviço. Nenhuma linha ASN visível apresenta diferença. A forma do documento comporta uma decomposição exata.

No WHOIS, existe uma única igualdade. Entre 09h e 10h UTC de 27 de agosto, o serviço registra zero consultas, zero ASN, nenhum tipo e nenhuma linha. É a única hora conciliada. Em cada uma das 1.690 horas com atividade, o total difere da soma dos tipos e pelo menos uma linha ASN também não fecha. Ao longo do período, 347.490 linhas apresentadas têm contagem diferente da soma de suas classes.

A primeira hora já mostra o problema: total de 4.774.145 e soma tipada de 4.801.599, uma diferença de −27.454. Na última hora arquivada, a relação é oposta: total de 2.989.539 e tipos somando 2.987.334, diferença de +2.205.

No conjunto, há 1.011 diferenças positivas e 679 negativas. O maior valor positivo ocorre em 20 de agosto, entre 03h e 04h UTC: 3.398.471 no total, 3.317.510 por tipos e +80.961, ou 2,3823%. O maior valor negativo aparece em 14 de julho, entre 05h e 06h: 3.288.941 no total, 3.652.538 por tipos e −363.597, ou −11,0551%.

O sinal é mais informativo do que a soma acumulada. Quando o total é maior, uma hipótese possível é a existência de consultas aceitas mas não classificadas. Uma categoria other poderia preencher o restante. Quando os tipos são maiores, esse restante precisaria ser negativo. A explicação então exige outra regra: múltiplos incrementos para uma consulta, relógios diferentes, repetição interna ou populações distintas. O arquivo não diz qual.

Também seria errado somar todas as diferenças positivas e negativas e chamar o saldo de consultas incorretas. Cancelar sinais não cria uma unidade. A constatação segura é que os campos não se conciliam segundo uma regra publicada.

Uma arquitetura legítima pode produzir a ambiguidade

O melhor argumento a favor da APNIC é operacional. Um contador pode ficar na borda e registrar comandos recebidos. Outro pode operar depois da análise sintática e contar objetos classificados. Um pedido pode acionar mais de um tipo. Uma etapa pode excluir comandos inválidos; outra pode registrar uma tentativa antes da exclusão. Eventos atrasados podem cair em fechamentos diferentes. A atribuição do ASN de origem pode falhar sem alterar a contagem de entrada.

Nenhuma dessas opções é absurda. Algumas podem ser necessárias para operar WHOIS em escala. O problema é que o README não escolhe entre elas. O documento descreve total_queries como total de consultas e query_type_distribution como mapa de tipo para contagem. Define a janela de uma hora e lista os campos por ASN. Não informa o ponto de medição, o tratamento de tentativas, a possibilidade de múltiplas classes, a categoria para falhas ou o horário de fechamento de cada etapa.

Por isso, a investigação não pode declarar qual número está correto. Talvez ambos estejam corretos para perguntas diferentes. Nesse caso, colocá-los como total e distribuição sem nomear as perguntas induz o usuário a fazer uma soma que o sistema não promete cumprir.

O checksum resolve outra camada. Ele prova que o arquivo recebido é o publicado. Não prova que a semântica de duas medidas é a mesma. Integridade de transporte, completude de classificação e coerência aritmética devem ser verificadas separadamente.

O vetor asns acrescenta um cuidado. Muitas horas declaram vários milhares de ASN distintos, mas a lista observada tem no máximo mil itens. É razoável supor uma classificação dos maiores emissores, porém o README não apresenta o limite nem o critério. A soma das linhas visíveis não deve ser tratada como o universo do serviço.

A implementação ganhou um segundo estado

Na página da prop-167, o estado atual continua sendo Implemented, com a entrada “Implementation Complete” em 30 de junho. Em contraste, uma apresentação publicada para a APNIC 62 chama a proposta de “In Implementation”. O slide lembra que os dados foram publicados inicialmente em 30 de junho, afirma que alguns problemas de exatidão estão em resolução e prevê conclusão até o fim do terceiro trimestre.

O material está associado no programa oficial à sessão de Policy SIG de 10 de setembro e foi capturado antes dessa data. Portanto, é um documento preparado e disponibilizado, não uma fala já realizada. Além disso, a frase sobre exatidão não identifica esta divergência. Seria um salto indevido afirmar que a APNIC reconheceu especificamente os dois totais.

A leitura útil é por camadas. A publicação do serviço pode ter sido concluída em junho. A verificação e a correção dos dados podem continuar. Uma única etiqueta de estado perde essa nuance. Disponibilidade, cobertura, coerência e correção merecem marcos próprios.

Esse enquadramento também impede uma conclusão desproporcional. Um arquivo reconciliado não provaria que todas as respostas WHOIS estão corretas. Um arquivo não reconciliado não prova que o serviço respondeu errado. O controle mede a consistência do artefato, não toda a realidade operacional.

Qual denominador entra na decisão

A abertura promovida pela prop-167 é valiosa. O conjunto permite acompanhar volume, classes de consulta, concentração por ASN e número de endereços de origem sem revelar esses endereços nem os recursos consultados. A preservação horária permite repetir análises e encontrar limites como este.

O risco surge no reuso. Uma participação calculada pela divisão de uma linha ASN por total_queries não é a mesma participação dividida pela soma dos tipos. Uma série de demanda montada com o total pode divergir de uma série reconstruída pelas categorias. Se a classificação muda de versão, o gráfico pode sugerir mudança de comportamento quando apenas a regra mudou.

A evidência não autoriza acusações. Ela não mostra perda, duplicação, abuso, quebra de privacidade ou impacto em rede. As linhas não tornam um ASN suspeito. A hora em zero não comprova indisponibilidade. O ponto é menor e mais rigoroso: um terceiro não consegue reconstituir o significado do denominador.

Conciliação sem expor usuários

Uma pequena prestação de contas horária seria suficiente. Ela começaria pelas solicitações aceitas na borda, seguiria para comandos interpretados e incrementos classificados, e terminaria com exclusões agregadas: formato inválido, tipo não suportado, expiração de tempo ou outra família. Se um comando incrementar mais de um tipo, a regra deve estar escrita. Se os estágios fecharem em momentos diferentes, os dois horários devem aparecer.

O segundo bloco registraria a transformação: identificador da execução, versão do coletor e do classificador, hora de conclusão e resultado da verificação aritmética. Falhas de enriquecimento por ASN podem continuar agregadas. O limite de mil linhas deve ser descrito como ranking, acompanhado do critério de seleção.

O terceiro bloco cuidaria da história. Cada arquivo teria estado provisório, validado, corrigido ou retirado e uma impressão digital. Um substituto apontaria para a impressão anterior, a data, a família do motivo e os campos afetados. A versão antiga continuaria disponível para reconstruir pesquisas já publicadas.

Esse desenho preserva a privacidade. Não exige IP, objeto consultado ou identidade do usuário. Exige apenas que o produtor mostre a passagem de um total a outro. A APNIC já oferece o arquivo, a frequência e a integridade. A conciliação transformaria disponibilidade em evidência comparável.

Fontes