Resumen

  • draft-ranjbar-regext-rdap-subordinate-referrals-01 propone relaciones direccionales para descubrir un servidor RDAP elegido por el titular y dedicado a nombres, redes o direcciones subordinadas.
  • Los datos de ese servidor son afirmaciones del titular, no del operador del registro. La subordinación estricta, el enlace de regreso y el límite de saltos acotan su voz; la consulta, además, queda visible para el titular.
  • El cliente necesita conservar una costura de autoridad que separe el objeto padre del registro, el acto de designación y la respuesta subordinada.

El arranque de RDAP conduce desde los registros de IANA hasta el servicio responsable de un dominio o un intervalo de recursos numéricos. La búsqueda se estrecha hasta el objeto más específico que posee la base del operador. Esa continuidad técnica invita a pensar que todo lo que aparezca después procede de la misma autoridad.

No siempre existe una ficha central más detallada. Un registro puede guardar el dominio inscrito sin almacenar cada nombre creado dinámicamente debajo. Un RIR puede conservar una asignación agregada sin registrar cada prefijo más específico o dirección individual que distribuye el titular. La granularidad vive en el sistema operativo del titular porque allí nace y cambia.

El borrador individual quiere hacer descubrible esa fuente. El titular designaría un servidor RDAP propio o contratado. El registro apuntaría hacia abajo y el servidor del titular mantendría un camino de vuelta al servicio que conserva el objeto padre. La propuesta evita trasladar una base volátil al registro, pero crea una frontera que la interfaz debe mostrar.

Una flecha descendente no hereda mandato

La revisión 01 llama rdap-base-down al enlace hacia la URL base del servicio aguas abajo y rdap-base-up al enlace inverso hacia el registro que cubre el recurso. Son nombres de dirección. No dicen que el operador inferior se haya convertido en registro ni que este garantice todos sus datos.

El ámbito es estricto: el servidor designado solo puede ser candidato para recursos totalmente subordinados al objeto que remite. La URL debe usar HTTPS y el cliente no puede extender la autoridad a un recurso vecino, superior o ajeno. Un enlace inverso conserva el camino hasta el padre y el cliente debe limitar los saltos; uno basta para los casos descritos.

Así aparecen dos afirmaciones. El registro afirma que ese titular designó ese servicio para ese ámbito. El titular afirma el contenido de la ficha hija. Si una aplicación rotula el resultado completo como «datos del registro», transforma la primera afirmación en una aprobación que el protocolo no concede.

La compatibilidad puede esconder el relevo

El borrador mantiene el comportamiento para clientes antiguos. Cuando existe el puntero, el servidor del registro seguiría redirigiendo la consulta subordinada para entregar el registro más específico sin que el cliente entienda la relación nueva. Un cliente moderno podría descubrir el enlace y cruzar conscientemente. Quien necesite la ficha del registro podría suprimir la redirección mediante la opción que estudia el borrador de remisiones explícitas.

La compatibilidad es valiosa, pero los redireccionamientos HTTP suelen seguirse en silencio. En la pantalla desaparece el momento en que cambian el operador, la disponibilidad, la política de privacidad y el valor probatorio. El usuario cree haber hecho una consulta única cuando en realidad ha recibido una afirmación de otro actor.

draft-ietf-regext-rdap-referrals-04 define una solicitud explícita de redirección hacia un recurso relacionado. Si hay un enlace adecuado y el cliente está autorizado, el servidor devuelve un código HTTP de redirección y Location. También trata negociación, caché y cadenas. Ahorra descargar una ficha completa solo para extraer un enlace, pero no resuelve la atribución pública de la respuesta final.

El titular publica y observa

La sección de seguridad aclara que los datos del servicio designado son afirmados por el titular, no por el registro. Esa procedencia decide quién corrige, quién conserva, quién responde por una discrepancia y qué fuente puede citarse en un expediente.

Además, la consulta llega a infraestructura del titular. Este puede observar interés por sus recursos. El texto compara esa visibilidad con la que ya posee un operador DNS y permite que un cliente con necesidades de confidencialidad no siga la remisión. El derecho solo es real si el software pregunta antes del salto y todavía ofrece el objeto padre.

La continuidad también se divide. Una caída del servicio del titular elimina el detalle adicional, pero no las respuestas propias del registro. Un cliente debería informar «capa subordinada no disponible» y conservar el objeto que cubre el recurso. Una avería del registro, un puntero erróneo y una caída del titular no son el mismo incidente.

La designación es el punto de poder no especificado

El borrador deja fuera el canal por el que el titular comunica su servidor al registro. Menciona como ejemplos un portal o una futura extensión EPP. Precisamente allí se decide quién puede desviar la consulta.

Hace falta un ciclo administrativo: alta autenticada, prueba del ámbito, validación del destino, activación, renovación, cambio, revocación y limpieza cuando cambia el titular. Operar el servidor no debería implicar automáticamente poder cambiar el puntero. Una transferencia del dominio o del recurso numérico debe cerrar la autoridad anterior de forma comprobable.

El registro debería verificar que el destino devuelve RDAP conforme para los recursos del titular. Sin embargo, la conformidad sintáctica no prueba propiedad ni exactitud. Un servidor puede responder JSON perfecto sobre un objeto que no le corresponde. La prueba de designación y la prueba de contenido son distintas.

Conservar la costura de autoridad

Propongo registrar la costura cada vez que se sigue una remisión. No es un requisito del borrador. Es una disciplina para que el descubrimiento no lave la procedencia.

La primera capa guarda el camino de arranque, el objeto padre, el servicio de registro, la relación, el destino, el actor y canal de designación, la fecha de activación, el ámbito y la última comprobación de conformidad. Lo que no esté disponible queda marcado como desconocido.

La segunda capa conserva la travesía: ruta consultada, redirección ordinaria o relación explícita, código, decisión de suprimir, URL de destino, resultado TLS, hora y número de saltos. También registra si el usuario fue advertido de que el titular vería la consulta.

La tercera capa mantiene aparte la afirmación subordinada: servicio que respondió, objeto, hora, tokens de conformidad, vida de caché y enlace de regreso. La interfaz puede presentar el detalle como «afirmado por el titular» junto a la ficha del registro, no en sustitución silenciosa.

Las relaciones propuestas son generales para poder apoyar RPKI delegado o híbrido y la modernización de RWhois o SWIP. Esa reutilización ahorra vocabulario, pero «aguas abajo» solo describe topología. Cada uso puede tener un acuerdo y un nivel de confianza diferentes.

La revisión 01 está fechada el 21 de julio de 2026 y sigue siendo un Internet-Draft individual. Datatracker no muestra respaldo formal, flujo ni estado RFC previsto, mientras el encabezado dice Standards Track. El autor prefiere integrar el contenido en el borrador del grupo REGEXT. La sección de implementación cita un servicio del lado del titular y señala que falta el salto del lado del registro. No demuestra adopción amplia.

Los datos subordinados merecen una vía de descubrimiento. Lo que no merecen es una autoridad prestada por el diseño de la pantalla. El camino puede continuar; la atribución debe cambiar en el punto exacto del salto.

Fuentes