Resumen

  • La revisión 02 de Automating DNS Delegation Management via DDNS es trabajo activo de DNSOP, no un RFC ni evidencia de una implantación.
  • El hijo descubre un receptor mediante DSYNC y firma una actualización de NS, glue o DS con SIG(0); el padre conserva la validación, la política y la integración con su aprovisionamiento.
  • NOERROR confirma recepción y aceptación, pero el propio borrador deja la publicación para un momento futuro. La ausencia de respuesta tampoco demuestra que la solicitud no haya sido aplicada.
  • Un flujo seguro necesita generaciones de intención, reintentos acotados y observación autoritativa antes de retirar la ruta anterior o declarar terminada la transición.

El silencio divide la historia en ramas

Cuando no llega respuesta, existen al menos tres relatos compatibles con la misma observación. La solicitud pudo perderse antes del receptor. El receptor pudo aceptarla y perderse la respuesta. O el servicio pudo fallar antes de emitir una decisión. El emisor no puede elegir uno mirando su temporizador.

La revisión 02 recomienda esperar al menos cinco segundos, aplicar retroceso exponencial y abandonar tras no más de cinco reintentos por actualización, salvo conocimiento local. Es una disciplina de carga y transporte. No convierte cinco silencios en prueba de que el estado del padre siga intacto.

El reintento debe conservar la identidad de la intención. Si el hijo ha decidido después otro conjunto de NS, repetir un mensaje antiguo puede revivir glue obsoleto o anular una corrección. Los tiempos de inicio y expiración de SIG(0) reducen el valor de una captura, pero no expresan cuál de dos decisiones legítimas es la más reciente.

Por eso la unidad operacional no es el paquete, sino la generación: estado anterior, RRsets deseados, aprobador, momento, clave, solicitud y relación de sustitución. Antes de reintentar, el controlador consulta el padre. Si el estado público ya coincide, la respuesta perdida no justifica una nueva mutación.

Aceptar no es publicar

La semántica de NOERROR es deliberadamente limitada. Significa que el receptor recibió y aceptó la actualización; el cambio debería publicarse en el padre en algún momento futuro. La frase no afirma que todos los servidores autoritativos lo sirvan cuando llega la respuesta.

Entre ambos puntos puede existir una base de aprovisionamiento, una API, un generador de zona, una carga en el primario y una transferencia a secundarios. Cada componente puede tener cola, fallo, reversión o versión propia. Reducirlos a un código de respuesta hace imposible localizar el tramo que no avanzó.

El padre puede aceptar una decisión correcta y tardar en exponerla. También puede publicar en el primario mientras un secundario conserva la generación anterior. Una consulta a un resolver recursivo añade la caché: incluso después de converger la autoridad, la respuesta anterior puede seguir siendo válida hasta su TTL.

El recibo de publicación debe nombrar servidor autoritativo, dirección, hora, RRset, TTL, estado DNSSEC y alguna evidencia de generación. Varias observaciones permiten describir convergencia o mezcla. Ninguna consulta aislada autoriza una afirmación sobre todos los cachés de Internet.

La firma empieza la autorización, no la termina

El receptor comprueba SIG(0), pero primero debe saber por qué confía en esa clave. Una actualización de arranque auto-firmada demuestra posesión de la clave privada propuesta. No demuestra autoridad sobre la delegación del hijo.

La clave pasa por estados separados: presentada, conocida, validada y de confianza. Puede validarse en el ápice de un hijo firmado, bajo el nombre de un servidor situado en una zona firmada o mediante un proceso manual. El método sin firma es más débil porque autentica al operador actual de los autoritativos, no necesariamente al registrante.

Durante un reemplazo, el receptor no debe borrar la clave fiable anterior hasta validar la nueva. De lo contrario, un candidato inválido podría destruir primero la autorización que aún funciona. La seguridad depende del orden de dos hechos, no sólo de que cada operación tenga una firma válida.

BADKEY indica que el receptor no dispone de la clave para verificar. Por sí solo no diferencia una clave conocida pendiente de confianza de una validación fallida. Los errores extendidos propuestos dan más detalle, pero el registro de arranque sigue siendo la fuente que explica por qué el sistema esperó, rechazó o volvió a iniciar.

El nombre limita el radio de acción

La regla normal exige que la clave SIG(0) fiable tenga exactamente el nombre del hijo cuya delegación cambia. Así, una clave comprometida de un hijo no debe alterar a otro. Un esquema alternativo, como una clave de registrador para muchos hijos, amplía la autoridad y obliga al receptor a autorizar cada operación por otros medios.

