Resumen

  • El JavaScript público de AIRRS añade amp;profile=afrinic a la consulta con la que pide a RIPEstat la estructura de la página. Dentro de una cadena JavaScript, esa escritura no se decodifica como HTML: crea una clave llamada amp;profile, no profile.
  • El 11 de septiembre de 2026, una consulta predeterminada y otra con la clave literal devolvieron la misma estructura normalizada de siete pestañas para AS327800, 196.192.48.0/20, afrinic.net y ZA.
  • En los cuatro casos, la consulta correctamente nombrada profile=afrinic devolvió HTTP 500, estado de error, objeto de datos vacío y cero pestañas.
  • La evidencia no desacredita los datos de los widgets. Demuestra que una página poblada no certifica el perfil que la organizó; hace falta un recibo que declare solicitud, selección, huella, versión, estado y repliegue.

Una respuesta visible puede ocultar la pregunta omitida

Las interfaces enseñan a confiar en el resultado, no en la negociación que lo produjo. Si aparecen tablas y gráficos, el usuario da por hecho que la aplicación entendió la solicitud. Ese atajo suele ser razonable. Deja de serlo cuando el sistema dispone de una configuración predeterminada capaz de producir una página completa aunque ignore la selección pretendida.

AIRRS —African Internet Registry and Routing Statistics— ofrece un caso preciso. Su propia presentación lo define como una colaboración entre AFRINIC y RIPE NCC para mostrar de forma accesible datos suministrados por RIPEstat. Aspira a entregar información actualizada sobre recursos de Internet o países para que operadores, reguladores, investigadores y responsables de políticas adopten decisiones informadas.

El anuncio archivado de AFRINIC identifica las fuentes que se acercan al usuario a través del portal: WHOIS, RIPE RIS, RIPE Atlas y conjuntos externos, entre otros. También dice que AIRRS está impulsado por la API de RIPE Stat. En la portada aparecen cuatro formas de consulta: ASN, prefijo, dominio e informe de país.

Así, AIRRS no es la base de datos original. Es una capa de selección y presentación. Para cada recurso pide a RIPEstat una estructura de resultados; esa estructura enumera pestañas y widgets. Después los widgets obtienen y muestran sus datos. Conviene separar esas dos operaciones. Un widget puede funcionar y una estructura puede parecer pertinente aunque la selección regional que supuestamente debía ordenar la página no se haya aplicado.

El nombre que sale por el cable

El archivo que construye los resultados se identifica como una plantilla AFRINIC para RIPEstat, fechada en febrero de 2020. La respuesta HTTP capturada indica que el JavaScript fue modificado por última vez el 11 de marzo de 2020 a las 10:00:24 UTC. Al recibir el recurso, el código forma una URL para results-page-structure y añade literalmente:

&profile=afrinic

En un fragmento HTML, & representa el carácter ampersand. Sin embargo, la línea se encuentra dentro de una cadena JavaScript que se utiliza como URL. El navegador ya tiene un ampersand real al principio; los caracteres siguientes forman el nombre de la clave. La consulta lleva por tanto amp;profile=afrinic. No lleva una clave profile con valor afrinic.

Muchas API toleran parámetros desconocidos. Los descartan y responden según su comportamiento predeterminado. Para el usuario, esa tolerancia parece resiliencia: llega JSON válido, AIRRS crea pestañas y precarga widgets. Para una auditoría de configuración, es una trampa: el éxito de transporte prueba que hubo una respuesta, no que el servidor reconociera la selección.

La manera más limpia de comprobarlo es comparar tres variantes. La primera no añade ningún perfil. La segunda reproduce exactamente la clave literal de AIRRS. La tercera utiliza el nombre correcto, profile=afrinic. El experimento se hizo con las cuatro formas que promociona el portal: el ASN AS327800, el prefijo 196.192.48.0/20, el dominio afrinic.net y el país ZA.

Una matriz sin zonas grises

Con AS327800, la consulta predeterminada devolvió HTTP 200, status: ok y siete pestañas. La consulta con amp;profile=afrinic también devolvió 200, estado correcto y siete pestañas. Al normalizar el objeto de datos, eliminando los campos volátiles de la envoltura, las dos respuestas compartieron exactamente la misma huella SHA-256. La consulta con profile=afrinic devolvió HTTP 500, status: error, status_code: 500, un objeto vacío y ninguna pestaña.

El prefijo 196.192.48.0/20 produjo la misma división. El valor predeterminado funcionó; la clave literal funcionó con una estructura normalizada idéntica; la clave correcta falló.

El dominio afrinic.net y el código de país ZA repitieron el patrón. La suma es sencilla: cuatro respuestas 200 por el camino predeterminado; cuatro respuestas 200 para la forma que AIRRS envía, todas idénticas a su predeterminado correspondiente en los datos normalizados; y cuatro respuestas 500 para la selección explícita del perfil AFRINIC.

Las doce respuestas registraron la compilación de RIPEstat v0.11.15-2026.09.09 y el canal de procesamiento 1415073. Se conservaron los identificadores de consulta, las horas, las huellas completas y normalizadas y los recuentos de pestañas. Es un corte temporal verificable del 11 de septiembre de 2026, no una afirmación basada únicamente en el aspecto de la pantalla.

En las respuestas fallidas aparece data_call_status: supported. No debe leerse aislado. La documentación de RIPEstat distingue data_call_status, status y status_code. Que una llamada sea de un tipo admitido no significa que su ejecución concreta haya terminado bien. HTTP 500 y status: error siguen describiendo un error.

