Cloudflare 1.1.1.1 valida firmas post-cuánticas de 2.420 bytes

Cloudflare activa validación de firmas post-cuánticas en 1.1.1.1

El resolver DNS público 1.1.1.1 de Cloudflare ya valida por defecto firmas DNSSEC creadas con ML-DSA-44, el algoritmo de firma post-cuántica estandarizado por el NIST como FIPS 204. Cada firma pesa 2.420 bytes, casi 38 veces más que las 64 bytes de una firma ECDSA P-256, el algoritmo que protege hoy la mayor parte de las zonas firmadas. Es la primera vez que un resolver a escala de Internet procesa firmas de ese tamaño de forma rutinaria, y Cloudflare lo describe como un paso deliberado para que la cadena de confianza del DNS sobreviva al momento en que un computador cuántico rompa la criptografía actual.

El movimiento llega después de años de trabajo de la compañía en el frente de TLS: según SDxCentral, el tráfico de origen protegido con la suite híbrida X25519MLKEM768 pasó de unos 25.000 millones a 45.000 millones de conexiones diarias tras desplegar Automatic Key Exchange, y la proporción de handshakes TLS 1.3 post-cuánticos completados en un solo round trip saltó de 0% a 99,2%. La experiencia con TLS dejó dos lecciones que ahora se aplican a DNSSEC: (1) las pilas de red asumen paquetes pequeños, y exponerlas a mensajes grandes tarde siempre expone bugs; (2) la adopción de cliente tarda años, por lo que el ensayo a gran escala debe empezar antes de que la amenaza sea inmediata.

Por qué DNSSEC es el siguiente eslabón crítico

El DNS no autentica respuestas por defecto: si un atacante puede falsificar un paquete, redirige a la víctima a donde quiera. DNSSEC resuelve eso con una cadena de firmas desde la zona raíz hasta el dominio final, y un resolver que valida —como 1.1.1.1— recorre esa cadena antes de devolver la respuesta. El problema es que los algoritmos en uso hoy (RSA, ECDSA) se basan en problemas que un computador cuántico suficientemente grande podría resolver. Cloudflare estima que en 2030 ya podría existir hardware capaz de recuperar la clave privada de la raíz, y un atacante con esa clave podría firmar cualquier delegación del árbol: break once, forge everywhere.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

La buena noticia es que DNSSEC no sufre el clásico harvest now, decrypt later del cifrado, porque su objetivo es autenticidad, no confidencialidad. La mala es que migrar exige coordinación entre servidores autoritativos, registros, registradores y resolvers, y la transición debe llegar hasta la raíz —un solo eslabón sin protección post-cuántica sigue siendo un punto de downgrade.

El problema de los 2.420 bytes

DNSSEC fue diseñado para mensajes pequeños. La cabecera de UDP original limitaba las respuestas a 512 bytes; EDNS(0) lo relajó, y hoy la mayoría de las implementaciones usan un tope conservador de 1.232 bytes para caber en la MTU mínima de IPv6. RFC 9715 recomienda un máximo de 1.400 bytes. Una firma de 2.420 bytes excede ese presupuesto antes de contar el RRset firmado, los nombres de dominio y las cabeceras. Enviar la respuesta como UDP fragmentado es poco fiable, así que el servidor autoritativo debe responder con el bit TC activo (truncated) y forzar al resolver a reintentar sobre TCP.

Según datos de Cloudflare Radar citados en el anuncio, alrededor del 85% de las consultas a 1.1.1.1 llegan por UDP, y la plataforma Big Pineapple que la soporta —también usada por Gateway DNS— recibe en conjunto cerca del 60% de su tráfico por UDP. El 40% restante ya viaja por TCP, DoT o DoH, así que el cambio no introduce una dependencia nueva; sí añade retries TCP adicionales en la comunicación con autoritativos que publiquen ML-DSA-44, un coste que Cloudflare quiere medir en producción antes de que la adopción sea masiva.

El downgrade y la solución de Cloudflare

