Resumen

  • APNIC registró un incidente RDAP de 18 horas, desde el 27 de enero de 2026 a las 15:45 hasta el día 28 a las 09:45, en UTC+10.
  • Un cambio no intencionado de configuración en Cloudflare aplicó controles de integridad de navegador más estrictos y bloqueó aproximadamente el 10 % de las solicitudes cuyo User-Agent no coincidía con los habituales de los navegadores.
  • Cloudflare cumple una función legítima de equilibrio de carga y defensa contra denegación de servicio; el problema es convertir el aspecto del software en una frontera de admisión para un protocolo automatizable.
  • En septiembre, cuatro consultas de baja frecuencia con perfiles de User-Agent distintos devolvieron el mismo objeto JSON. Es una observación actual y limitada, no una reproducción histórica ni una garantía universal.
  • APNIC puede acreditar la interoperabilidad con canarios por clase de cliente, resultados separados del borde y del origen, y una línea de despliegue y reversión que no revele reglas sensibles.

El diez por ciento necesita conservar su denominador

El aviso oficial de APNIC ofrece una cifra notable, pero también la acota. El servicio afectado fue RDAP. El comienzo fue el martes 27 de enero de 2026 a las 15:45; el final, el miércoles 28 a las 09:45, siempre en UTC+10. La duración declarada es de dieciocho horas. Durante ese intervalo, aproximadamente el 10 % de las solicitudes RDAP que contenían cadenas User-Agent distintas de las habituales de los navegadores fueron bloqueadas.

La unidad es una solicitud. No es un usuario, una empresa, un operador de red ni una herramienta. Un único programa puede emitir muchas consultas; varios programas pueden compartir biblioteca y encabezado; una denegación puede provocar reintentos. El material público no permite calcular cuántos actores distintos estuvieron detrás del porcentaje ni qué decisiones dependían de sus respuestas.

APNIC tampoco publica en ese aviso los códigos HTTP, el cuerpo de la denegación, las ubicaciones, las cadenas concretas o el umbral de seguridad. No sabemos si todas las solicitudes no parecidas a un navegador sufrieron la misma respuesta. No podemos identificar una aplicación afectada. Mantener esos vacíos no debilita la investigación: impide que una descripción precisa de mecanismo termine convertida en una acusación imaginaria.

La información suficiente es esta: parte de la demanda fue clasificada por el intermediario antes de recibir la respuesta normal del servicio. Por eso una métrica observada solo desde el origen y una sonda que siempre simule un navegador pueden omitir exactamente la clase de fallo que ocurrió.

La defensa de APNIC no es un detalle

RDAP no puede funcionar como una promesa de capacidad infinita. La consulta estructurada facilita la automatización legítima, pero la misma interfaz puede recibir barridos excesivos, patrones abusivos y ataques de denegación de servicio. Mantener el servicio disponible para la comunidad exige controles de volumen y comportamiento.

APNIC explicó en 2020 que las consultas dirigidas a rdap.apnic.net y a los servicios RDAP de registros nacionales pasan por Cloudflare. El proveedor aporta reparto de carga y protección DDoS antes de enviar las consultas hacia infraestructura de Google Cloud. Quitar ese borde sin más trasladaría el riesgo al origen y no resolvería la obligación de disponibilidad.

La documentación de Browser Integrity Check también describe un propósito razonable. Cloudflare busca encabezados HTTP frecuentes en tráfico abusivo y puede desafiar peticiones con User-Agent ausente o no estándar. Una señal así puede ser útil dentro de una decisión de varias capas. Además, el producto permite limitar o desactivar el control mediante reglas de configuración.

La crítica defendible no consiste en declarar ilegítima toda protección antirrobot. Consiste en reconocer que un valor normal para un sitio interactivo no tiene por qué ser normal para un servicio de protocolo. Si la misma regla cubre ambos, el perímetro compartido puede crear dos contratos distintos bajo una sola dirección aparente.

RDAP espera clientes que no son personas ante una pantalla

El propio APNIC describió RDAP en 2021 como JSON sobre HTTP o HTTPS, fácil de procesar por máquinas. Una sola implementación puede interpretar la mayoría de las respuestas RDAP y aprovechar la caché HTTP. Esa promesa reduce una parte de la variación que históricamente complicó WHOIS.

