Por qué DNSSEC es esencial para la seguridad del dominio

El DNS se diseñó en los años ochenta para una red cooperativa y confía en las respuestas por defecto. Un resolutor que recibe una respuesta plausible a su pregunta normalmente la acepta, la guarda en caché y se la entrega a todos los usuarios que pregunten después. Esa apertura es justo lo que aprovechan los atacantes. DNSSEC (Domain Name System Security Extensions) corrige esta debilidad de fondo al permitir que los resolutores verifiquen que una respuesta procede realmente del propietario de la zona y no se modificó por el camino. En este artículo explicamos qué problema resuelve DNSSEC, cómo funciona su cadena de confianza y cómo activarlo sin dejar su dominio fuera de línea.

Si la resolución DNS es nueva para usted, empiece por nuestra guía sobre cómo funciona el DNS; los tipos de registro como A, MX y TXT se tratan en entender los registros DNS.

El problema: las respuestas DNS se pueden falsificar

Una consulta DNS clásica es un pequeño paquete UDP. El resolutor empareja la respuesta mediante unos pocos campos, como el identificador de la consulta y el puerto de origen. Si un atacante consigue adivinar esos valores, adelantarse en la carrera o situarse en la ruta de red, puede inyectar una respuesta falsa. El ejemplo más conocido es la técnica de envenenamiento de caché que Dan Kaminsky hizo pública en 2008, que demostró que, en las condiciones adecuadas, un atacante fuera de la ruta podía envenenar la caché de un resolutor para todo un dominio en cuestión de segundos.

La aleatorización del puerto de origen dificultó mucho estos ataques, pero no los hizo imposibles. Siguen existiendo otras amenazas:

• Manipulación en la ruta mediante routers comprometidos, redes Wi-Fi hostiles o infraestructura fraudulenta.
• Compromiso del resolutor, en el que una caché envenenada envía a muchos usuarios a la vez a un sitio falso.
• Desvío del correo mediante registros MX falsificados, lo que permite interceptar mensajes que no aplican bien el cifrado.

El cifrado, como DNS over HTTPS, protege el enlace entre usted y su resolutor, pero no demuestra que la respuesta del resolutor sea auténtica. Eso lo hace DNSSEC.

Qué hace DNSSEC y qué no hace

DNSSEC proporciona autenticación del origen e integridad de los datos. Un resolutor validador puede confirmar que un conjunto de registros fue firmado con la clave de la zona y que no ha cambiado desde entonces. También ofrece denegación de existencia autenticada, de modo que un atacante no puede falsificar una respuesta de "este nombre no existe".

Igual de importante es saber lo que no hace:

• No cifra las consultas ni las respuestas DNS; cualquiera en la ruta puede seguir leyéndolas.
• No protege frente a una cuenta de registrador secuestrada. Si alguien cambia sus servidores de nombres y su registro DS en el registrador, los datos falsos validarán correctamente.
• No asegura el sitio web en sí; sigue necesitando HTTPS y un certificado válido.

Los nuevos tipos de registro

Cómo funciona la cadena de confianza

Un resolutor validador solo necesita una clave en la que confíe de antemano: la clave de firma de claves de la zona raíz, configurada como ancla de confianza (trust anchor). A partir de ahí sigue una cadena:

1. El conjunto DNSKEY de la raíz se verifica con el ancla de confianza.
2. La zona raíz contiene un registro DS firmado para com. El resolutor comprueba la RRSIG de ese DS con la clave de la raíz.
3. El resolutor obtiene el conjunto DNSKEY de com y confirma que una de sus claves coincide con el hash del DS.
4. El patrón se repite: com publica un DS firmado para example.com, que debe coincidir con una DNSKEY de su zona.
5. Por último, su DNSKEY verifica la RRSIG de la respuesta que pidió el usuario, como el registro A de www.example.com.

Si todos los eslabones son correctos, el resolutor activa el indicador AD (datos autenticados). Si alguno falla, un resolutor validador rechaza la respuesta y devuelve SERVFAIL. Si el padre no tiene registro DS para una zona, esta se trata simplemente como no firmada (insegura) y se resuelve con normalidad.

KSK y ZSK

La mayoría de las zonas usan claves con dos funciones:

• La clave de firma de claves (KSK) firma únicamente el conjunto DNSKEY. Su hash es lo que publica como registro DS en el padre, así que cambiarla exige una actualización en el registrador.
• La clave de firma de zona (ZSK) firma todos los demás registros. Puede renovarse con frecuencia y completamente dentro de su zona, sin tocar el padre.