Publicar firmas convencionales y post-cuánticas a la vez no basta. RFC 6840 dice que los validadores deberían aceptar cualquier camino válido, lo que crea un downgrade path: si un atacante falsifica solo una respuesta ECDSA, un resolver que soporta ML-DSA-44 la aceptará igual. Cloudflare resuelve el problema con una política local más estricta: si el DS RRset firmado por la zona padre contiene un registro para un algoritmo post-cuántico soportado, el resolver exige al menos un camino post-cuántico válido. Si no existe, la validación falla. Es un comportamiento que RFC 4035 permite como política local del resolver, y es la primera vez que un resolver público lo aplica por defecto.

La elección de ML-DSA-44 no es casual. NIST ya tenía tres estándares post-cuánticos publicados en agosto de 2024 —FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) y FIPS 205 (SLH-DSA)— y la IANA asignó a ML-DSA-44 el número de algoritmo DNSSEC 18. La familia basada en lattice es la recomendación principal de NIST para firmas de uso general, y ya cuenta con implementaciones en las librerías criptográficas habituales.

Por qué importa más allá del DNS

La transición DNSSEC es solo una cara de una mudanza cripto que ya tiene fecha. En junio de 2026, la Office of Management and Budget de EE.UU. emitió el memorándum M-26-15, que obliga a todas las agencias federales a entregar un plan de migración a criptografía post-cuántica antes del 22 de octubre de 2026 —apenas seis semanas después del anuncio de Cloudflare—. Una orden ejecutiva firmada el 22 de junio de 2026 fija plazos de cumplimiento de 2030 y 2031 para sistemas civiles de alto valor, y la directiva CNSA 2.0 de la NSA exige criptografía post-cuántica en nuevos sistemas de seguridad nacional desde 2027.

El resto del ecosistema también se mueve. Cloudflare se convirtió en febrero de 2026 en el primer SASE del mercado con soporte post-cuántico completo, y según su Year in Review 2025, el 52% del tráfico web humano ya viaja protegido por criptografía post-cuántica, en buena parte tras una actualización de iOS que activó TLS híbrido quantum-safe por defecto. En blockchain, Fireblocks anunció en septiembre de 2026 una implementación EVM de ML-DSA-44 que reduce el coste de verificación de 8,09 millones a 1,23 millones de gas —una mejora de 6,6 veces— según CryptoBriefing, lo que hace viable la verificación on-chain sin esperar al precompile NTT del pendiente EIP-7885.

Qué significa esto para tu startup

La transición post-cuántica ya no es un ejercicio teórico: está en los contratos federales, en los roadmaps de productos y, ahora, en el resolver DNS más usado del mundo. Para una startup, eso cambia tres cosas prácticas.

Acciones concretas que puedes tomar esta semana:

Audita dónde firmas con criptografía asimétrica. Haz inventario de dónde usas RSA o ECDSA: TLS en tu API, JWTs, firmas de artefactos, DNSSEC si tienes zona firmada. El memorándum M-26-15 exige un inventario criptográfico explícito a las agencias; replica ese ejercicio aunque no vendas al gobierno federal, porque clientes enterprise grandes empezarán a pedirlo.
Habilita TLS híbrido post-cuántico en tu edge. Si usas Cloudflare, comprueba que el Automatic Key Exchange está activo para tu dominio; según los datos de SDxCentral, alrededor del 12% de los orígenes ya soportan X25519MLKEM768, y enviar el ClientHello post-cuántico en el primer intento te ahorra más de 150 ms en la latencia del percentil 90 del handshake.
Planifica el coste de mensajes grandes en tu infraestructura. Si dependes de DNS, MQTT, firma de firmware o cualquier protocolo con límites de paquete pequeños, asume que las firmas van a multiplicarse por 25-40x en tamaño. Cloudflare lo está testeando con DNSSEC; tu sistema embebido o tu pipeline de OTA puede tener la misma sorpresa en dos años.

Si quieres ver la firma de 2.420 bytes en vivo, Cloudflare habilitó la zona dnstest.dev: ejecuta dig @1.1.1.1 valid.mldsa44.dnstest.dev +dnssec y observa el aviso de truncado y el retry sobre TCP. Para saber si tu propio resolver ya valida ML-DSA-44, está disponible la herramienta comunitaria Is your DNS resolver post-quantum ready?.