¿Qué es DNSSEC? Cómo funciona y cómo activarlo sin riesgos

El DNS clásico no tiene forma de demostrar que una respuesta es auténtica. Un resolver envía una pregunta por UDP y se cree la primera respuesta plausible. Cualquiera que pueda inyectar o alterar esa respuesta (mediante envenenamiento de caché, una red comprometida o un resolver malicioso) puede enviar a los usuarios a otro servidor. DNSSEC, las extensiones de seguridad del DNS, cierra esa brecha añadiendo firmas digitales a los datos DNS, de modo que un resolver pueda verificar que una respuesta procede realmente del propietario de la zona y no ha sido modificada por el camino.

Merece la pena activarlo en la mayoría de los dominios, y es también una de las pocas funciones del DNS que puede dejar un dominio completamente fuera de servicio si se maneja con descuido. Las dos mitades se tratan a continuación.

Qué hace DNSSEC y qué no

Proporciona:

Autenticación del origen e integridad: los registros fueron publicados por quien posee las claves de la zona y no han sido modificados.
Denegación de existencia autenticada: una prueba firmada de que un nombre o un tipo de registro no existe, para que un "no existe tal dominio" tampoco pueda falsificarse.

No proporciona:

Cifrado. Las consultas y las respuestas siguen siendo legibles para cualquiera en el camino. La privacidad es tarea de DNS sobre TLS o DNS sobre HTTPS, que protegen el tramo entre el cliente y el resolver y complementan a DNSSEC en lugar de sustituirlo.
Protección frente a una cuenta DNS comprometida. Si un atacante puede editar su zona, el proveedor firmará sin problema los registros del atacante.
Protección de la sesión web. Eso es TLS. DNSSEC garantiza que llega a la dirección correcta; el certificado demuestra que el servidor es quien dice ser.
Nada para los usuarios cuyo resolver no valida. Muchos grandes resolvers públicos y operadores validan; no todos lo hacen.

Cómo funciona

DNSSEC añade unos cuantos tipos de registro:

Registro	Dónde	Finalidad
`RRSIG`	junto a cada conjunto de registros	la firma sobre ese conjunto (por ejemplo, sobre todos los registros `A` de `www`)
`DNSKEY`	ápice de la zona	las claves públicas de la zona
`DS`	en la zona padre	un hash de la clave del hijo; el eslabón de la cadena
`NSEC` / `NSEC3`	por toda la zona	demuestra qué nombres y tipos no existen
`CDS` / `CDNSKEY`	ápice de la zona	permite al hijo señalar automáticamente al padre los cambios de DS

La mayoría de las zonas usa dos claves. La clave de firma de zona (ZSK) firma los registros. La clave de firma de claves (KSK) firma solo el conjunto DNSKEY, y es el hash de la KSK el que se publica como registro DS en el padre. Esta separación permite rotar la ZSK con frecuencia sin involucrar al padre. Algunos proveedores usan en su lugar una única clave combinada (CSK); el principio es el mismo.

La cadena de confianza

Un resolver validador confía de entrada en una sola cosa: la clave pública de la zona raíz, firmada desde 2010. Todo lo demás se deriva de ahí:

root DNSKEY  (trust anchor, built into the resolver)
   └─ signs  DS for "com"          → matches com's DNSKEY
         └─ signs  DS for "example.com"   → matches example.com's DNSKEY
               └─ signs  www.example.com A 192.0.2.10

En cada nivel, el padre responde por la clave del hijo publicando y firmando un registro DS. Si todos los eslabones se verifican, la respuesta es segura y el resolver activa el indicador ad (authenticated data). Si una zona no tiene DS en su padre, es simplemente insegura: se trata como DNS ordinario sin firmar, sin daño alguno. Pero si existe un DS y las firmas no se verifican (clave incorrecta, firma caducada, RRSIG ausente), el resultado es bogus y el resolver devuelve SERVFAIL. Para los usuarios detrás de resolvers validadores, el dominio deja de existir.

Ese último caso es todo el riesgo operativo de DNSSEC, y explica las reglas que siguen.

Un detalle que conviene conocer: las firmas caducan. Cada RRSIG tiene una hora de inicio y una de expiración. El firmante debe volver a firmar con regularidad. Los proveedores de DNS gestionado lo hacen automáticamente; un firmante autoalojado que deja de ejecutarse produce una caída una o dos semanas después.

Comprobar DNSSEC con dig

¿Hay un registro DS en el padre (es decir, se supone que el dominio está firmado)?

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

Los campos son la etiqueta de clave, el algoritmo (13 = ECDSA P-256 con SHA-256, la elección moderna habitual), el tipo de resumen (2 = SHA-256) y el resumen.

¿Publica la zona claves y firmas?

$ dig +dnssec +multi example.com DNSKEY
$ dig +dnssec www.example.com A
www.example.com.  3600 IN A      192.0.2.10
www.example.com.  3600 IN RRSIG  A 13 3 3600 20261004000000 20260920000000 31589 example.com. oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr...

