Resumen

  • La revisión 02 de ML-DSA-MTL para DNSSEC permite que una firma ML-DSA sobre una escalera autentique muchos RRsets mediante pruebas Merkle individuales.
  • El ahorro criptográfico depende de un conjunto de nodos que evoluciona; una respuesta válida no demuestra que ese estado pueda continuar de forma coherente tras una actualización, transferencia o recuperación.

draft-kaizer-dnsop-ml-dsa-mtl-dnssec-02 se publicó el 28 de septiembre de 2026. Cambió la intención del documento a Standards Track y añadió la propuesta de un registro IANA para tipos MTL. Sigue siendo un Internet-Draft individual: no es adopción del grupo DNSOP, consenso del IETF ni RFC. El número de algoritmo continúa como TBD. Las implementaciones de prueba citadas en LDNS, NSD y Unbound no son un censo de despliegue, y el propio texto advierte que la lista no ha sido verificada ni implica respaldo del IETF.

La presión que motiva el diseño no es retórica. ML-DSA ofrece una firma poscuántica estandarizada por NIST, pero una firma completa es grande para el perfil operativo de DNS. Repetirla en cada RRSIG aumenta almacenamiento, caché y tráfico. La escalera Merkle intenta distribuir ese coste entre mensajes.

El DNSKEY publica la clave ML-DSA. Cada mensaje DNSSEC se combina con un randomizer y se convierte en una hoja. Las hojas reciben índices consecutivos desde cero y se incorporan a un conjunto de nodos con un identificador de serie, SID. Sus rungs autentican tramos del conjunto. En vez de firmar individualmente cada RRset, ML-DSA firma los flags, el SID, el número de rungs y sus datos.

La RRSIG completa lleva además el índice de hoja y los hashes hermanos que forman el camino de autenticación. El resolver valida la firma de la escalera, recalcula la hoja a partir del RRset y sigue el camino hasta un rung compatible. Después aún debe completar la validación DNSSEC convencional. Una sola respuesta puede contener lo necesario; una sola firma pesada puede cubrir muchas hojas.

La palabra decisiva es «conjunto». La prueba no nace de un RRset aislado. Depende de la serie en la que fue insertado, de su posición, del randomizer y de la versión de la escalera. Cuando llegan nuevas hojas, cambian los rungs y puede ser necesario recalcular el camino de un mensaje antiguo contra la escalera actual.

Eso convierte la programación del lote en control de servicio. Un lote mayor mejora la amortización, pero puede retrasar la firma de cambios recientes. Uno menor reduce la espera, aunque exige más operaciones ML-DSA y más uso del HSM. El borrador deja correctamente la elección al operador. La producción necesita además un objetivo: tiempo máximo hasta una prueba disponible, regla de promoción y comportamiento si un nodo de firma se queda atrás.

El estado que sostiene esa decisión no está especificado como artefacto transferible. La revisión actual no dice qué debe viajar con AXFR o IXFR, qué debe contener una copia de seguridad, cómo varios firmantes asignan índices sin colisión, ni cómo se detecta una restauración a una escalera antigua. Tampoco afirma que la recuperación sea imposible. Deja abierta la operación.

Ese matiz importa. Un implementador quizá pueda reconstruir el conjunto desde material conservado; otro puede replicar una base propia; un tercero puede iniciar un SID nuevo tras la conmutación. Son estrategias distintas. La firma válida de ayer no prueba cuál aplica mañana ni si la transición será entendida por todos los servidores y resolvers.

El documento sí fija una separación fuerte: no se puede reutilizar el mismo SID en varias instancias MTL. Nombra el conjunto KSK y el conjunto ZSK como ejemplo. Por tanto, custodiar la clave privada sin custodiar la identidad de cada serie es insuficiente. También hay que evitar que un respaldo antiguo vuelva a ocupar un índice con datos diferentes o que dos firmantes crean ser dueños del siguiente.

La firma online no borra la decisión. El borrador sugiere como ejemplo crear un conjunto nuevo por respuesta dinámica. Eso puede evitar una historia larga compartida, pero limita la amortización al contenido de la consulta. El rendimiento debe medirse por arquitectura, no inferirse de la palabra MTL.

En el transporte, la revisión 01 eliminó la opción EDNS(0) de la versión inicial y convirtió la respuesta MTL completa en el único tipo para cada RRset. La revisión 02 dice que siempre supera DNS sobre UDP, prevé más TCP y recomienda consultar directamente por TCP cuando se quiera evitar truncamiento y reintento.

TCP resuelve el canal, no el significado. Un flujo TCP íntegro no garantiza que el clúster autoritativo comparta el mismo estado. Una escalera válida no garantiza que el resolver acepte el algoritmo. Un algoritmo aceptado no garantiza una cadena desde el DS hasta el ancla de confianza. Y una respuesta autenticada no demuestra que la aplicación haya obtenido el resultado esperado.

El mecanismo SigTag ya publicado por BTW se ocupa de otra capa: qué escalera dice tener un cliente, cuándo el servidor puede omitirla, qué privacidad expone y cómo volver a una respuesta completa. Esta pieza no repite esa tesis. Examina el requisito previo del lado del firmante: disponer de una historia coherente antes de ofrecerla para reutilización.

La lectura desde el running code es sencilla. El registro propuesto y la especificación de bits permiten experimentar. Los repositorios citados muestran que alguien ejecutó el diseño. La realidad operativa requiere todavía conmutación, restauración, actualización, separación de roles, transferencia y capacidad TCP demostradas por actores independientes. Publicar una estructura no transporta automáticamente su estado.

El recibo mínimo de una escalera debería identificar SID, rol KSK/ZSK, intervalo de índices, rungs, serie SOA, firmante, versión, hora y predecesor. La prueba de aceptación debería restaurar un firmante retrasado, detectar el rollback y verificar desde un resolver real si la serie continúa o cambia de forma declarada. Así se mide la memoria del servicio, no solo la validez de una muestra.

Fuentes