Resumen

  • SigTag usa una opción EDNS(0) para que el cliente enumere hasta ocho ladders firmadas que cree conocer; una coincidencia permite responder con una firma condensada.
  • El identificador de 32 octetos no acredita posesión, vigencia, vínculo con el firmante, validación de la ladder ni éxito DNSSEC.
  • La adopción necesita recuperación mediante firma completa, telemetría por etapa y una decisión explícita sobre la información histórica que revela cada tag.

El tamaño se ahorra una sola vez

La firma completa de ML-DSA-MTL incluye una prueba Merkle condensada y una signed ladder con la firma ML-DSA subyacente. Una ladder puede autenticar muchos RRset, por lo que reparte coste criptográfico, pero el borrador base reconoce que una respuesta completa rebasa DNS sobre UDP.

SigTag calcula SHAKE128(SIGNED_LADDER, 256) y deja que el resolver envíe ese resultado en EDNS(0). Si el servidor conserva la ladder correspondiente, puede responder con MTL-Type 0x02 y omitirla. Si no hay coincidencia o el servidor ya no la posee, debe devolver la firma completa.

La ladder no pierde relevancia al desaparecer del paquete. El resolver tiene que recuperarla del caché correcto, comprobar su firma con la DNSKEY adecuada, verificar el camino de inclusión del RRset y completar la cadena DNSSEC. La coincidencia decide una optimización de formato; no emite el veredicto secure.

Un hash correcto puede vivir en el contexto equivocado

El borrador base exige asociar la ladder almacenada al nombre del firmante porque otro firmante podría usar el mismo SID. Por tanto, SID o SigTag no son claves globales de autoridad. Un caché que no incluya firmante y contexto de clave puede encontrar el objeto matemáticamente correcto y aplicarlo al dominio incorrecto.

Además, la consulta solo expresa lo que el cliente cree saber. Una entrada puede ser expulsada, corromperse o quedar desfasada durante un rollover. El servidor mantiene otra copia de estado, y el camino condensado recibido debe corresponder a ambas. Conviene conservar tres recibos, no un único indicador de hit.

Cuando el cliente no conoce tags, puede enviar la opción vacía. El eco vacío del servidor señala soporte y habilita la deduplicación dentro de una respuesta: la primera RRSIG lleva la ladder y las demás pueden ser condensadas. Ese eco no prueba que el cliente validó nada.

El fallback define si el ahorro es tolerable

Ante una respuesta inválida, la revisión 00 permite repetir con una opción vacía, quitar SigTag para exigir firmas completas o consultar otro servidor. Entre los fallos citados están una firma condensada no coincidente y la ausencia de payload.

Estas rutas son parte del mecanismo operativo. Sin ellas, una optimización que depende del caché crea una nueva causa de SERVFAIL. TCP tampoco es una absolución: puede evitar una secuencia de truncación, pero entrega, verificación y uso por la aplicación siguen siendo hechos distintos. Los operadores deben observar tamaño, UDP/TCP, reintento, cambio de upstream, resultado DNSSEC y consumo final por separado.

La lista de tags es también una pista de navegación

Un tag no vacío informa a la autoridad de que el cliente recibió una ladder determinada. El borrador advierte que esto puede revelar consultas previas o permitir seguimiento si la autoridad entrega ladders individualizadas. Enviar siempre la opción vacía mantiene la deduplicación intrarrespuesta sin divulgar caché conocido; borrar ese estado al cambiar de interfaz o dirección limita su persistencia.

La eficiencia y la privacidad tiran en direcciones distintas. La autoridad no adquiere permiso para perfilar al resolver, ni el fabricante del software debe resolver el conflicto sin visibilidad. La elección corresponde a quien opera el sistema y asume sus efectos.

Publicación, registro y realidad

La revisión 00 fue publicada el 28 de septiembre de 2026. El código EDNS y el nuevo MTL-Type siguen como TBD. El texto menciona implementaciones de prueba en LDNS, NSD y Unbound, y al mismo tiempo aclara que la información procede de contribuyentes, no fue verificada y no implica respaldo de IETF.

IANA puede fijar un significado común. Un repositorio puede mostrar código. Solo pruebas reproducibles con versiones, trazas, fallos y resultados de validación muestran si el sistema funciona bajo carga y rollover reales.

Fuentes