Resumen

  • RDAP DELEG-05 retiró priority y target, cambió el nombre de la estructura a DelegInfos y alineó sus ejemplos con DELEG-11.
  • El borrador que define el aprovisionamiento por EPP todavía incluye ambos atributos en un esquema XML que presenta como completo y apto para validación automática.
  • El texto RDAP ya exige anunciar dnsDeleg, aunque deja como TBD la definición integral de las parejas clave-valor de su JSON.
  • La evidencia permite hablar de deriva entre especificaciones, no de un fallo desplegado: aún no existe en los textos una prueba reproducible de ida y vuelta entre EPP, DNS y RDAP.

La salida pública ya sigue a DELEG-11

El anuncio del I-D fechó la revisión 05 el 4 de septiembre de 2026. Su objetivo es añadir a los objetos de dominio RDAP una representación de los nuevos registros DELEG y DELEGPARAM que se diseñan para delegar autoridad en DNS.

La lista de cambios explica el salto respecto de la revisión 04. Se eliminaron priority y target; delegInfo pasó a llamarse DelegInfos; y los ejemplos se reconstruyeron a partir de DELEG-11. El borrador base DELEG-11 señala que su formato, aunque aprovecha ideas de SVCB, no contiene SvcPriority ni TargetName. Solo mantiene una lista extensible de claves y valores.

El conjunto inicial ofrece server-ipv4, server-ipv6, server-name e include-delegparam, más la clave mandatory. También propone un registro IANA propio. Cada clave futura debería tener número, nombre, significado, referencia estable y responsable del cambio. Así, la extensión se abre sin convertir el espacio de nombres en una zona privada de cada proveedor.

RDAP-05 ha seguido esta decisión. En el extremo de lectura ya no presenta los dos miembros abandonados.

La entrada EPP conserva otra época del diseño

El proyecto RDAP no se apoya únicamente en DELEG. También cita de forma normativa el mapeo EPP de DELEG. Esa pieza describe cómo un cliente patrocinador añade, retira o consulta datos DELEG de un dominio dentro de un registro, sobre la base del mapeo de nombres de dominio de RFC 5731.

La revisión 02 del proyecto EPP incluye una sección de sintaxis que califica como esquema completo para validar automáticamente XML. Allí, delegType sigue teniendo un atributo priority de entero corto sin signo y otro atributo target. El tipo de parámetros, además, permite atributos arbitrarios mediante processContents="skip".

La diferencia puede deberse simplemente al calendario. EPP-02 es del 21 de julio; DELEG-11, del 23; RDAP-05, de septiembre. Pero la fecha no reemplaza una política de conversión. Una solicitud EPP puede ser válida según el esquema publicado y, al mismo tiempo, contener dos conceptos que el modelo DNS actual declara ausentes y el modelo RDAP actual retiró.

¿Debe el registro rechazarlos? ¿Ignorarlos? ¿Conservarlos como extensión privada? ¿Traducirlos? Las tres especificaciones no ofrecen hoy una respuesta única. Tampoco hay evidencia aquí de que un operador haya elegido alguna de ellas. Por eso el hallazgo es de diseño documental, no de incidente.

Una etiqueta no conserva la historia del dato

RDAP-05 ordena añadir dnsDeleg a rdapConformance cuando la respuesta contiene la nueva estructura. En RFC 9083, esos identificadores anuncian las especificaciones usadas para construir el JSON. Son útiles para que un cliente reconozca extensiones, pero no certifican la transformación anterior ni el origen de cada valor.

Justo después de definir DelegInfos, la revisión 05 deja un TBD: falta especificar por completo qué parejas clave-valor pueden aparecer. El texto espera la evolución de DELEG y de EPP. Los ejemplos permiten imaginar la forma del resultado; no dicen cómo demostrar que una entrada XML, un registro DNS y una salida JSON expresan el mismo estado.

En la fecha de congelación, dnsDeleg no figuraba en el registro IANA de extensiones RDAP. El borrador solicita ese alta con alcance “Any”. La ausencia no implica rechazo ni juicio de IANA; solo confirma que la cadena sigue en fase de propuesta.

El grupo REGEXT tiene otro borrador sobre versionado de extensiones RDAP. Propone versiones legibles por máquinas, relaciones entre predecesores y sucesores, avisos de retirada y políticas de migración. RDAP DELEG aún no enlaza su carga con una identidad de versión de ese tipo.

Los tres textos no tienen el mismo rango

El Datatracker de RDAP DELEG lo registra como I-D individual, sin flujo RFC ni Area Director responsable. El mapeo EPP también es individual. Publicar un I-D no equivale a adopción o aval del IETF.

DELEG-11 sí pertenece al grupo de trabajo DELEG y está en Working Group Last Call. Todavía no es un RFC: algunos números de tipo DNS y el nuevo registro de claves siguen pedidos o pendientes. La mayor madurez del borrador base no se transfiere automáticamente a sus acompañantes.

La lectura prudente es que hay una costura abierta y reparable. La lectura exagerada —que ya se están corrompiendo delegaciones— no está respaldada por las fuentes.

La unidad que falta no es otro nombre, sino un recorrido

La conformidad de cada interfaz por separado no resuelve el traspaso. Hace falta fijar qué revisión manda sobre cada campo, cómo una orden EPP se convierte en datos DNS autoritativos, cómo se proyectan esos datos en RDAP y qué pérdidas son deliberadas.

Si eso no queda registrado, dos respuestas con dnsDeleg pueden usar decisiones de conversión distintas sin revelarlo. Quien controla el puente controla qué parte de la intención del titular llega al registro público. Ese control es operativo y, por tanto, también es gobierno.