Cloudflare anunció el 10 de septiembre de 2026 que 1.1.1.1 ya valida DNSSEC poscuántico con ML-DSA-44. Es un avance en la autenticación del DNS, no una actualización que convierta automáticamente todos los dominios en resistentes a computadoras cuánticas.
La distinción importa si administras una web, una API o un VPS: resolver una dirección, autenticar la respuesta y cifrar la conexión son tareas diferentes. Aquí explicamos qué cambia y mostramos una consulta real realizada por TERAMONT.
Qué cambia y cuál es el alcance real
Según el anuncio de Cloudflare, la validación está habilitada en el resolutor. Sus usuarios no tienen que activarla. La protección completa requiere una cadena de confianza compatible hasta la raíz; no basta con una firma en el dominio final. La firma ML-DSA-44 ocupa 2.420 bytes. El soporte correspondiente de firma en DNS autoritativo y de registros DS en Registrar se presenta como siguiente paso, no como una función ya desplegada por este anuncio.
DNSSEC no es lo mismo que DNS cifrado
| Capa | Qué aporta | Qué no demuestra |
|---|---|---|
| DNSSEC | Autenticidad e integridad de datos DNS mediante firmas. | Que la consulta viaje oculta o que el sitio sea confiable. |
| DNS sobre HTTPS o TLS | Cifrado del transporte entre cliente y resolutor. | Que toda la cadena DNSSEC sea poscuántica. |
| HTTPS del sitio | Protección de la conexión con el servicio web. | Que el dominio use este nuevo algoritmo DNSSEC. |
La documentación de DNS cifrado explica las opciones de transporte de 1.1.1.1. La consecuencia práctica es que estas capas se complementan: cambiar el resolutor no sustituye el certificado de tu web, sus actualizaciones ni el control de acceso al panel.
Ilustración generada para explicar la confianza entre componentes; no es un esquema exacto de la red de Cloudflare.
Prueba real: una consulta desde nuestro entorno
El 11 de septiembre de 2026, a las 18:50 UTC−6, ejecutamos una consulta con dig al dominio de prueba indicado por Cloudflare. Solo consultamos DNS público; no modificamos un dominio ni la configuración de un servidor.
Tu aplicación, en un entorno que puedes administrar
Explora VPS Hosting de TERAMONT para tu proyecto. La seguridad requiere configurar y mantener por separado el sistema, la aplicación y el DNS.
dig @1.1.1.1 valid.mldsa44.dnstest.dev +dnssec +noall +comments +stats| Observación local | Resultado | Cómo interpretarlo |
|---|---|---|
| Estado | NOERROR | La consulta obtuvo una respuesta sin error DNS. |
| Indicador de autenticación | ad | El resolutor indicó que los datos estaban autenticados. |
| Transporte final | TCP, después de una respuesta truncada | La herramienta reintentó por TCP. |
| Presupuesto UDP anunciado | 1.232 bytes | Valor EDNS observado en esta consulta. |
| Tamaño recibido | 2.563 bytes | Tamaño de esta respuesta, no de todas las consultas. |
| Tiempo informado | 65 ms | Una medición puntual, no un benchmark comparativo. |
Límites de la prueba: una consulta, un entorno y un momento. No controlamos la caché ni comparamos regiones, proveedores o algoritmos. El indicador ad por sí solo tampoco demuestra una cadena íntegramente poscuántica; nuestro cliente confía en lo que declara el resolutor. No se puede concluir que tu sitio cargará más rápido o más lento a partir de esos 65 ms.
Cómo comprobar tu dominio sin cambiar nada
En un equipo con dig, sustituye el dominio de ejemplo por el tuyo y consulta primero sus registros habituales. Estas comprobaciones son de lectura:
dig @1.1.1.1 example.com A +dnssec
dig @1.1.1.1 example.com DNSKEY +dnssec
dig @1.1.1.1 example.com DS +dnssecRevisa el estado de respuesta, las firmas y la configuración DNSSEC del proveedor y del registrador. No tomes la ausencia de ad como prueba de un ataque. Un SERVFAIL tampoco identifica por sí solo la causa: puede requerir revisar la delegación, las firmas y la conectividad. Consulta la guía oficial de diagnóstico DNSSEC antes de modificar registros.
Qué debería hacer quien administra un VPS
- Separar responsabilidades. Anota quién registra el dominio, quién publica su DNS y dónde corre la aplicación. Pueden ser tres proveedores distintos.
- Revisar DNSSEC existente. Un registro DS del registrador debe corresponder con las claves de la zona. Sigue la documentación del proveedor; no copies claves de un ejemplo.
- No bloquear el diagnóstico por TCP. Nuestra consulta necesitó ese transporte. Si UDP funciona y TCP falla en tu entorno, revisa la política de red aplicable sin abrir servicios indiscriminadamente.
- Preparar una recuperación. Antes de cambiar proveedor DNS, documenta registros, TTL y procedimiento de migración. No borres el DS ni desactives DNSSEC solo porque apareció esta noticia.
- Mantener las otras capas. Actualizaciones del sistema, mínimos privilegios, HTTPS y copias siguen siendo necesarios.
Si necesitas alojar tu aplicación con control de su entorno, revisa el VPS Hosting de TERAMONT. Contratar infraestructura no activa por sí mismo DNSSEC poscuántico: la configuración del dominio y la aplicación sigue siendo una tarea separada.
Conclusión: un avance real, no un escudo universal
La noticia merece atención porque introduce capacidad de validación que el ecosistema necesita. Para una web en producción, la mejor respuesta hoy es conocer su cadena DNS, comprobar que funciona y evitar cambios apresurados. Nuestra prueba añade un dato concreto: esa respuesta grande pudo resolverse mediante un reintento TCP; no demuestra adopción universal ni seguridad completa frente a cualquier amenaza.
