APNIC repone 92 informes WHOIS/RDAP sin registro de reparación

Resumen

El archivo de octubre de APNIC ya muestra los 92 informes WHOIS/RDAP de las horas entre el 23 de octubre a las 04:00 UTC y el 27 a las 00:00 UTC. Informes y archivos MD5 asociados llevan la misma hora de modificación: 29 de octubre, 10:16 en el listado UTC+10.
El aviso del 16 de octubre aún no tiene hora de fin ni duración. Una suma MD5 verifica los bytes descargados; el esquema publicado por APNIC no indica si los registros de origen de cada hora estaban completos.

Noventa y dos horas, una sola pasada

La recuperación se ve en las filas del directorio, no en una nueva explicación de la avería: hay 92 informes más y todos llevan una marca de actualización común. El 27 de octubre, el archivo saltaba del día 23 al 27. El tramo comienza el 23 de octubre a las 04:00 UTC y termina el 27 a las 00:00: cuatro días, 92 intervalos consecutivos de una hora.

El directorio marca su regreso con una precisión poco habitual. Cada informe previsto y cada archivo .md5 asociado figura como modificado el 29 de octubre a las 10:16, la hora UTC+10 del servidor. Las cabeceras HTTP del primer y el último informe marcan las 00:16:28 UTC. Descargué ambas versiones comprimidas, comprobé los intervalos que declaran y comparé el MD5 de cada archivo con el archivo de verificación MD5 de APNIC. El primero cubre del 23 de octubre, 04:00–05:00 UTC; el último, del 26, 23:00 al 27, 00:00 UTC.

El flujo actual siguió avanzando. El JSON WHOIS/RDAP más reciente cubre del 30 de octubre, 23:00, al 31, 00:00 UTC; su MD5 coincide con los bytes descargados. En el nivel del archivo, las horas perdidas regresaron y la publicación horaria está al día.

El parte de la incidencia no avanzó con ellas. El aviso de APNIC del 16 de octubre atribuye la falta de integridad a problemas al procesar registros desde las 10:00 UTC+10. Dice que desactivó la generación y que volvería a publicar los archivos afectados al resolver el problema. Los campos de hora de fin y duración siguen vacíos. El índice de actualizaciones conserva el aviso, pero no incluye un cierre para esta incidencia de WHOIS/RDAP.

Que el directorio esté completo no resuelve la calidad de los datos. El README de APNIC enumera los campos de cada informe horario: intervalo, total de consultas, distribución por tipo, cantidad de ASN y métricas por ASN. No define un identificador de revisión, un estado de integridad por hora ni un manifiesto de recuperación. Los valores MD5 demuestran que los dos archivos muestreados coinciden con sus archivos de verificación MD5. No dicen qué registros alimentaron el cálculo ni si todos los intervalos afectados están completos.

La diferencia pesa cuando alguien construye una serie temporal. Una hora restaurada puede terminar en un gráfico, una línea de referencia o una investigación. Sin estado de reparación, el usuario no puede marcarla como reconstruida, validada o meramente disponible. Los 92 archivos volvieron; los documentos públicos revisados no cierran el período más amplio que APNIC declaró afectado desde el 16 de octubre.

El archivo necesita un recibo de reparación

APNIC podría cerrar el asunto con un manifiesto por intervalo: la hora UTC afectada, el estado de recuperación, el identificador del proceso, la suma MD5 vigente y la hora de cierre de la incidencia. Si una estadística continúa incompleta, basta con decirlo para esa hora. Así los usuarios distinguirían entre archivos repuestos y datos cuya integridad sí se confirmó, y podrían repetir los cálculos después.

La marca temporal del directorio fija cuándo volvieron los archivos. Un registro de reparación debe identificar el proceso y el estado de cada intervalo. APNIC devolvió las horas ausentes; ahora falta documentar cómo se reconstruyeron esos informes.