DNSSEC (DNS Security Extensions, extensiones de seguridad de DNS) añade firmas digitales a los registros DNS para que los resolutores puedan verificar que una respuesta procede realmente del propietario del dominio y que nadie la ha alterado por el camino. No cifra nada; demuestra la autenticidad mediante una cadena de confianza que empieza en la raíz de DNS.
El DNS normal no tiene forma de distinguir una respuesta genuina de una falsificada. DNSSEC, estandarizado en las RFC 4033, 4034 y 4035, cierra esa brecha. Esta guía explica los tipos de registro implicados, cómo funciona la validación y los errores que con más frecuencia dejan fuera de servicio a los dominios firmados.
El problema que resuelve DNSSEC
Un resolutor recursivo acepta la primera respuesta que coincide con su pregunta. Un atacante que consiga inyectar una respuesta falsa, ya sea situándose en la ruta de red o ganando una carrera contra el servidor real en un ataque de envenenamiento de caché, puede redirigir a los usuarios de ese resolutor a la dirección IP que elija. Todos los que comparten ese resolutor reciben entonces la respuesta falsa hasta que caduca la entrada en caché.
DNSSEC hace que la falsificación sea detectable. Cada conjunto de registros se firma con la clave privada de la zona, y la clave pública correspondiente se publica en DNS. Un resolutor que valida comprueba la firma y rechaza todo lo que no se verifique. Si antes necesitas repasar qué son los resolutores y los servidores autoritativos, lee qué es DNS y cómo funciona.
Tipos de registro de DNSSEC
| Registro | Dónde está | Finalidad |
|---|---|---|
DNSKEY | La zona firmada | Claves públicas que sirven para verificar las firmas de la zona |
RRSIG | La zona firmada | Una firma sobre un conjunto de registros (por ejemplo, todos los registros A de un nombre), con fechas de inicio y fin de validez |
DS | La zona padre | Delegation Signer: un hash de la clave de firma de claves de la zona hija, que enlaza la zona padre con la hija |
NSEC | La zona firmada | Demuestra que un nombre o un tipo de registro no existe indicando el siguiente nombre existente en orden alfabético |
NSEC3 | La zona firmada | Igual que NSEC pero con nombres con hash (RFC 5155), lo que dificulta listar todos los nombres de la zona |
CDS / CDNSKEY | La zona firmada | Indican al padre qué registro DS debería publicar, lo que permite actualizaciones automáticas (RFC 7344) |
Nuestra guía de tipos de registros DNS cubre los registros ordinarios, como A, MX y TXT, que estas firmas protegen.
Por qué hace falta demostrar la inexistencia
Sin NSEC ni NSEC3, un atacante podría falsificar una respuesta NXDOMAIN («este nombre no existe»), que no puede llevar una firma propia porque no hay ningún registro que firmar. Los registros NSEC dan al resolutor una declaración firmada de que no existe nada entre dos nombres, de modo que también se puede verificar una negativa.
Claves de firma de claves y claves de firma de zona
La mayoría de las zonas usan dos tipos de clave, ambas publicadas como registros DNSKEY:
- Clave de firma de zona (ZSK), DNSKEY con flags
256: firma los conjuntos de registros ordinarios de la zona. Se puede rotar con frecuencia sin que intervenga nadie más. - Clave de firma de claves (KSK), DNSKEY con flags
257: firma solo el conjunto de registros DNSKEY. Su hash es lo que se incluye en el registro DS del padre, así que cambiarla exige actualizar el registrador.
Separar las funciones hace que los cambios rutinarios de clave se queden dentro de tu proveedor de DNS, mientras que el cambio de KSK, más infrecuente, es el único que afecta a la zona padre. Algunas configuraciones usan en su lugar una sola clave de firma combinada, que es más sencilla y habitual con los algoritmos modernos de curva elíptica, como el algoritmo 13 (ECDSA P-256 con SHA-256).
La cadena de confianza
Una firma solo sirve si el resolutor confía en la clave que la generó. DNSSEC construye esa confianza paso a paso desde la raíz, que se firmó en 2010. Los resolutores que validan incluyen la KSK de la zona raíz como ancla de confianza integrada. Para validar www.example.com, un resolutor:
- Usa el ancla de confianza de la raíz para verificar el conjunto DNSKEY de la raíz.
- Verifica el registro DS firmado de
comen la zona raíz y comprueba después que coincide con la KSK del conjunto DNSKEY decom. - Verifica el registro DS firmado de
example.comen la zonacomy comprueba después que coincide con la KSK que publicaexample.com. - Usa el conjunto DNSKEY de
example.compara verificar el RRSIG de los registros A dewww.example.com.
Si todos los eslabones se verifican, la respuesta es segura (secure). Si el padre no tiene registro DS para una zona, la zona es insegura (insecure, sin firmar) y la respuesta se devuelve con normalidad. Si existe un DS pero las firmas no se verifican, la respuesta es falsa (bogus).
Cómo se ve la validación: AD y SERVFAIL
Cuando un resolutor que valida verifica correctamente una respuesta, activa el flag AD (Authenticated Data, datos autenticados) en la respuesta. Puedes verlo con dig:
$ dig +dnssec www.example.com A @1.1.1.1
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
www.example.com. 300 IN A 192.0.2.10
www.example.com. 300 IN RRSIG A 13 3 300 20261101000000 20261011000000 12345 example.com. (signature data)Cuando la validación falla, el resolutor no devuelve los datos posiblemente falsificados. Devuelve SERVFAIL, que a los usuarios les parece igual que un sitio que no existe o una caída de DNS. Para confirmar que la causa es DNSSEC, repite la consulta con la comprobación desactivada:
dig www.example.com A # status: SERVFAIL
dig +cd www.example.com A # status: NOERROR, answer returnedSi la consulta con +cd (checking disabled, comprobación desactivada) funciona y la normal falla, el DNSSEC de la zona está roto. Nuestro comprobador de DNSSEC ejecuta estas comprobaciones por ti y muestra el estado del DS, de las DNSKEY y de las firmas.
Formas habituales en que se rompe DNSSEC
Cambiar de proveedor de DNS sin quitar el registro DS
Es el fallo clásico. El registro DS publicado en el registro del TLD sigue apuntando a la KSK del proveedor anterior. Tras cambiar los servidores de nombres, el proveedor nuevo sirve la zona sin firmar o la firma con claves distintas. Los resolutores que validan encuentran un DS sin ninguna clave que coincida, marcan la zona como falsa (bogus) y todas las consultas devuelven SERVFAIL.
Una migración segura sigue estos pasos:
- En el registrador, elimina el registro DS.
- Espera a que el DS antiguo haya caducado en las cachés: como mínimo el TTL del registro DS en la zona padre, que puedes ver con
dig example.com DS. Esperar uno o dos días es un margen de seguridad habitual. - Cambia los servidores de nombres al proveedor nuevo y espera a que caduquen los registros NS antiguos.
- Activa DNSSEC en el proveedor nuevo y publica su nuevo registro DS en el registrador.
Algunos proveedores admiten una configuración multifirmante que evita el intervalo sin firmar, pero requiere la cooperación de ambos proveedores.
Firmas caducadas
Cada RRSIG tiene una fecha de caducidad. Si el proceso de firma se detiene, por ejemplo en un servidor propio cuya tarea de refirmado ha fallado, las firmas acaban caducando y la zona pasa a ser falsa (bogus).
Cambios de clave hechos demasiado rápido
Quitar una clave antigua antes de que las cachés hayan recogido la nueva provoca fallos en los resolutores que aún conservan el conjunto DNSKEY o el registro DS antiguos. Los cambios de clave deben respetar los TTL implicados.
Cómo activar DNSSEC en tu dominio
- Comprueba que tu TLD admite DNSSEC; lo hacen la mayoría de los genéricos y muchos de código de país.
- Activa la firma DNSSEC en tu proveedor de alojamiento DNS. Generará las claves y firmará la zona.
- Copia los datos del registro DS (etiqueta de clave, algoritmo, tipo de resumen y resumen) en la configuración de DNSSEC de tu registrador. Si tu proveedor y tu registrador son la misma empresa, esto suele ser automático, y algunos operadores de registro (registries) recogen los registros CDS de forma automática.
- Verifica el resultado con nuestro comprobador de DNSSEC y comprueba que las consultas normales siguen funcionando con la herramienta de consulta DNS.
Preguntas frecuentes
¿DNSSEC cifra mis consultas DNS?
No. DNSSEC ofrece autenticidad e integridad, no privacidad. Las consultas y las respuestas siguen siendo visibles en la red. El cifrado lo aportan DNS sobre TLS o DNS sobre HTTPS, que complementan a DNSSEC.
¿Necesito DNSSEC si mi sitio usa HTTPS?
Los certificados HTTPS ya impiden que una respuesta DNS falsificada suplante tu sitio sin que nadie se dé cuenta, pero DNSSEC también protege el enrutamiento del correo, los registros TXT que se usan para verificaciones y otros registros. Además, es obligatorio para DANE, que publica en DNS la información de los certificados TLS.
¿Por qué mi dominio funciona en unas redes y en otras no?
Si DNSSEC está roto, solo los resolutores que validan devuelven SERVFAIL; los que no validan siguen respondiendo. Por eso parece que la caída depende de la red.
¿Cómo desactivo DNSSEC de forma segura?
Elimina primero el registro DS en el registrador, espera a que caduque en las cachés y solo entonces deja de firmar la zona. Hacerlo en el orden contrario provoca una caída.