Resumen

  • Desde el 10 de septiembre de 2026, el resolutor 1.1.1.1 de Cloudflare podía validar ML-DSA-44 para zonas de prueba. En RIPE 93, Joe Abley presentó una prueba DNSSEC ejecutada en el navegador.
  • Entre resolutores validadores, la doble firma frente al control clásico mostró +1 ms en la mediana y +1.405 ms en p99. Las diapositivas calificaron el resultado agregado como net breakage del 6,0%; el ensayo temprano y ruidoso no estableció una tasa de fallos de toda la población.

La mediana vende; la cola despierta a guardia

Un milisegundo más en la mediana es el número que luciría en grande en un anuncio de actualización. Joe Abley llevó a RIPE 93 la línea que ese anuncio pondría en letra pequeña: en p99, el camino con doble firma tardó 1.405 milisegundos más que el control clásico. Ese percentil mira el extremo lento, justo donde un promedio bien peinado deja a algunos usuarios fuera de cuadro.

La gráfica de las diapositivas originales de RIPE 93 compara el tiempo transcurrido de la doble firma menos el control con algoritmo 13 en resolutores validadores. Las diferencias fueron +1 ms en la mediana, +147 ms en p90, +618 ms en p95 y +1.405 ms en p99. Son tiempos del desafío en el navegador, no una medición aislada del trabajo criptográfico. Abley mostró también una referencia no validadora: firma clásica 13 rota frente al control, con 0, +73, +215 y +1.132 ms en esos percentiles.

El experimento reunió unos 140.000 puntos de datos al mostrar el desafío a uno de cada 1.000 usuarios. Cuatro solicitudes HTTPS paralelas usaban nombres DNS servidos por Cloudflare: control con algoritmo 13, firma 13 rota a propósito, ruta ML-DSA-44 con algoritmo 18 y nombre con ambas firmas. La diapositiva 19 llamó «net breakage» del 6,0% al resultado agregado de resolutores validadores. Abley señaló un aumento significativo de fallos en alrededor de 20 sistemas autónomos; en la mayoría de los AS observados no hubo diferencia. La presentación no atribuye una causa a cada fallo.

La firma nueva puede cerrar la salida de emergencia

La prueba fue posible porque 1.1.1.1 tenía validación ML-DSA-44 activa para todos sus clientes desde el 10 de septiembre, pero en zonas de prueba. Eso era capacidad de validación, no el lanzamiento comercial de firmas poscuánticas. El registro de IANA identifica el algoritmo 18 como ML-DSA-44 y marca MAY tanto para firmar como para validar. El algoritmo 13 —ECDSA P-256 con SHA-256— figura como RECOMMENDED.

En el DNSSEC habitual, un resolutor puede aceptar un conjunto de registros si valida cualquiera de las firmas RRSIG que lo cubren. La RFC 6840 dice que debería aceptar toda firma válida y declarar bogus el conjunto solo si fallan todas. La RFC 4035 deja los conflictos a la política de seguridad local. La regla poscuántica más estricta de Cloudflare cierra esa salida: si hay una firma de algoritmo 18, tiene que validar. Una firma 13 correcta no rescata una ML-DSA-44 rota. La intención es impedir que una actualización cuántica termine convertida en una rebaja silenciosa a la firma clásica.

La protección convierte la firma nueva en condición de disponibilidad. Si está mal formada, puede perderse una respuesta que la firma clásica sí habría autenticado. Esa regla pertenece a la política local del resolutor; no cambia el protocolo DNSSEC base.

El navegador no era un laboratorio limpio

Abley describió los resultados como muy iniciales y ruidosos. Se reutilizaron los mismos nombres DNS, así que la caché podía alterar la comparación; la prueba no la evadía. Las redirecciones HTTPS añadían tiempo. Quienes completaban rápido podían salir antes de que acabara la medición, y el límite de dos segundos cortaba las solicitudes lentas. El navegador y la red doméstica metían más ruido. Las diapositivas apuntan a una señal que investigar, no a una causa probada para cada fallo.

La decisión de despliegue seguía abierta. Cloudflare aún experimentaba con la firma en línea ML-DSA-44 y no había fijado una fecha para ofrecerla a clientes. Las exigencias de cumplimiento podían crear demanda de una opción voluntaria; activar doble firma por defecto requería mucha confianza en que no rompería el servicio. El borrador individual de Joe Abley propone una señal Extended DNS Error para que el cliente distinga una política local estricta de una respuesta negativa sin explicación.

Una repetición aleatoria, con nombres que eviten caché y trazas del resolutor, cambiaría el juicio de despliegue: separaría los errores de validación DNS de las redirecciones, salidas del navegador y tiempos agotados. Por ahora, el resultado dibuja el problema: centro casi plano, cola inclinada y una política que exige que la firma poscuántica cuente.

Fuentes