Resumen

  • RFC 9910, un Proposed Standard de la IETF de enero de 2026, añade capacidades de búsqueda RDAP específicas de los RIR para redes IP, números y rangos de sistemas autónomos, y objetos DNS inversos.
  • Las búsquedas básicas y las búsquedas de relación formulan preguntas distintas sobre una jerarquía de registro. Un enlace de resultado puede conservar la búsqueda o apuntar a una consulta única; por ello deben conservarse la consulta, la respuesta y el momento de observación.
  • Una relación devuelta es evidencia de lo que informó un servicio RDAP autorizado en un momento concreto. No demuestra propiedad, título jurídico, permanencia, integridad del conjunto de datos ni despliegue universal de los RIR.

El mecanismo

RDAP ya define convenciones de consulta estructurada y de respuesta. RFC 9910 añade una superficie de búsqueda propia de los registros regionales de Internet mediante segmentos de ruta explícitos y el identificador registrado rirSearch1. Su alcance incluye búsquedas de redes IP, números autónomos o rangos de ASN, y objetos DNS inversos. Según la clase de objeto, la entrada puede ser una dirección IP o un par CIDR, un nombre de dominio, o un ASN individual o un rango de ASN.

Una búsqueda básica pide al registro objetos que coincidan con la clase de recurso seleccionada. Una búsqueda de relación pide objetos situados con respecto a otro recurso dentro de la jerarquía de recursos de numeración de Internet. La dirección jerárquica importa: el resultado puede describir un padre, un hijo u otra relación definida respecto del objeto inicial. Los tipos de relación definidos y los filtros de estado opcionales afinan la pregunta, pero no convierten la respuesta en un registro general de propiedad.

Enlaces de búsqueda y conjuntos de resultados

Hay que distinguir entre una URL de búsqueda y una URL de consulta. La URL de búsqueda conserva la consulta que produjo un conjunto de resultados. Si el servidor devuelve un solo resultado, RFC 9910 permite que un enlace sustituya esa búsqueda por una URL de consulta directa. La diferencia es operativa: el cliente posterior puede recuperar el objeto por su identificador en lugar de repetir la búsqueda original. Si el estado del registro cambia entre ambas peticiones, la consulta y el resultado inicial pueden dejar de coincidir.

Trate la respuesta como un conjunto de resultados con un límite temporal. Registre la ruta exacta, los parámetros, el tipo y la dirección de la relación, el filtro de estado, la autoridad del registro, los bytes de respuesta, el enlace devuelto y el momento de observación. Guardar la URL de consulta sirve para navegar, pero no sustituye a la URL de búsqueda ni a la respuesta capturada. Si la decisión depende del estado actual, vuelva a consultar.

RFC 9082 aporta la semántica básica de las rutas de consulta y búsqueda; RFC 9083 describe las respuestas JSON de RDAP y los objetos de enlace. RFC 9910 controla las rutas de búsqueda específicas de los RIR, el vocabulario de relaciones y el comportamiento de los resultados. RFC 7481 mantiene los límites operativos: autenticación, autorización, confidencialidad, privacidad, limitación de tasa y restricciones regulatorias siguen vigentes. Una superficie de búsqueda más amplia no anula la política de acceso del servidor ni las reglas de una jurisdicción.

Registro de evidencia en el momento de observación

  • Observado en: 2026-09-06T07:55:55.126Z, momento de congelación del paquete de fuentes.
  • Autoridad que debe registrarse: el servidor RDAP o punto de acceso del RIR que entregó la respuesta; el paquete no demuestra el despliegue actual de cada RIR.
  • Evidencia de consulta: clase de objeto, IP/CIDR, dominio, ASN o rango, dirección y tipo de relación, y filtro de estado.
  • Evidencia de respuesta: bytes sin procesar, forma del conjunto de resultados, relación del enlace, URL de búsqueda, posible URL de consulta y metadatos permitidos.
  • Límite: el registro documenta una observación, no un título jurídico, una jerarquía permanente, datos completos ni una verdad atemporal.

Ruta de decisión para la aceptación del operador

  1. Defina la pregunta. Elija búsqueda básica o de relación, clase de objeto, dirección jerárquica y filtro de estado, si corresponde.
  2. Compruebe la autoridad. Confirme el endpoint, la autorización, la base de privacidad, el límite de tasa y el permiso jurisdiccional antes de realizar la petición.
  3. Capture la fuente. Conserve la URL de búsqueda, la respuesta, la clase de resultado, la relación y el momento de observación. No guarde únicamente el atajo de consulta.
  4. Evalúe la decisión. Acepte el resultado solo como evidencia temporal del registro. Si hace falta el estado actual, vuelva a consultar y compare; ante una denegación o ambigüedad, deténgase o escale en vez de inferir.
  5. Registre el cambio. Un cambio de enlace, estado o posición jerárquica es una nueva observación y debe incluir su efecto operativo.

Theo March — análisis: RFC 9910 hace más consultable el descubrimiento de jerarquías, pero la rendición de cuentas depende de conservar cómo y cuándo se obtuvo la respuesta. El control práctico no es confiar en una URL, sino capturar evidencia de forma disciplinada dentro de los límites de autoridad y privacidad de RDAP.

Fuentes