En los registros DNSKEY, la KSK suele mostrar el indicador 257 y la ZSK el 256. Algunos proveedores usan una única clave combinada (CSK); también funciona, pero entonces cada renovación de clave requiere actualizar el DS.

El algoritmo 13 y por qué es la opción habitual

Cada clave y cada firma indican un número de algoritmo. El algoritmo 8 (RSA/SHA-256) fue durante mucho tiempo el predeterminado y sigue teniendo amplio soporte. El algoritmo 13 (ECDSA con la curva P-256 y SHA-256) es el que recomiendan hoy las buenas prácticas y el que usan por defecto muchos grandes proveedores DNS, por varias razones:

• Claves y firmas mucho más pequeñas que RSA con una seguridad comparable, lo que mantiene reducido el tamaño de las respuestas.
• Las respuestas pequeñas reducen la probabilidad de fragmentación UDP y de recurrir a TCP.
• Amplio soporte de validación en los resolutores modernos.

El algoritmo 15 (Ed25519) también se recomienda, aunque algunos validadores y registros antiguos lo admiten de forma menos uniforme. El tipo de resumen del DS es un número aparte: lo habitual es el 2 (SHA-256).

Comprobar DNSSEC con dig

Pida los datos DNSSEC con +dnssec y busque los registros RRSIG y el indicador ad (salida abreviada):

$ dig +dnssec example.com A

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2
example.com.  300  IN  A      93.184.215.14
example.com.  300  IN  RRSIG  A 13 2 300 20261021000000 20261007000000 12345 example.com. (firma)

En la RRSIG, 13 es el algoritmo, 12345 es la etiqueta de clave (key tag) y las dos marcas de tiempo son la caducidad y el inicio de la firma. Para comparar sus claves con las del padre:

$ dig example.com DNSKEY +short
257 3 13 mdsswUyr3DPW132mOi8V9xESWE8jTo0d...
256 3 13 oJMRESz5E4gYzS/q6XDrvU1qMPYIjCWz...

$ dig example.com DS +short
12345 13 2 3490A6806D47F17A34C29E2CE80E8A999FFBE4BE...

La línea DS se lee así: etiqueta de clave, algoritmo, tipo de resumen y resumen. La etiqueta y el algoritmo deben corresponder a la KSK (indicador 257) de su conjunto DNSKEY. Analizadores en línea como DNSViz dibujan la cadena completa y señalan los eslabones rotos.

Fallos habituales y SERVFAIL

Lo complicado es que solo fallan los resolutores validadores. Quien usa un resolutor que no valida ve su sitio con normalidad, así que una rotura de DNSSEC puede parecer una caída parcial misteriosa. Ayuda ejecutar dig +cd (comprobación desactivada) contra un resolutor validador: si la consulta funciona con +cd y falla sin él, el culpable es DNSSEC.

Cómo activar DNSSEC de forma segura

1. Confirme el soporte. Su TLD, su registrador y su proveedor DNS deben admitir DNSSEC. La mayoría de los TLD importantes ya están firmados.
2. Active la firma en el proveedor DNS. Elija el algoritmo 13 si está disponible y deje que el proveedor gestione automáticamente las renovaciones de la ZSK.
3. Publique el registro DS en el registrador. Copie exactamente la etiqueta de clave, el algoritmo, el tipo de resumen y el resumen. Algunos registradores y proveedores lo automatizan mediante registros CDS/CDNSKEY.
4. Verifique. Compruebe el indicador ad a través de un resolutor validador y revise la cadena en un analizador.
5. Planifique las migraciones. Al cambiar de proveedor DNS, transfiera las claves correctamente o retire el DS, espere a que caduque el TTL del DS en el padre, migre y vuelva a activarlo.

DNSSEC también depende de que la cuenta del registrador se mantenga en buen estado, porque allí reside el DS. Vigile el registrador, los servidores de nombres y la fecha de caducidad con la consulta WHOIS y RDAP de TLDix, y controle las renovaciones de toda su cartera en el panel de TLDix para que un registro vencido nunca rompa la cadena.

¿Merece la pena DNSSEC?

Para dominios que gestionan correo, inicios de sesión, pagos o la confianza en una marca, la respuesta suele ser que sí. Con los proveedores actuales, la firma es en gran parte automática y el algoritmo 13 mantiene baja la sobrecarga. El riesgo operativo real se concentra en unos pocos momentos previsibles, sobre todo los cambios de DS y las migraciones de proveedor. Si los gestiona con cuidado, DNSSEC cierra discretamente una brecha que existe en el DNS desde sus orígenes y, además, abre la puerta a tecnologías como DANE, que se apoyan en datos DNS firmados.