Resumen

  • En la instantánea capturada para el 8 de septiembre, de 14:00 a 15:00 UTC, APNIC declara 3.192.583 consultas WHOIS; las siete clases visibles suman 3.183.463. La diferencia es de 9.120, mientras que RDAP cuadra al céntimo estadístico.
  • El examen de las 1.691 horas disponibles halló que las 1.690 con actividad WHOIS presentan una diferencia. En 1.011 archivos el total es mayor que el desglose y en 679 ocurre lo contrario, por lo que una categoría residual omitida no basta como explicación.
  • Un documento publicado para APNIC 62 reconoce problemas de exactitud aún en resolución, pero no identifica esta aritmética. La respuesta prudente es una hoja de conciliación por hora con etapas, exclusiones, reglas de clasificación y versiones corregidas.

La transparencia puede crear una obligación que no existía mientras el dato permanecía invisible: permitir que terceros comprueben si las piezas encajan. APNIC hizo públicos sus recuentos horarios de uso de WHOIS y RDAP como parte de prop-167. La decisión convirtió una actividad operativa antes opaca en archivos descargables, preservados y acompañados por sumas de control. También dejó a la vista una pregunta elemental.

La instantánea más reciente congelada para este análisis cubre el 8 de septiembre de 2026 entre las 14:00 y las 15:00 UTC. En WHOIS, total_queries es 3.192.583. El mismo objeto contiene siete recuentos: 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 y 721 para inet6num. Su suma es 3.183.463.

Faltan 9.120 unidades para llegar al total, un 0,2857 %. No se trata de bytes dañados en la descarga: el MD5 publicado coincide con el archivo. Tampoco es una propiedad inevitable del formato. En la sección RDAP de ese mismo documento, las cinco categorías suman exactamente 588.346, el valor de su total.

La diferencia puede parecer menor que el ruido de un servicio con millones de consultas. La serie histórica muestra que su importancia no reside en el tamaño de una hora, sino en la ausencia de una relación estable entre los campos.

El archivo completo funciona como prueba de control

El recorrido comenzó en el primer fichero disponible, el 30 de junio a las 03:00 UTC, y terminó en el fichero archivado del 8 de septiembre a las 13:00 UTC. Los índices mensuales contienen 1.691 horas, exactamente las esperadas para ese intervalo. No hay huecos en los nombres. Los 1.691 gzip se descomprimen, los JSON se analizan, las fechas internas corresponden al nombre y no aparece ningún contenido duplicado.

El cálculo aplicado a cada bloque fue idéntico. Primero se sumaron todos los valores de query_type_distribution; después se restó esa suma de total_queries. En las filas ASN se comparó query_count con la suma de query_count_by_type. No se estimaron consultas ni se infirió tráfico que el archivo no publicara.

El resultado de RDAP es limpio: 1.691 horas, 1.691 conciliaciones exactas y ninguna fila ASN visible con diferencia interna. Ese servicio demuestra que APNIC puede publicar un total y un desglose que obedecen a la misma identidad aritmética.

WHOIS coincide una sola vez. Fue el 27 de agosto entre las 09:00 y las 10:00 UTC, cuando muestra cero consultas, cero ASN, una distribución vacía y ninguna fila. Por tanto, todas las 1.690 horas con tráfico WHOIS tienen un total general distinto de la suma por tipo. En esas mismas horas hay filas ASN que repiten la discrepancia; el conteo acumulado es de 347.490 filas visibles no conciliadas.

El patrón nació con la publicación. En la primera hora, WHOIS marca 4.774.145 consultas, mientras que las clases suman 4.801.599: 27.454 más. En la última hora archivada del control, el total es 2.989.539 y las clases 2.987.334: 2.205 menos.

La dirección cambia de manera sistemática. Hay 1.011 horas en las que total_queries supera la suma. Allí podría existir una cola de comandos no clasificados, rechazos u otro resto no mostrado. Hay 679 horas en las que el desglose supera el total. El caso extremo ocurre el 14 de julio de 05:00 a 06:00 UTC: 3.288.941 como total frente a 3.652.538 al sumar tipos. La diferencia es −363.597, equivalente a −11,0551 % del total. El mayor salto positivo aparece el 20 de agosto de 03:00 a 04:00: +80.961, un 2,3823 %.

Esta inversión invalida el arreglo más cómodo. Añadir una categoría other de 9.120 a la hora reciente cerraría una brecha positiva. No puede cerrar una hora donde las categorías ya exceden el total, salvo que se publique además una regla de doble clasificación o una frontera temporal distinta. La aritmética no identifica la causa; sí obliga a que la causa tenga más de una dimensión.

Es posible que ambos contadores sean correctos

Un sistema operativo no tiene por qué producir un solo concepto de «consulta». Un contador situado en la entrada puede registrar cada comando aceptado. Otro, detrás del analizador, puede incrementar una o varias clases de objeto. Un enriquecimiento por ASN puede cerrarse más tarde. Reintentos internos, comandos mal formados, respuestas en caché, eventos tardíos o marcas de tiempo diferentes pueden separar los resultados sin que ninguno esté mal construido.