La matriz sostiene una conclusión acotada. Para estos cuatro testigos, la clave literal no alteró la estructura predeterminada y el perfil correctamente nombrado falló. No explica por qué. Tampoco demuestra que el perfil haya fallado siempre, que el problema exista desde 2020, que afecte a cualquier recurso posible o que no pueda desaparecer con la siguiente versión.

Siete pestañas no son una prueba de perfil

Sería incorrecto saltar desde esta observación hasta una acusación contra los datos mostrados. La respuesta predeterminada contiene siete pestañas y puede organizar widgets valiosos. Los widgets pueden consultar WHOIS, RIPE RIS, RIPE Atlas u otras fuentes de manera independiente. No se ha comparado la exactitud de sus rutas, objetos o mediciones. No se ha observado una caída general ni se ha probado que la información subyacente sea falsa.

Lo que falta es una declaración de procedencia de la composición. Una página de AIRRS no dice qué perfil declaró RIPEstat como seleccionado. Tampoco señala que haya caído al valor predeterminado ni muestra la versión o la huella de la estructura. La marca AFRINIC y el contexto africano hacen que el usuario complete mentalmente esa ausencia: supone que la página es la versión AFRINIC porque está dentro de AIRRS.

Puede que el perfil regional y el predeterminado estén diseñados para ser iguales. En ese caso, la diferencia visible sería nula. Puede que seleccionen widgets u órdenes distintos. Puede que exista una caché o una última versión válida. Las pruebas no eligen entre esas posibilidades; precisamente por eso es necesario que el sistema revele su elección.

Un perfil tampoco convierte los datos en verdad oficial. Solo define una composición. Pedir una prueba de selección no otorga autoridad adicional a AFRINIC ni rebaja la utilidad de RIPEstat. Evita confundir tres enunciados: el portal tiene marca regional; el cliente pidió una configuración regional; el servidor confirmó que utilizó esa configuración. Hoy solo el primero es visible y el segundo contradice el nombre esperado.

La diferencia resulta profesionalmente relevante porque AIRRS enumera audiencias que reutilizan evidencia. Un investigador puede citar la disposición de los widgets. Un regulador puede comparar países. Un operador puede incluir una captura en una decisión de interconexión. Una página completa invita a conservar el resultado, pero sin un recibo no conserva el contexto de selección que permitiría interpretarlo después.

El cliente de 2020 y el servicio de 2026

El encabezado temporal añade una cuestión de mantenimiento. El cliente capturado tiene marca de marzo de 2020; las respuestas se identifican con una compilación de septiembre de 2026. Esta distancia justifica probar la compatibilidad en el límite entre servicios. No permite construir una historia causal.

No sabemos si profile=afrinic funcionó en 2020. No sabemos si la cadena se copió desde un contexto HTML, si el perfil cambió de nombre, si hubo una migración de esquema o si el error 500 corresponde a una condición temporal. Las fuentes tampoco muestran una promesa de compatibilidad incumplida. La fecha Last-Modified limita la copia observada; no es un registro completo de cada operación del sistema.

Asignar culpa sería todavía menos sólido. AFRINIC controla el JavaScript y la explicación del repliegue en AIRRS. RIPE NCC controla cómo RIPEstat resuelve el perfil nombrado y qué estado devuelve. Una solución verificable probablemente exige comprobar ambas mitades. La evidencia no autoriza a describir la situación como sabotaje, manipulación, incidente de enrutamiento o falla general.

La lección operativa es que una interfaz duradera necesita una prueba de contrato más precisa que “la página carga”. Esa prueba debería enviar los cuatro tipos de recurso con el perfil explícito, confirmar la selección declarada y comparar la lista de pestañas y su huella. Así, una modificación del cliente o del servidor deja un cambio observable en lugar de depender de que alguien repare en un punto y coma.

Un recibo pequeño para una dependencia grande

La solución de transparencia puede ser compacta. AIRRS podría publicar junto al resultado, o en un diagnóstico accesible, un recibo de selección de perfil.

El primer bloque indicaría el tipo de recurso y su forma canónica, el nombre exacto del parámetro enviado y el valor solicitado. El segundo mostraría el perfil que RIPEstat declara haber usado. Si el resultado es predeterminado, debería aparecer explícitamente default; la ausencia de un valor no debería adoptar por herencia la marca de la página.

Después vendrían la versión o huella normalizada de la estructura, la secuencia de pestañas y widgets, la compilación de RIPEstat, el identificador y la hora de la consulta, status, status_code y data_call_status. Ninguno de estos elementos exige revelar el historial de búsquedas del visitante, su dirección ni detalles operativos sensibles.

El recibo incluiría además la política de repliegue. Si el perfil nombrado no está disponible, AIRRS puede bloquear con una explicación, mostrar el predeterminado con una etiqueta inequívoca, o conservar una estructura regional conocida indicando su antigüedad. Cada opción equilibra de manera distinta disponibilidad, vigencia y procedencia. El control no impone una de ellas; impide que el cambio quede oculto.

Por último, debe figurar el último resultado de los cuatro testigos. No es necesario inspeccionar todo el espacio de ASN, prefijos, dominios y países. Sí es necesario comprobar que las cuatro rutas de entrada anunciadas reciben una estructura esperada. Un mero 200 no alcanza: la huella y el orden de pestañas detectan alteraciones silenciosas.

Corregir la cadena del cliente verifica que AIRRS formula la pregunta adecuada. Recuperar el perfil verifica que RIPEstat puede responderla. Comparar la estructura verifica que la respuesta mantiene el contrato previsto. Son tres pasos y ninguno sustituye a los otros.

El recibo es una propuesta de esta investigación, no una regla anunciada por AFRINIC o RIPE NCC. Su objetivo no es engrandecer una errata, sino reducir la distancia entre lo que el usuario ve y lo que el sistema puede demostrar.

Fuentes