Resumen

  • La revisión 02 propone que la zona hija envíe al padre cambios precisos de NS, glue y DS mediante el DNS UPDATE de RFC 2136, protegido con SIG(0) y dirigido a un receptor descubierto por DSYNC.
  • En el alta de la clave, la autofirma acredita posesión. El receptor debe conservarla como conocida hasta que una comprobación distinta permita confiar en la autoridad asociada.
  • En una sustitución, la clave anterior no puede eliminarse antes de validar la nueva. Después, NOERROR acredita aceptación del receptor, no publicación autoritativa ni resolución observada.

El borrador contiene una orden que ningún sistema debería ejecutar de izquierda a derecha sin estado intermedio: borrar todas las KEY anteriores del hijo y añadir una nueva KEY. El propio candidato firma la petición. Verificar esa firma es útil; demuestra que quien envió el mensaje controla la clave privada. Pero la clave recién fabricada no puede certificar por sí sola el mandato que pretende adquirir.

Por eso draft-ietf-dnsop-delegation-mgmt-via-ddns-02 distingue dos hechos. La clave queda conocida cuando el receptor puede identificarla y comprobar la autofirma. Solo queda confiable cuando supera el método de arranque anunciado por el padre. Durante el intervalo, la antigua clave confiable permanece. Si el sistema la borrara primero, un atacante no necesitaría superar la validación: bastaría con iniciar una sustitución falsa para retirar la autorización válida.

La discusión está viva. DNSOP abrió la última llamada el 20 de agosto y fijó el 7 de septiembre como cierre. Tres días antes, uno de los presidentes pidió apoyo positivo y comentarios constructivos porque el silencio no era suficiente. Geoff Huston respaldó la publicación y comparó favorablemente el push con el sondeo del padre. Johan Stenstam destacó la posibilidad de trabajar con hijos no firmados y describió su relación con una implementación. Michael Richardson dijo que podría programar a partir del texto, pero pidió claridad sobre KEY frente a DNSKEY, estados de clave, opciones criptográficas futuras y un diagrama de decisiones.

Son posiciones individuales; no acreditan consenso, aprobación del IETF ni resultados de producción.

La propuesta no crea un nuevo protocolo de edición. Usa DNS UPDATE, cuyas precondiciones y operaciones define RFC 2136, y firma la transacción con SIG(0) según RFC 2931 y RFC 3007. DSYNC, de RFC 9859, anuncia si el padre acepta el mecanismo y dónde encontrar su UPDATE Receiver. Ese receptor puede estar apartado del servidor primario y entregar una solicitud a un sistema de aprovisionamiento.

Esa arquitectura impide convertir autenticación en ejecución automática. El padre restringe qué RRsets pueden cambiar, exige por defecto una clave confiable cuyo nombre coincide exactamente con el hijo y conserva las comprobaciones de CDS/CDNSKEY y CSYNC. El paquete trae un cambio exacto; no trae el derecho unilateral a modificar el padre.

La confianza tampoco tiene una fuente única. Un hijo firmado puede publicar KEY en su apex para validación DNSSEC. Un hijo no firmado puede apoyarse en una zona firmada de uno de sus servidores de nombres, donde el operador publique la señal especial. El intercambio manual sigue siendo posible. Cada camino identifica una cadena de responsabilidad distinta.

Para un hijo completamente no firmado, el receptor compara el KEY presentado con observaciones autoritativas recogidas desde varios puntos, momentos y transportes. La diversidad reduce la posibilidad de un observador en ruta, pero no inventa un registrante. El borrador acota el resultado: autentica al operador actual de los servidores autoritativos, no al titular del dominio, y no puede superar la seguridad de esos servidores.

También importa el tipo. SIG(0) usa KEY, no DNSKEY. Una DNSKEY pertenece a la validación de firmas de zona; la KEY de esta propuesta autoriza una firma de transacción. Mezclarlas en inventarios o interfaces impide saber qué almacén, rotación o respuesta a compromiso protege cada función.

Los retornos del receptor son recibos parciales. NOERROR indica recepción y aceptación; el cambio debería aparecer más tarde en los datos del padre. REFUSED puede proceder de política, límite de tasa o mala configuración y un único rechazo no tiene por qué ser definitivo. BADKEY indica que falta la clave pública necesaria, aunque no distingue por sí solo todos los estados del arranque. Sin respuesta, el hijo no sabe si se perdió la petición o la contestación.

Una cadena de evidencia separaría descubrimiento DSYNC, hash del UPDATE y precondiciones, identidad de KEY, método de arranque, transición a conocida, transición a confiable, decisión y respuesta autenticada, transacción de aprovisionamiento, serial del padre, RRset publicado, vistas de resolutores tras los TTL y, por último, resultado del servicio. Reducirlo a «actualización exitosa» destruye la causalidad.

La doctrina de Heng Lu ayuda a nombrar el límite: un registro describe la realidad que observó, no recibe soberanía sobre la siguiente. La clave conocida es un hecho. La confianza es otro. La aceptación, la publicación y el uso son otros tantos. La automatización se vuelve defendible cuando conserva esas separaciones, no cuando las esconde detrás de una firma verde.

Fuentes