APNIC repõe 92 relatórios WHOIS/RDAP sem registro de correção

Resumo

O arquivo de outubro da APNIC já lista os 92 relatórios WHOIS/RDAP referentes às horas de 23 de outubro, 04:00 UTC, a 27 de outubro, 00:00 UTC. Relatórios e arquivos MD5 aparecem com a mesma atualização: 29 de outubro, às 10:16 no horário UTC+10 do diretório.
O aviso de 16 de outubro segue sem horário de término ou duração. A soma MD5 confere os bytes baixados; o esquema publicado pela APNIC não informa se os registros de origem de cada hora estavam completos.

Uma leva devolveu quatro dias ao arquivo

A lista mensal registra a mudança em bloco: 92 relatórios e seus arquivos de verificação aparecem com atualização de 29 de outubro às 10:16, no horário UTC+10. Quatro dias antes, o salto entre 23 e 27 deixava essas horas de fora. O intervalo começa em 23 de outubro às 04:00 UTC e termina em 27 de outubro à 00:00: quatro dias, 92 períodos horários seguidos.

O diretório deixa uma pista clara sobre a reposição. Cada relatório esperado e cada arquivo .md5 correspondente consta como atualizado em 29 de outubro às 10:16, horário UTC+10 da listagem. Nos cabeçalhos HTTP dos relatórios que abrem e fecham o período, a hora é 00:16:28 UTC. Baixei os dois arquivos compactados, conferi os intervalos declarados e comparei o MD5 dos bytes com o arquivo de verificação da APNIC. O primeiro cobre 23 de outubro, 04:00–05:00 UTC; o último, 26 de outubro, 23:00 até 27 de outubro, 00:00 UTC.

O fluxo atual também avançou. O JSON mais recente de WHOIS e RDAP cobre 30 de outubro, 23:00, a 31 de outubro, 00:00 UTC; seu MD5 confere com o arquivo baixado. No nível do arquivo, as horas ausentes voltaram e a publicação horária está em dia.

O registro do incidente ficou para trás. No aviso de 16 de outubro, a APNIC atribuiu estatísticas incompletas, desde 10:00 em UTC+10, a problemas no processamento dos registros. Disse que a geração fora desativada e que republicaria os arquivos afetados depois de resolver o problema. Os campos de término e duração seguem vazios. O índice de atualizações ainda lista o aviso, sem uma nota separada de encerramento para essa falha nas estatísticas WHOIS/RDAP.

Arquivo preenchido não é o mesmo que integridade dos dados confirmada. O README da APNIC define os campos do relatório horário: intervalo, total de consultas, distribuição por tipo, número de ASNs e números por ASN. Não prevê identificador de revisão, estado de integridade por hora ou manifesto de recuperação. Os valores MD5 dos dois arquivos verificados mostram que os downloads correspondem aos arquivos de verificação publicados. Não revelam quais registros alimentaram os relatórios nem provam que todas as horas afetadas foram reconstruídas por completo.

Isso pesa para quem monta uma série temporal. A hora que reapareceu pode entrar em gráfico, referência ou pesquisa; sem um estado de reparo, o usuário não sabe se ela foi reconstruída, validada ou simplesmente recolocada no diretório. Os 92 arquivos voltaram. Os registros públicos consultados não encerram o período mais amplo que a APNIC disse estar afetado a partir de 16 de outubro.

Falta um recibo para fechar a conta

A APNIC poderia publicar um manifesto por intervalo: hora UTC, estado da recuperação, ID do processamento, soma MD5 atual e horário de encerramento do incidente. Se uma estatística continuar incompleta, a linha correspondente deve dizer isso. Assim, quem usa os dados separa arquivos repostos de estatísticas cuja integridade foi confirmada e consegue refazer a mesma série mais tarde.

O horário no diretório é uma evidência útil. Não é um histórico de reparo. A APNIC devolveu as horas que faltavam ao arquivo; agora precisa registrar o que aconteceu com os dados dentro delas.