RFC 9082 define patrones uniformes para consultar dominios, servidores de nombres, entidades, redes IP y sistemas autónomos. RFC 7480 fija el transporte HTTP. También contempla aplicaciones dentro del navegador mediante acceso entre orígenes, pero no otorga al navegador prioridad arquitectónica. Un script de inventario, un cliente de terminal, una mesa de abuso y un sistema de investigación son clientes naturales aunque no presenten cabecera de interfaz gráfica.

Por eso “no se parece a un navegador” no equivale a “no se parece a RDAP”. Puede significar lo contrario: el software se está identificando con honestidad como programa especializado. Una regla construida para detectar rarezas en páginas web puede convertir una propiedad ordinaria del protocolo en una anomalía.

Este argumento tampoco convierte toda automatización en autorizada. La especificación de seguridad de RDAP, RFC 7481, reconoce el problema de disponibilidad y permite aplicar límites. La autenticación puede distinguir accesos con derechos adicionales. El ritmo, el patrón de consultas y otras señales pueden justificar una restricción. La afirmación es más pequeña: el parecido con un navegador no demuestra por sí solo ninguna de esas cosas.

User-Agent es una declaración de software, no una credencial

RFC 9110 define User-Agent como información sobre el software que origina la solicitud. Sirve para identificar productos, ajustar respuestas y diagnosticar problemas de interoperabilidad. La cadena la escribe el propio cliente. Puede contener productos y comentarios, reducirse o imitar a otro agente.

No autentica a la persona u organización que controla el proceso. No informa de un contrato con APNIC, del propósito de la consulta, del derecho a una capacidad mayor ni de la inocencia del tráfico. Un robot malicioso puede copiar una cadena popular. Una herramienta legítima puede llevar un nombre poco conocido. La apariencia no es mandato.

Esto no obliga a ignorar la cabecera. Puede aportar evidencia débil dentro de un conjunto mayor. Pero hay que observar qué autoridad recibe el indicio. Si solo eleva o reduce una puntuación que se contrasta con comportamiento, conserva su papel. Si impide todo acceso a un protocolo de máquinas, acaba decidiendo más de lo que puede probar.

El resultado altera el ecosistema. Los autores de clientes descubren que identificarse como tales empeora la disponibilidad y adoptan una cadena de navegador. El tráfico abusivo adopta la misma máscara. Con el tiempo, la telemetría pierde la categoría “automatización honesta” y el filtro se entrena sobre una población deformada por el propio filtro.

APNIC califica el efecto de no intencionado. Conviene tomar esa frase en serio. No hay base para atribuir una política deliberada contra los clientes de máquinas. Sí hay base para tratar el suceso como un problema de alcance, revisión y canarios en una configuración que forma parte del servicio efectivo.

La respuesta legible también es una forma de control

La protección por volumen tiene semántica propia. RFC 7480 recomienda usar HTTP 429 para limitar frecuencia, reducir el ritmo y respetar Retry-After cuando aparece. Un programa puede distinguir así entre “la consulta es inválida”, “el servicio no está disponible” y “vuelve más tarde a menor velocidad”.

No sabemos si esa respuesta correspondía a los bloqueos de enero, ni la especificación obliga a representar toda decisión de un sistema antirrobot como 429. Un desafío de seguridad y un límite de frecuencia son mecanismos diferentes. Confundirlos sería inventar el detalle que APNIC no publicó.

Lo importante es que la capa se conserve en la evidencia. Una página de desafío, un HTML opaco o una denegación del borde no son un objeto RDAP del origen. Si la monitorización transforma cualquiera de ellos en un simple “error HTTP”, pierde la causa. Si solo mira el origen, puede no contar la solicitud. Si una sonda de navegador atraviesa el control, puede no ver que otro cliente quedó fuera.

Un canario de septiembre encuentra igualdad

El 5 de septiembre de 2026 se enviaron cuatro consultas GET, de baja frecuencia, a https://rdap.apnic.net/ip/202.12.29.0. Todas solicitaron application/rdap+json. Una no incluyó User-Agent explícito. Otra declaró un User-Agent de automatización que indicaba su finalidad. La tercera usó curl/8.7.1. La última presentó una cadena de estilo Mozilla/Safari.

