Cloudflare ha activado en su servicio DNS público 1.1.1.1 la validación de firmas DNSSEC creadas con ML-DSA-44, uno de los algoritmos de firma poscuántica estandarizados por el Instituto Nacional de Estándares y Tecnología de Estados Unidos (NIST). El cambio no cifra las consultas DNS ni convierte Internet en resistente a los ordenadores cuánticos, pero introduce una pieza necesaria para que DNSSEC pueda seguir verificando la autenticidad de los registros cuando los actuales algoritmos de clave pública dejen de considerarse seguros.
Las claves del DNS poscuántico de Cloudflare en 30 segundos
- El resolver 1.1.1.1 ya puede validar firmas DNSSEC creadas con ML-DSA-44.
- ML-DSA-44 está diseñado para resistir los ataques conocidos de futuros ordenadores cuánticos suficientemente potentes.
- Una firma ocupa 2.420 bytes, frente a los 64 bytes de ECDSA P-256.
- Ese tamaño supera por sí solo los límites UDP habituales de DNS y puede obligar a recurrir a TCP.
- Todavía no existe una cadena DNSSEC poscuántica completa desde la raíz hasta los dominios.
La novedad tiene además un matiz importante. Cloudflare no está utilizando 1.1.1.1 para firmar las respuestas DNS que entrega a cada usuario, como podría interpretarse a partir de una explicación simplificada del anuncio. El resolver recursivo ha aprendido a validar las firmas ML-DSA-44 publicadas por zonas DNS que utilicen este nuevo algoritmo.
Es una diferencia técnica importante.
En DNSSEC, las firmas pertenecen a los registros de la zona y se generan en el lado autoritativo. El resolver comprueba después la cadena criptográfica para determinar si la respuesta recibida es auténtica y no ha sido modificada.
Cloudflare ha comenzado por esa segunda parte: hacer que 1.1.1.1 pueda validar el nuevo algoritmo. La compañía prevé añadir posteriormente soporte de firma ML-DSA-44 a Cloudflare Authoritative DNS y soporte para los correspondientes registros DS en Cloudflare Registrar.
DNSSEC no cifra el DNS: demuestra que la respuesta es auténtica
El DNS tradicional nació sin mecanismos criptográficos integrados para autenticar las respuestas.
Eso creó ataques conocidos desde hace décadas, como el DNS spoofing y el cache poisoning, donde un atacante intenta introducir una respuesta falsa para que un dominio legítimo termine resolviendo hacia una dirección IP diferente.
DNS Security Extensions (DNSSEC) aborda ese problema mediante firmas digitales.
Una zona firmada publica registros DNSKEY que contienen sus claves públicas y registros RRSIG con las firmas correspondientes. Un resolver que valida DNSSEC puede seguir una cadena de confianza desde el dominio consultado hasta sus zonas superiores.
El objetivo es responder a una pregunta: ¿los datos recibidos son realmente los que publicó el responsable de esta zona DNS?
DNSSEC no responde a otra pregunta diferente: ¿puede alguien observar qué dominio está consultando el usuario?
Para proteger la confidencialidad existen mecanismos como DNS over HTTPS (DoH) y DNS over TLS (DoT), que cifran la comunicación entre cliente y resolver.
Las funciones son distintas:
| Tecnología | Qué aporta |
|---|---|
| DNS tradicional | Resolución de nombres |
| DNSSEC | Autenticidad e integridad |
| DNS over HTTPS | Cifrado entre cliente y resolver mediante HTTPS |
| DNS over TLS | Cifrado entre cliente y resolver mediante TLS |
| DNSSEC + ML-DSA-44 | Autenticidad preparada frente a futuros ataques cuánticos |
Por eso afirmar simplemente que «DNS utiliza UDP y no tiene criptografía» se queda corto para describir el DNS actual. DNS puede funcionar mediante UDP y TCP, además de transportes cifrados como DoH y DoT. DNSSEC, por su parte, lleva años proporcionando autenticación criptográfica.
Lo nuevo está en qué criptografía utiliza DNSSEC para hacerlo.
El problema cuántico de RSA y ECDSA
Las implementaciones actuales de DNSSEC pueden utilizar distintos algoritmos. Entre los desplegados aparecen RSA y ECDSA.
Su seguridad depende de problemas matemáticos que son extremadamente costosos de resolver utilizando ordenadores clásicos suficientemente grandes.
El problema es que un ordenador cuántico a gran escala capaz de ejecutar eficazmente el algoritmo de Shor cambiaría esa situación.
Una máquina de esas características podría comprometer sistemas basados en factorización de enteros o logaritmos discretos, lo que afecta a RSA y a la criptografía de curva elíptica.
Ese ordenador cuántico criptográficamente relevante no existe actualmente.
La migración se está preparando antes de que exista porque cambiar algoritmos desplegados por toda Internet lleva años.
Cloudflare recuerda que DNSSEC añade una dificultad particular. La cadena de confianza atraviesa varias organizaciones y niveles:
Raíz DNS
│
▼
TLD (.com, .es, .org...)
│
▼
Dominio
│
▼
Registros DNS firmados
│
▼
Resolver validadorPara conseguir una cadena realmente poscuántica no basta con que un dominio utilice ML-DSA-44.
Su zona superior debe poder publicar la información necesaria, los registradores deben aceptarla, los registros deben soportarla, los resolvers tienen que verificarla y, finalmente, la propia raíz DNS tendrá que disponer de una cadena de confianza poscuántica.
Cloudflare todavía no está anunciando ese escenario.
1.1.1.1 representa uno de los primeros pasos del camino.
ML-DSA-44 trae un problema inesperado: las firmas son enormes
La criptografía poscuántica tiene una contrapartida especialmente relevante para DNS: el tamaño.
Cloudflare compara tres configuraciones:
| Algoritmo | Clave pública | Firma |
|---|---|---|
| RSA-2048/SHA-256 | 260 bytes | 256 bytes |
| ECDSA P-256 | 64 bytes | 64 bytes |
| ML-DSA-44 | 1.312 bytes | 2.420 bytes |
Una firma ML-DSA-44 es casi 38 veces mayor que una firma ECDSA P-256.
El ejemplo proporcionado por el investigador Bill Buchanan permite observarlo directamente con dig. Al consultar el dominio de pruebas valid.mldsa44.dnstest.dev, el registro DNSKEY contiene una clave pública ML-DSA-44 de 1.312 bytes.
Una consulta DNSSEC al resolver de Cloudflare puede realizarse con:
dig @1.1.1.1 valid.mldsa44.dnstest.dev +dnssecLa respuesta incluye un RRSIG identificado con el algoritmo DNSSEC 18, asignado a ML-DSA-44.
Y ahí aparece el problema operativo.
DNS utilizó históricamente paquetes UDP de hasta 512 bytes. EDNS(0) permitió posteriormente negociar respuestas mayores, pero muchos sistemas utilizan un tamaño conservador de 1.232 bytes de carga UDP para evitar problemas de fragmentación relacionados con la MTU mínima de IPv6.
RFC 9715 recomienda actualmente no superar 1.400 bytes para DNS sobre UDP.
Una sola firma ML-DSA-44 ocupa 2.420 bytes.
No cabe.
Una consulta que antes viajaba por UDP puede terminar en TCP
La consecuencia puede verse directamente utilizando dig.
En la prueba recogida por Buchanan aparece:
;; Truncated, retrying in TCP mode.El servidor devuelve una respuesta truncada y el resolver vuelve a intentarlo utilizando TCP.
Esto no supone que DNS sobre TCP sea algo excepcional o incorrecto. Forma parte del protocolo desde hace mucho tiempo.
Pero sí cambia las características operativas cuando empieza a ocurrir con más frecuencia.
Con una firma poscuántica pueden aumentar:
- el tráfico generado por determinadas resoluciones;
- el número de consultas que requieren TCP;
- la memoria utilizada para caché;
- el coste computacional de las verificaciones;
- y la presión sobre servidores autoritativos y resolvers.
Las respuestas DNSKEY pueden crecer todavía más porque durante una migración no será posible eliminar inmediatamente las claves tradicionales.
Una zona podría necesitar publicar simultáneamente:
ECDSA DNSKEY
ML-DSA-44 DNSKEY
ECDSA RRSIG
ML-DSA-44 RRSIGEso mantiene la compatibilidad con resolvers antiguos, pero multiplica el tamaño de determinadas respuestas.
Los key rollovers, donde durante un periodo conviven varias claves para permitir su sustitución segura, pueden añadir todavía más información.
Mantener ECDSA también abre la puerta a un downgrade
La convivencia entre criptografía clásica y poscuántica crea otro problema menos visible.
Supongamos que una zona publica tanto ECDSA como ML-DSA-44.
Un resolver antiguo utiliza ECDSA porque no entiende el nuevo algoritmo. Uno moderno podría validar ML-DSA-44.
Durante años ambos sistemas tendrán que coexistir.
Pero si en el futuro ECDSA pudiera romperse mediante un ordenador cuántico, un atacante podría intentar eliminar de la respuesta los elementos poscuánticos y presentar únicamente una cadena ECDSA falsificada.
El resolver moderno podría interpretar que simplemente está ante una zona que todavía utiliza el algoritmo antiguo.
Es un ataque de downgrade.
Cloudflare ha introducido una política específica en 1.1.1.1 para evitarlo.
Cuando un conjunto autenticado de registros DS indica la presencia de un algoritmo poscuántico soportado, el resolver exige que exista al menos una ruta válida de verificación poscuántica. Una firma convencional correcta deja de ser suficiente.
La política es deliberadamente más estricta que el comportamiento tradicional de DNSSEC.
El problema reaparece, sin embargo, si algún nivel superior de la cadena todavía depende exclusivamente de criptografía clásica. De ahí que la migración completa tenga que alcanzar eventualmente la raíz DNS.
ML-DSA-44 ya tiene asignado el algoritmo DNSSEC 18
ML-DSA deriva de la familia de algoritmos conocida anteriormente como CRYSTALS-Dilithium y fue estandarizado por NIST como parte de su transición hacia criptografía poscuántica.
Para utilizarlo dentro de DNSSEC hacía falta además definir cómo representar sus claves y firmas en los registros DNS.
ML-DSA-44 dispone ahora del número de algoritmo DNSSEC 18, uno de los requisitos para comenzar su despliegue interoperable.
Al mismo tiempo continúa el trabajo dentro de la Internet Engineering Task Force (IETF). Existen borradores sobre el uso de ML-DSA en DNSSEC y propuestas como ML-DSA-MTL, que combina firmas basadas en retículas con estructuras Merkle para estudiar alternativas adecuadas a las características particulares del DNS.
Estos documentos siguen siendo trabajos en curso y no deben interpretarse como estándares definitivos.
Los usuarios de 1.1.1.1 no tienen que cambiar nada
Para quien ya utiliza 1.1.1.1 como resolver, el cambio es transparente.
Cuando una zona publique los registros necesarios, Cloudflare podrá validar ML-DSA-44. Las zonas DNSSEC convencionales continuarán funcionando como hasta ahora.
La compañía utilizará además dominios de prueba para medir qué ocurre cuando estas respuestas mucho mayores atraviesan redes, routers, firewalls y resolvers reales.
Ese trabajo puede ser tan importante como la propia criptografía.
La transición hacia algoritmos poscuánticos en TLS ya demostró que aumentar el tamaño de determinados mensajes puede revelar límites y suposiciones escondidas en software y equipos de red. DNS tiene todavía más sensibilidad al tamaño porque gran parte de su tráfico sigue utilizando UDP.
Cloudflare estima que aproximadamente el 85 % de las consultas que llegan a 1.1.1.1 utilizan UDP. La cifra se refiere al transporte entre clientes y el servicio de resolución de Cloudflare, no necesariamente al utilizado después entre el resolver y los servidores autoritativos.
La compañía ha fijado 2029 como objetivo para alcanzar protección poscuántica en sus sistemas. DNSSEC es una de las piezas que todavía deben recorrer ese camino.
La novedad de 1.1.1.1 tampoco significa que exista una amenaza cuántica inmediata contra DNS. A diferencia del tráfico cifrado que puede almacenarse hoy para intentar descifrarlo años después, DNSSEC protege autenticidad, no confidencialidad, por lo que no presenta exactamente el mismo problema de harvest now, decrypt later.
Hay tiempo, pero la infraestructura que debe cambiar es enorme.
Y el experimento con ML-DSA-44 ya muestra uno de los retos prácticos: sustituir una firma ECDSA de 64 bytes por otra preparada para un futuro poscuántico significa pasar a 2.420 bytes.
En criptografía el algoritmo puede cambiar sobre el papel en unas líneas. En Internet, esos 2.356 bytes adicionales tienen que atravesar millones de servidores, resolvers, firewalls y dispositivos de red sin romper nada.
Fuentes:
- Cloudflare, 1.1.1.1 now supports post-quantum DNSSEC, all 2,420 bytes of it, 10/09/2026.