¿Valida? Pregunte a un resolver validador y mire los indicadores:

$ dig www.example.com A @1.1.1.1 | grep flags
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, ...

ad significa que el resolver validó la respuesta. Para distinguir un fallo de DNSSEC de otros fallos, repita una consulta que falla con la comprobación desactivada:

$ dig www.example.com A @1.1.1.1          # status: SERVFAIL
$ dig www.example.com A @1.1.1.1 +cd      # status: NOERROR, answer present

SERVFAIL en condiciones normales pero una respuesta con +cd es la huella de una configuración DNSSEC rota. delv www.example.com (incluido con BIND) realiza la validación localmente y explica dónde se rompe la cadena.

Cómo activar DNSSEC

Necesita que tres partes lo admitan: el TLD (casi todos lo hacen), el proveedor de DNS (firma la zona) y el registrador (pasa el DS al registro).

Active la firma en el proveedor de DNS. Este genera las claves y empieza a publicar registros DNSKEY y RRSIG. En este punto nada puede romperse, porque sin un DS la zona sigue siendo "insegura".
Verifique la zona firmada: dig +dnssec contra los servidores de nombres del proveedor debería mostrar RRSIG para sus registros. Espere al menos un TTL para que las cachés contengan los datos firmados.
Publique el registro DS.
- Si el registrador y el proveedor de DNS son la misma empresa, normalmente es un clic, o automático.
- En caso contrario, copie los valores del DS (etiqueta de clave, algoritmo, tipo de resumen, resumen) desde el proveedor de DNS al formulario de DNSSEC del registrador. Algunos registradores piden en su lugar el DNSKEY y calculan el DS ellos mismos. Copie con cuidado; un solo carácter erróneo convierte el dominio en bogus.
- Algunos registros y registradores consultan los registros CDS/CDNSKEY y crean o actualizan el DS por su cuenta. Si el suyo lo hace, prefiera esa vía.
Verifique la cadena con los comandos anteriores y con un validador externo, desde más de un resolver.
Vigile. La caducidad de las firmas y las discrepancias del DS no avisan hasta que fallan.

Los momentos peligrosos

Cambiar de proveedor de DNS o de servidores de nombres. El DS en el padre apunta a la clave del proveedor antiguo. Cambie los servidores de nombres sin ocuparse de eso y el dominio se vuelve bogus. O bien retira el DS, espera a que expire su TTL (a menudo un día), se muda y vuelve a activarlo; o bien hace una migración coordinada con varios firmantes. La secuencia completa está en cambiar de servidores de nombres sin interrupciones.
Desactivar DNSSEC. El orden es el inverso al de la activación: retire primero el DS, deje pasar su TTL y solo entonces deje de firmar. Desactivar la firma mientras el DS sigue publicado es la caída autoinfligida clásica.
Transferir el dominio a otro registrador cuando el registrador antiguo también aloja el DNS. Consulte cómo transferir un dominio.
Rotaciones de claves en firmantes autoalojados. Una rotación de la KSK involucra al padre y debe seguir el patrón publicar–esperar–cambiar–esperar–retirar. Con un proveedor gestionado, eso es tarea suya.

Recuerde que bajar sus propios TTL no ayuda con una cadena rota: el TTL del registro DS lo fija la zona padre.

Errores frecuentes

Pegar el DS con un número de algoritmo o de tipo de resumen equivocado.
Dejar un DS antiguo en su sitio tras cambiar de proveedor de DNS.
Desactivar la firma antes de retirar el DS.
Un firmante autoalojado cuya tarea programada murió; todo funciona hasta que caducan las firmas.
Elegir NSEC sin darse cuenta de que permite enumerar los nombres de la zona ("zone walking"). NSEC3, o las técnicas de respuesta mínima que usan los grandes proveedores, lo dificultan.
Usar algoritmos obsoletos (RSA/SHA-1) cuando ECDSA P-256 da respuestas más pequeñas y lo admiten todos los validadores actuales.
Suponer que, como el sitio le funciona a usted, DNSSEC está bien. Puede que su resolver no valide.

¿Merece la pena?

Para la mayoría de los dominios en un proveedor de DNS gestionado: sí. Es gratuito, son uno o dos clics y elimina una clase de ataque que de otro modo le resulta invisible. El coste es disciplina operativa en los pocos momentos enumerados arriba. Si su equipo cambia de proveedor de DNS a la ligera y nadie se hace cargo de la cuenta del registrador, arregle eso primero.

Compruébelo con OrbitProbe

La consulta DNS de OrbitProbe muestra los registros que los resolvers públicos devuelven para su dominio, con sus TTL. Un dominio firmado que de repente no devuelve ningún registro desde los resolvers validadores, mientras el panel de su proveedor parece normal, es el patrón que hay que reconocer: vaya directamente a la prueba con +cd de más arriba. La visión que el registro tiene de la delegación, incluido si está marcada como firmada, aparece en los datos de registro tal como se describe en WHOIS y RDAP.