Resumen

  • draft-ietf-dnsop-delegation-mgmt-via-ddns-02 propone enviar cambios exactos de NS, glue o DS desde el hijo hacia un receptor del padre mediante DNS UPDATE con SIG(0), descubierto por DSYNC.
  • La petición inicial está autofirmada: acredita posesión de la nueva clave privada, pero no el derecho de esa clave a gobernar el hijo. El receptor debe distinguir la clave known de la clave trusted tras una validación adicional.
  • Conviene registrar una transición de autoridad que una clave anterior, método de arranque, evidencia independiente, decisión de política, aceptación y publicación efectiva. Es una propuesta de gobernanza de este artículo, no una exigencia del borrador.

El problema no está en verificar la firma. Está en decidir qué significa.

Una persona desconocida puede crear un par de claves, enviar la pública y demostrar control de la privada. Esa demostración evita que otro haya alterado el mensaje, pero es circular como prueba de autoridad: la credencial candidata presenta sus propias referencias. En una delegación DNS, aceptar esa circularidad permitiría que cualquier clave recién inventada solicitara poder sobre servidores de nombres y datos DNSSEC.

La revisión 02 de Automating DNS Delegation Management via DDNS se publicó el 17 de junio de 2026. Datatracker la identifica como documento de trabajo activo de DNSOP. Como todo Internet-Draft, puede cambiar, ser sustituida o expirar. El documento renderizado indica Standards Track; la ficha de Datatracker deja sin completar el estado RFC previsto. No es un RFC ni prueba que un registro haya implantado la propuesta.

Su problema operativo sí es conocido. Los datos de delegación del hijo y del padre pueden dejar de coincidir. Una vieja dirección de glue, un conjunto NS incompleto o un DS desfasado no siempre derriba el dominio de inmediato. A veces elimina redundancia y prepara una caída que solo se manifiesta cuando falla el último camino sano.

Los mecanismos basados en CDS y CSYNC suelen requerir que el padre explore periódicamente zonas hijas y valide lo observado. La alternativa del borrador invierte la iniciativa. El hijo sabe cuándo ha cambiado su configuración, calcula el alta o la baja exacta y la envía como DNS UPDATE. Un registro DSYNC publicado por el padre anuncia el receptor y el puerto. Menos barrido y menor latencia son ventajas reales, también para hijos que no firman su zona.

Sin embargo, hacer más rápido el transporte de una intención no resuelve quién puede formularla.

El receptor es una aduana, no una tubería

Un UPDATE, a diferencia de una simple notificación, lleva la modificación concreta que el emisor desea. SIG(0) firma la transacción con criptografía asimétrica. Cuando el receptor ya confía en la clave pública, puede comprobar que el mensaje procede del poseedor de la privada y que no fue modificado.

La frase decisiva es “ya confía”. El borrador reconoce que una firma SIG(0) puede tener una fortaleza criptográfica comparable a DNSSEC sin heredar su cadena de confianza. La clave de UPDATE obtiene confianza mediante un arranque específico. El algoritmo protege el mensaje; la política instituye al firmante.

Por eso el UPDATE Receiver puede estar separado del servidor primario y delante del sistema de aprovisionamiento. Debe restringir el contenido admisible, comprobar que un cambio NS, glue o DS satisface las reglas aplicables, conservar auditoría y decidir si lo aprueba. Una firma válida no obliga al padre a aplicar el cambio.

La regla predeterminada limita cada clave a un nombre. La delegación de child.parent. solo acepta una firma de una clave confiable cuyo nombre sea exactamente child.parent.. Se evita así que la clave de un hijo reescriba a otro. Un esquema alternativo puede autorizar una clave de registrar para muchos hijos, pero entonces el receptor debe probar por otra vía el mandato para cada operación. Escalar la credencial concentra también el riesgo.

Primero se aprende la clave; después se decide confiar

El arranque comienza con un UPDATE autofirmado que propone un nuevo KEY y puede incluir la orden de borrar los anteriores. Si la autofirma valida, el receptor sabe que el remitente posee la nueva clave privada. El estado adecuado es known, no trusted.

La diferencia salva a la clave vigente. El receptor no puede cumplir la supresión del conjunto anterior hasta que la sustituta haya superado su validación. Si esta falla, la propuesta no entra en confianza y la clave antigua permanece. De otro modo, cualquier atacante podría desalojar una credencial legítima presentando una sustituta inválida: ni siquiera necesitaría que la aceptaran.

Este estado intermedio también mejora la operación. Una clave desconocida, una clave conocida cuya comprobación sigue pendiente y una clave conocida cuya comprobación fracasó no exigen la misma respuesta. El borrador incluso propone errores extendidos distintos. Reintentar continuamente ayuda en el primer caso, quizá en el segundo, y no arregla el tercero.

Las interfaces deben resistir la tentación de simplificar. “Clave cargada”, “clave vista” y “clave activa” no son sinónimos. Si el historial sobrescribe el registro de la propuesta al aprobarla, después será imposible probar qué control convirtió una posesión en una autorización.

La identidad depende del camino de arranque