Tras verificar clave, firma y nombre, el padre aplica las mismas comprobaciones de corrección y política que usaría para CDS/CDNSKEY o CSYNC. El borrador no entrega a la criptografía la potestad de decidir cualquier NS, glue o DS.

DSYNC sólo permite localizar el receptor adecuado. Descubrimiento de endpoint, autenticación de endpoint, autorización del hijo, aceptación de política y mutación publicada son relaciones diferentes. Cada una requiere su propio dato de procedencia.

El registro mínimo incluye el DSYNC observado, su TTL, el destino resuelto, el transporte, el nombre del hijo, las diferencias de RRsets, la huella de clave, la ventana de firma, la versión de política y el resultado. “Llamada correcta” no preserva ninguna de esas fronteras.

La respuesta también necesita identidad

Que el hijo firme la solicitud no autentica automáticamente la respuesta. El receptor puede firmarla con su propia clave SIG(0), y el hijo debe validar esa clave mediante DNSSEC del padre o por arranque manual.

Sin esa confianza inversa, un atacante puede inyectar una respuesta que declare desconocida la clave del hijo y provocar un rearranque innecesario. No obtiene autoridad para cambiar la delegación, pero sí puede causar interrupción, rotación y carga operacional.

El controlador debe guardar si la respuesta iba firmada, con qué clave, cómo se confió en ella, qué RCODE y EDE contenía y a qué generación de solicitud respondía. Una respuesta auténtica prueba quién emitió el mensaje. Su semántica sigue sin extenderse hasta la publicación.

Esta simetría distribuye responsabilidades: el hijo custodia la clave de petición; el padre, la del receptor; una cadena DNSSEC o un procedimiento externo establece cada confianza. Un solo componente no puede declarar que todas las autoridades adyacentes avanzaron.

La retirada convierte una omisión en pérdida

Añadir una ruta suele fallar dejando la anterior disponible. Retirar un servidor o una DS antigua elimina capacidad de recuperación. Por eso el evento que autoriza la retirada no debe ser NOERROR, ni el cierre del job de aprovisionamiento.

La organización necesita una regla explícita: observar el conjunto previsto en las autoridades pertinentes, registrar su estabilidad, respetar la exposición del TTL anterior y comprobar el resultado desde resolvers representativos. Si el padre muestra generaciones mezcladas, la retirada se detiene.

El calendario comercial puede exigir apagar un proveedor antes que cierre el recibo técnico. Esa tensión no se resuelve escondiéndola en el controlador. Debe existir un responsable capaz de prolongar el solapamiento, aceptar el coste y documentar la excepción.

El rollback tampoco es “enviar otra vez lo anterior”. Necesita conocer qué generación llegó a qué servidores, qué cachés pueden conservarla y cuál es ahora la intención autorizada. Sin esa historia, una reversión puede crear una tercera mezcla.

El estado del borrador impide presentar ejemplos como realidad

En la fecha de corte, la revisión 02 estaba fechada el 17 de junio de 2026, actualizada en Datatracker el 25 de septiembre y con vencimiento el 19 de diciembre. Su estado de grupo era Waiting for WG Chair Go-Ahead Other - see Comment Log; el de IESG, I-D Exists.

Datatracker no mostraba estado RFC previsto, mientras la cabecera decía Standards Track. La discrepancia forma parte de la evidencia. El artículo no la corrige ni convierte los valores solicitados a IANA en asignaciones definitivas.

Las fuentes no prueban uso por ningún registro, registrador, TLD ni operador concreto. La apertura es un caso construido. El análisis puede derivar controles de la mecánica publicada, no atribuir una avería o éxito inexistente.

El resultado defendible es un grafo de recibos

El grafo enlaza intención, descubrimiento DSYNC, confianza en ambas claves, alcance del nombre, validación, política y respuesta. Después añade job de aprovisionamiento, generación del padre, carga de secundarios, observaciones autoritativas, horizonte de caché y prueba de aplicación.

Cada nodo conserva propietario, hora, entradas, salida y hash. Los estados desconocidos no se rellenan con éxito. Así se puede decidir si reintentar, esperar, frenar una retirada, conservar una clave o escalar al propietario correcto.

La conclusión útil no promete más de lo observado: SIG(0) puede autenticar una petición limitada y NOERROR puede confirmar que el receptor la aceptó. Sólo el padre público puede demostrar que la publicó.

Fuentes