Esa es la mejor defensa del conjunto. Pero no está descrita en el contrato público. El README dice que cada servicio contiene un intervalo, un total, un número de ASN, una distribución por tipo y una lista por ASN. Define una ventana UTC semiabierta y la forma del archivo. No explica dónde se cuenta cada métrica, si una consulta pertenece a varias clases, qué se excluye, cómo se tratan los retrasos o qué representa una diferencia.

La palabra «total» adquiere entonces una autoridad que la documentación no sostiene. El lector puede interpretar la distribución como una partición del total, porque así se presentan habitualmente ambos campos. Si en realidad son medidas de etapas diferentes, los nombres deben decirlo. «Solicitudes aceptadas» e «incrementos clasificados» podrían ser dos métricas útiles, siempre que no se ofrezca la segunda como desglose natural de la primera.

La integridad del archivo tampoco reemplaza la definición. Un MD5 idéntico confirma que APNIC y el lector comparten los mismos bytes. No confirma que dos columnas dentro de esos bytes compartan población, unidad o momento de cierre.

Existe además un límite silencioso en las filas ASN. Los bloques declaran con frecuencia varios miles de ASN de origen, pero la matriz asns observada contiene como máximo mil elementos. Eso parece una lista de principales orígenes, no el universo. El README no la etiqueta como truncada ni publica el criterio de corte. Incluso con filas internamente correctas, su suma no debería usarse como sustituto del total del servicio.

«Implementado» y «en implementación» pueden describir capas distintas

La página de prop-167 conserva el estado Implemented y una línea histórica fechada el 30 de junio: «Implementation Complete». Sin embargo, APNIC ha publicado antes de APNIC 62 una presentación para la sesión de Policy SIG prevista el 10 de septiembre. En ella, prop-167 figura como «In Implementation». El texto dice que se publicó inicialmente el 30 de junio, que algunos problemas de exactitud se están resolviendo y que se espera completar el trabajo antes de que termine el tercer trimestre.

Dos límites son esenciales. La presentación estaba disponible antes del horario de la sesión; no debe convertirse en una cita oral que todavía no había ocurrido. Tampoco nombra la diferencia entre total_queries y la distribución. No sabemos si APNIC se refiere a este hallazgo, a otro problema o a varios.

El documento sí aporta una corrección conceptual. La publicación inicial y la garantía de calidad no son el mismo hito. El archivo puede estar disponible y la política, implementada como servicio; la validación de sus datos puede seguir abierta. Mantener dos estados por capa sería más exacto que obligar a escoger una única palabra para toda la iniciativa.

La reutilización transforma una diferencia pequeña en una decisión

Los datos de prop-167 tienen ventajas importantes. Permiten estudiar volumen, mezcla de objetos, concentración por ASN y diversidad de fuentes sin divulgar direcciones IP ni recursos consultados. La preservación horaria facilita comparaciones y hace posible esta misma auditoría. La conclusión no debería ser cerrar el flujo, sino hacerlo interpretable.

Un investigador que divide la fila de un ASN por total_queries obtiene una participación. Si usa la suma de clases, obtiene otra. Una gráfica de volumen puede seguir el total declarado o reconstruirse por categorías. Cuando la brecha cambia de signo, las dos series no solo difieren de nivel: pueden cambiar de dirección. Una modificación del clasificador puede parecer un cambio de comportamiento de usuarios.

No existe prueba aquí de consultas perdidas o duplicadas. No se ha observado una respuesta WHOIS incorrecta, una violación de privacidad, un ataque ni un daño a la red. Las diferencias de fila no convierten a ningún ASN en responsable. La hora con cero no prueba una caída sin un parte independiente. El problema está en el uso probatorio del dato, no en una sentencia sobre el servicio.

Una conciliación que no necesita datos personales

Cada hora debería publicar primero su ecuación. Puede distinguir solicitudes aceptadas en la frontera, comandos analizados, incrementos asignados a tipos y cantidades excluidas por familias amplias: sintaxis inválida, tipo no compatible, tiempo agotado u otra razón. Si una solicitud suma en más de una clase, la multiplicidad debe constar. Si cada etapa cierra en un momento distinto, deben aparecer ambos cortes.

Después hace falta identidad técnica: versión del recolector y del clasificador, identificador de ejecución, hora de finalización y resultado de una comprobación automática. Los fallos de atribución ASN pueden expresarse como agregados. La matriz de mil filas debe declarar que es un ranking y explicar su selección.

Por último, la corrección debe conservar historia. Una publicación puede ser provisional, validada, corregida o retirada. Su huella debe acompañarla. El reemplazo debe citar la huella anterior, la fecha, la categoría del motivo y los campos afectados. La versión vieja debe seguir localizable para que una afirmación previa pueda reconstruirse.

Nada de eso revela quién consultó qué. Es una contabilidad de transformaciones, no de usuarios. El archivo de APNIC ya aporta frecuencia, acceso, continuidad y sumas de control. Una hoja de conciliación completaría el camino entre un número visible y una evidencia reutilizable.

Fuentes