Las cuatro recibieron HTTP 200 y contenido application/rdap+json. El cuerpo medía 3.857 bytes y tenía en todos los casos el SHA-256 d6983abd9266f7ac6d6a23b8b5cf67c186aae673a64030fc04e4e457837bb853. Las cabeceras mostraron a Cloudflare en la ruta.

La muestra indica que en ese momento los cuatro perfiles llegaron al mismo resultado para ese recurso. Es una señal compatible con una condición reparada. Pero no cubre otras consultas, métodos, redes, regiones, puntos de presencia, velocidades o momentos. Tampoco prueba por sí sola cómo funcionaba la regla en enero. La igualdad de cuatro respuestas es un canario; no es una auditoría total.

El comprobante mínimo une borde y origen

APNIC puede producir una prueba útil sin exponer expresiones del WAF, umbrales, reputaciones o vías para evadirlos. Debe definir primero las clases legítimas que el contrato público promete atender. Un conjunto mínimo sería: ausencia de User-Agent, automatización con nombre propio, cliente común de línea de comandos y navegador.

Cada canario debe registrar dos decisiones. La primera es la del borde: pasó, fue limitado, recibió desafío o fue bloqueado. La segunda es la del origen: llegó y qué clase de respuesta RDAP produjo. Añadir estado HTTP, tipo de contenido, latencia y semántica de reintento permite que un programa interprete el resultado. Separar capas evita que un origen saludable oculte una puerta cerrada.

El segundo componente es la genealogía del cambio: identificador, responsable, revisor, alcance, hora de despliegue, hora de reversión y validación posterior. No hace falta publicar la regla para demostrar que el control de navegador quedó fuera del camino RDAP o se combinó con excepciones y límites conscientes del protocolo. Una estadística agregada de decisiones por clase puede ayudar sin revelar el umbral.

APNIC ya publicó una metodología de perspectiva del usuario. Para el segundo trimestre de 2025 consideraba correcta una prueba RDAP si entregaba una respuesta HTTP sin error en menos de cinco segundos y calculaba éxitos sobre el total. La dimensión de clase de cliente es una extensión natural de esa idea, no una petición de abandonar la medida.

En su resumen del primer trimestre de 2026, APNIC afirmó que todos los servicios principales del registro alcanzaron al menos 99,99 % de disponibilidad. El texto breve no muestra denominadores ni el detalle necesario para relacionarlo con este incidente. No se puede afirmar que sea falso. Se puede pedir que una futura cifra deje visible qué ocurre en el borde y qué población de clientes representa.

Los límites de esta conclusión

El aviso no prueba una avería actual, una violación deliberada de estándares o daños concretos para un grupo identificado. Aproximadamente el 10 % de solicitudes no significa todos los clientes de máquina. La sonda de septiembre tampoco demuestra que no exista ninguna diferenciación en otro lugar.

La conclusión válida es de control. Un protocolo legible por máquinas atravesó durante un intervalo una regla que valoraba el parecido con navegadores; APNIC dijo que ese efecto no era intencionado. La forma más pequeña de evitar que se repita es hacer visibles las clases de cliente a través de las dos capas que deciden el resultado.

No hay que elegir entre seguridad y apertura ciega. Hay que impedir que una señal de apariencia ocupe el lugar de la autoridad y que una capa de protección desaparezca de la contabilidad del servicio.

Fuentes

  1. APNIC, anuncio de servicio del 28 de enero de 2026
  2. APNIC Blog, una nueva infraestructura para servir RDAP
  3. APNIC Blog, ¿está RDAP listo para sustituir a whois?
  4. APNIC Blog, disponibilidad de servicios de registro en el segundo trimestre de 2025
  5. APNIC Blog, actualización de la Secretaría del primer trimestre de 2026
  6. Cloudflare Docs, Browser Integrity Check
  7. RFC 7480, uso de HTTP en RDAP
  8. RFC 7481, servicios de seguridad para RDAP
  9. RFC 9082, formato de consultas RDAP
  10. RFC 9110, semántica de HTTP