Resumen

  • draft-brown-epp-deleg-03 propone comandos EPP para consultar, crear, añadir, retirar o eliminar en bloque los registros DELEG de un dominio.
  • El propio borrador prevé que DELEG y NS coexistirán durante mucho tiempo; por eso, un único estado aceptado por el registro puede proyectarse en dos delegaciones públicas que aún no coinciden.
  • La evidencia de cierre debe unir la transacción con la generación de zona, la firma, las autoridades del padre, la capacidad de los resolutores, las cachés y el resultado de una prueba de servicio.

El turno de guardia recibe dos capturas. En la primera, el servidor EPP devuelve éxito a una actualización con deleg:all. En la segunda, una consulta NS al padre conserva los servidores de siempre. El cambio parece reversible y el dominio parece accesible. Falta la captura decisiva: la respuesta que obtiene un resolutor que sí entiende DELEG.

La revisión 03 convierte esa ausencia en un problema concreto. Introduce elementos repetidos deleg:param, cambia la versión del espacio XML, permite retirar todo el conjunto DELEG y exige controles operativos sobre nombres y valores. El registro de Datatracker y su historial impiden exagerar: es un Internet-Draft individual, sin cauce RFC ni consenso formal del IETF. No prueba asignación, adopción ni despliegue.

El éxito pertenece a una capa concreta

EPP puede describir bien lo que ocurre en el repositorio. info puede devolver el conjunto almacenado; create puede enviar DELEG al crear un dominio; update puede añadir, retirar elementos determinados o usar deleg:all. La respuesta positiva y los identificadores de transacción son evidencias valiosas para auditar ese intercambio.

RFC 5730 define el núcleo de comandos, respuestas y correlación. RFC 5731 se ocupa del objeto dominio y RFC 5732 del objeto host. Ninguno convierte al servidor EPP en testigo de lo que después hizo el generador de zona. El cliente patrocinador está autorizado ante el repositorio; no por ello gobierna el firmante DNSSEC, los servidores autoritativos, el software recursivo o el servicio final.

La diferencia entre “solicitado”, “aceptado” y “publicado” no es burocrática. Si el registro confirma una operación y el lote de generación se detiene, la base puede estar correcta y el padre, anticuado. Si una autoridad carga el nuevo serial y otra no, ambas pueden responder con datos firmados de épocas distintas. Si la caché conserva el conjunto anterior, el usuario todavía observa una tercera realidad temporal.

La coexistencia es una arquitectura, no una nota de transición

El borrador EPP espera que la mayoría de los dominios mantenga DELEG y NS durante el futuro previsible. También recomienda que los servidores permitan combinar DELEG con objetos o atributos host tradicionales. La transición introduce así dos proyecciones destinadas a poblaciones distintas.

El borrador del grupo de trabajo Extensible Delegation for DNS propone que DELEG sea autoritativo en el padre, ampliable y protegible con DNSSEC. Puede convivir con NS o aparecer sin él. Pero, sin NS, el software que desconoce DELEG no puede resolver la zona delegada. Mantener NS no es mera duplicación: durante la adopción puede ser la única vía de compatibilidad.

Por eso deleg:all no tiene una consecuencia universal. Puede ser un retorno deliberado a NS, una retirada ordenada de una prueba o un borrado defectuoso que sólo afecta a los resolutores nuevos. Una sonda NS seguirá sana en los tres casos. La orden necesita un estado esperado y una política de migración, no sólo una sintaxis válida.

El borrador DNSOP de modificaciones para extensiones de delegación añade negociación de capacidad y protección frente a degradación. La aceptación del objeto en EPP no demuestra que las autoridades hayan servido ese protocolo ni que el resolutor lo haya negociado.

La lista de claves también tiene versión

La revisión 03 obliga al servidor a rechazar parámetros desconocidos o contenidos inválidos, y hace únicos los nombres dentro de un registro. Además, servidor y cliente deben actualizar periódicamente la lista de DelegInfoKeys registradas. Es una salvaguarda, pero también una fuente de desajuste.

Un cliente actualizado puede usar una clave que un servidor antiguo aún rechaza. Un servidor actualizado puede guardarla mientras un generador de zona no sabe representarla. Una herramienta puede validarla y una autoridad puede negarse a cargarla. Cada paso necesita su propia versión y su propio resultado.

El borrador DELEG solicita a IANA un nuevo registro de información; el de EPP solicita el espacio de nombres y la inscripción de la extensión. RFC 7451 explica el marco registral, mientras que el registro vivo de extensiones EPP de IANA muestra las asignaciones efectivas. En la captura utilizada para este informe, la extensión propuesta no aparece. Una solicitud escrita en un borrador no equivale a un acto de IANA.

La autoridad del padre exige otra prueba

El borrador base prohíbe colocar DELEG en el ápice hijo, pues el lugar equivocado puede causar fallos DNSSEC. RFC 4035 ofrece el marco para autenticar y validar datos DNS. Una respuesta validada puede demostrar la integridad de lo servido bajo esa cadena. No demuestra que sea la última proyección pretendida por el titular ni que NS y DELEG mantengan el mismo destino.

Un expediente útil conserva primero la intención, la persona o sistema autorizado, la sesión EPP, los bytes exactos, el espacio de nombres, la versión de DelegInfoKeys y ambos identificadores de transacción. Después fija la versión comprometida en el registro y la regla que concilia DELEG con hosts y NS.

La cadena continúa con la entrada y salida del generador, el serial del padre, los RRset firmados y la carga de cada autoridad. Las consultas deben cubrir rutas conscientes e inconscientes de DELEG. Para cada resolutor importan la versión, la señal de capacidad, la validación, la caché y el fallback. Sólo al final llega el canario de la aplicación y la decisión documentada de cerrar o revertir.

Los ensayos de Heng Lu funcionan como lentes declaradas. La primacía del código operativo pide observar lo que realmente responde. La especificación mínima con decisión local evita confundir interoperabilidad con política de despliegue. Las capas de realidad separan la inscripción simbólica del resultado. No son requisitos IETF; ayudan a no inflar la respuesta EPP.

Expediente oficial

Las fuentes congeladas son el estado actual, el historial, la revisión 03, los borradores DELEG y DELEXT, y las RFC de EPP núcleo, dominios, hosts, registro de extensiones y DNSSEC, junto con IANA. Son evidencia normativa o de proceso; no son un incidente ni una medición de adopción.