Resumen

  • Los archivos estándar de delegaciones de AFRINIC con fechas del 10, 11 y 12 de septiembre de 2026 son idénticos byte por byte. Todos conservan el número interno y el cierre de periodo 20260910; los archivos ampliados muestran el mismo patrón.
  • La igualdad no demuestra una avería ni ausencia de nuevas asignaciones. Un registro de publicación podría separar una comprobación reciente sin cambios de la reutilización de una salida anterior, sin exponer expedientes de miembros.

Un sistema de recopilación puede trabajar tres noches seguidas y aun así obtener una sola versión de los datos. Eso es lo que muestra una comparación del archivo público de AFRINIC: los nombres del 10, 11 y 12 de septiembre devuelven los mismos 491.382 bytes y el mismo SHA-256, 54b0cfb6c962fe41815728ef9bff5950cece5fcdd7ab17b94cc3875e68378e07.

La captura, realizada el 14 de septiembre según el calendario Asia/Shanghai, encuentra en los tres encabezados el número 20260910, 9.947 registros declarados y un periodo que termina el 10 de septiembre. El hecho observable es la identidad de contenido bajo nombres distintos. El motivo de esa identidad no aparece en los archivos.

Cada fecha tiene su función

La norma RIR Statistics Exchange Format publicada por AFRINIC exige producción diaria. Define la fecha de delegated-<registry>-yyyymmdd como el día local en que el RIR produjo el archivo. Define por separado serial como el número del archivo dentro de la serie del registro. El final del periodo constituye otro campo. El alias latest debe apuntar al archivo más reciente cuando se actualiza.

El servidor aporta una cuarta referencia temporal. En el índice de 2026, el archivo llamado 10 de septiembre tiene modificación del día 11; el del 11, del 12; el del 12, del 13. Las respuestas HTTP también ofrecen metadatos diferentes. Esos tiempos describen los objetos servidos, no certifican la ejecución del generador ni el límite de las fuentes examinadas.

El directorio raíz añade un nombre del 13 de septiembre con modificación del día 10. Su contenido coincide con los tres archivos anteriores y con el alias estándar actual. En esta muestra, nombre reciente, modificación reciente y versión interna reciente no son propiedades que avancen juntas.

Una comprobación de integridad no acredita frescura

La coincidencia incluye los archivos ampliados de los días 10, 11 y 12 y su alias actual: 992.722 bytes por archivo, SHA-256 66f1d06b8f272cbb3f2da3260b73a63cb7b1cd132ad770851dc2e2864ac9eb75, número y cierre 20260910, y 19.651 registros declarados. El formato ampliado añade estados y datos sobre titulares; no añade la explicación del episodio de publicación.

Los tres archivos MD5 también son idénticos. El cálculo independiente sobre el contenido estándar coincide con su valor publicado, 568a689f01216f94af0b174514fd3903. Los tres objetos de firma OpenPGP separada contienen los mismos bytes. Aquí no se afirma que las firmas hayan sido verificadas localmente.

Son controles valiosos pero limitados. La coincidencia del checksum respalda la integridad del contenido respecto del valor anunciado. Incluso una firma verificada matemáticamente vincularía los bytes con una clave, no con una nueva revisión diaria. Autenticidad del contenido y actualidad de la observación son preguntas diferentes.

El archivo del 9 de septiembre ayuda a no confundir otra métrica: conserva tamaño y número declarado de registros, pero tiene un digest distinto y número interno del día 9. Un total estable puede ocultar cambios de filas. Solo la igualdad del archivo completo acredita que el contenido capturado es el mismo.

«Sin cambios» requiere un corte de observación

Puede ser perfectamente normal que un registro no tenga novedades que publicar. También puede ser razonable volver a distribuir una salida validada. La cuestión no es censurar la repetición, sino saber qué proceso la respalda: ¿se revisó el estado hasta un nuevo corte y se concluyó que no había cambios, o se entregó de nuevo la salida anterior?

Los objetos públicos no ofrecen identificador de ejecución, corte de fuente, clase de reutilización ni estado de corrección. No permiten distinguir entre esas situaciones y un generador detenido o una fuente retrasada. Tampoco permiten afirmar que faltan asignaciones, que la base de datos está equivocada o que hubo daño operativo.

Un recopilador que usa solo la URL como clave puede contar tres observaciones independientes de un único conjunto de datos. Otro que deduplica solo por número interno puede perder la historia de las nuevas rutas de publicación. La solución es conservar las dos identidades: versión de contenido y evento de publicación.

Los consumidores ya pueden guardar URL solicitada, hora de captura, metadatos devueltos, número, fin de periodo y digest. AFRINIC podría aportar un registro compacto que los enlace con hora de publicación, corte realmente comprobado, resultado de validación y motivo general de la salida idéntica. No hace falta publicar solicitudes, tickets ni expedientes privados.

Alcance de la evidencia y fuentes

Este artículo compara archivos públicos congelados, no registros de operación internos. La evidencia demuestra igualdad de los objetos descargados y documenta definiciones y metadatos. No demuestra avería, asignaciones ocultas, falsificación, fechas manipuladas, error registral ni consecuencias sobre rutas o RPKI. Si aparece una corrección posterior, su relación con el objeto anterior debe poder reconstruirse.