Cuando el hijo está firmado, puede publicar el KEY en el ápice y el padre validarlo con DNSSEC. Si el hijo no está firmado pero uno de sus servidores de nombres pertenece a una zona firmada, el proveedor puede volver a publicar la clave bajo un nombre especial de su propia zona. Así el padre obtiene una cadena DNSSEC, aunque esa opción depende de una coordinación operativa con el proveedor que la especificación no completa.

Para un hijo totalmente no firmado, la propuesta permite observar el KEY varias veces, desde lugares de red distintos y por transportes diferentes. La coincidencia temporal y espacial reduce la oportunidad de un atacante en ruta. No prueba al titular. Prueba, con cautelas, al operador que controla las respuestas autoritativas en ese periodo. El propio borrador califica unsigned como la modalidad automática más débil.

También puede existir un arranque manual. Su nombre no dice si consiste en una autenticación robusta del titular o en un correo fácil de recuperar. Lo relevante es la fuente de autoridad, el desafío, el canal, las excepciones y la conservación de la evidencia.

Cada vía autoriza potencialmente a un principal diferente. Controlar la zona firmada, controlar los servidores autoritativos y controlar la cuenta registral pueden coincidir, pero una política no debe suponerlo sin declararlo. La elección del método es una elección sobre quién puede hablar por el dominio.

El menú de métodos también puede ser atacado

El padre puede anunciar sus opciones mediante el parámetro SVCB bootstrap en el destino DSYNC. at-apex, at-ns, unsigned y manual permiten que el hijo no tenga que adivinar el procedimiento disponible.

Ese menú interviene en la seguridad. Si se falsifica una publicación no firmada, puede ocultarse una opción fuerte y presentar solo la vía débil. El texto recomienda firmar el SVCB cuando el padre tiene DNSSEC y escoger el método más fuerte que el hijo pueda cumplir.

La prueba del arranque debe incluir, por tanto, el contexto de selección. Registrar únicamente la opción final oculta un posible downgrade. Hacen falta la respuesta DSYNC, el menú SVCB, su validación, las capacidades del hijo y la regla usada para decidir.

Una respuesta aceptada todavía no es la zona publicada

Con la clave en estado trusted, el receptor verifica la firma, el nombre y la política de cada UPDATE. Si responde NOERROR, confirma que ha recibido y aceptado el cambio. La redacción del borrador dice que debe esperarse su publicación en el padre en un momento posterior.

Ese intervalo puede importar más que el intercambio. Durante un cambio de proveedor, el hijo no debería retirar el servicio antiguo por haber recibido una aceptación si los servidores del padre todavía sirven la delegación previa. Para DNSSEC, cerrar antes de observar el nuevo DS puede convertir una transición correcta en fallo de validación.

El tablero operativo necesita cuatro hitos independientes: KEY conocido, KEY confiable, UPDATE aceptado y RRsets publicados. El primero describe adquisición; el segundo, autoridad; el tercero, decisión de cambio; el cuarto, estado público. Un solo indicador verde no permite saber qué reparación aplicar.

También hay confianza en sentido inverso. Las respuestas del receptor son plenamente útiles para automatización cuando el hijo puede validar su clave. Sin esa validación, una respuesta falsa puede afirmar que la clave es desconocida y provocar un nuevo arranque. No entrega al atacante el poder de cambiar la delegación, pero sí un vector de perturbación.

Un recibo para la transición de autoridad

Propongo conservar un recibo por cada arranque o recuperación. No añade un registro DNS ni atribuye requisitos nuevos a DNSOP. Su función es impedir que una base de datos convierta known en trusted sin una explicación reproducible.

El recibo fija el hijo y el padre, la identidad del receptor, la respuesta DSYNC, versión de software y política, huellas de las claves antiguas y nueva, resumen exacto de la petición autofirmada y ventanas temporales. Conserva todos los métodos anunciados, la validez del anuncio, los que el hijo podía satisfacer y el motivo de elección.

Después nombra el principal que la política pretendía autorizar. En la vía DNSSEC registra cadena, nombres consultados, fecha y resultado. En unsigned documenta independencia real de puntos de vista, horarios, transportes y respuestas completas. En la vía manual referencia sesión, expediente de autoridad, revisor, desafío y excepciones sin volcar información personal a una superficie pública.

Los eventos known, validación, fallo, promoción, sustitución y revocación conservan actor y hora. El recibo muestra que la clave anterior no se retiró antes del éxito. Los UPDATE posteriores añaden el delta exacto, controles aplicados, decisión, respuesta y trabajo de aprovisionamiento. La fase final observa el nuevo estado en los servidores autoritativos del padre.

La automatización no necesita eliminar el juicio; necesita localizarlo. La autofirma demuestra una herramienta bajo control. El recibo demuestra el proceso que decidió poner esa herramienta al mando.

Fuentes

  1. Automatización de la gestión de delegaciones DNS mediante DDNS — revisión 02
  2. Registro Datatracker del borrador DNSOP
  3. Historial del borrador
  4. Documentos de DNSOP
  5. Grupo de trabajo DNSOP
  6. RFC 9859: notificaciones DNS generalizadas
  7. RFC 2136: actualizaciones dinámicas del DNS
  8. RFC 2931: firmas de peticiones y transacciones DNS
  9. RFC 3007: actualización dinámica segura
  10. RFC 8078: gestión de DS desde el padre
  11. RFC 7477: sincronización de hijo a padre
  12. The Policy Mirror