¿Qué es DNSSEC?
DNSSEC (Extensiones de Seguridad del Sistema de Nombres de Dominio) añade firmas digitales a los conjuntos de registros DNS. Un resolutor validador puede usar firmas válidas y una cadena de confianza para autenticar los datos firmados y detectar cambios no autorizados. DNSSEC no cifra las consultas ni las respuestas DNS.Cómo Funciona DNSSEC
Cadena de confianza (ejemplo con claves separadas):
Zona raíz (.)
├── La KSK raíz (ancla de confianza) firma el RRset DNSKEY de la raíz
└── La ZSK raíz firma los demás conjuntos de registros autoritativos (RRset) de la zona raíz, salvo el RRset DNSKEY, incluido el RRset DS de .com publicado en la zona padre
└── El resumen criptográfico del DS corresponde a la KSK de .com
├── La KSK de .com firma el RRset DNSKEY de .com
└── La ZSK de .com firma los demás conjuntos de registros autoritativos (RRset) de .com, salvo el RRset DNSKEY, incluido el RRset DS de example.com publicado en la zona padre
└── El resumen criptográfico del DS corresponde a la KSK de example.com
├── La KSK de example.com firma el RRset DNSKEY de example.com
└── La ZSK de example.com firma los demás conjuntos de registros autoritativos (RRset) de example.com, salvo el RRset DNSKEY
El resolutor valida las firmas y los resúmenes criptográficos de los DS desde el ancla de confianza de la raíz
Tipos de Registros DNSSEC
| Registro | Propósito | Descripción |
|---|---|---|
| RRSIG | Firma | Firma criptográfica para cada conjunto de registros |
| DNSKEY | Clave Pública | Claves públicas de firma de zona (KSK y ZSK) |
| DS | Firmante de delegación | Resumen criptográfico de la KSK de la zona hija, publicado en la zona padre |
| NSEC/NSEC3 | Negación Autenticada | Prueba de que un registro no existe |
Tipos de Claves
| Clave | Propósito | Frecuencia de Rotación |
|---|---|---|
| KSK (Clave de Firma de Clave) | Firma registros DNSKEY | Depende de la política; consulta la nota siguiente |
| ZSK (Clave de Firma de Zona) | Firma los demás conjuntos de registros autoritativos (RRset), salvo el RRset DNSKEY. En la zona padre, los RRset NS del punto de delegación y los RRset de direcciones glue asociados no se firman; el RRset NS del ápice de la zona hija sí se firma ([RFC 4035 §2.2](https://www.rfc-editor.org/rfc/rfc4035.html#section-2.2)) | Depende de la política; consulta la nota siguiente |
El momento de la rotación depende de la función de la KSK y de la política del operador. Para una KSK vinculada mediante un registro DS en la zona padre, [RFC 6781 §3.3](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.3) considera razonable un intervalo de un año si se opta por una rotación periódica. Una KSK usada como ancla de confianza requiere coordinación con los resolutores validadores y su periodo de vigencia puede ser mucho más largo ([RFC 6781 §3.2.2](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.2.2)).
El periodo de vigencia de la ZSK también depende de la política del operador y de las limitaciones del proceso de rotación. Para una ZSK almacenada en un sistema conectado a la red y en un entorno con mayor riesgo de compromiso, [RFC 6781 §3.3](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.3) considera razonable un periodo de vigencia previsto de un mes. Se trata de una orientación condicionada, no de un intervalo universal. La planificación de la rotación debe dejar que transcurra el TTL de caché de las firmas antiguas para que los resolutores las descarten antes de retirar la clave anterior; [RFC 7583 §3.2.1](https://www.rfc-editor.org/rfc/rfc7583.html#section-3.2.1) explica los intervalos de TTL y propagación que deben tenerse en cuenta.
Rotación de la KSK raíz del 11 de octubre de 2026
ICANN indica que la rotación de la KSK de la zona raíz está prevista para el 11 de octubre de 2026. Comprueba que tu resolutor validador tiene cargada KSK-2024 (etiqueta de clave 38696) como ancla de confianza. No des por hecho que la actualización automática de las anclas de confianza haya funcionado. Si falta la clave, confirma que las actualizaciones automáticas están activadas y sigue las instrucciones del fabricante de tu resolutor. Consulta [la guía de ICANN sobre la rotación de la KSK raíz](https://www.icann.org/resources/pages/ksk-rollover-en) para ver la información actualizada.
Proceso de Validación DNSSEC
1. El cliente consulta a un resolutor DNS para obtener el registro A de example.com
2. El resolutor obtiene el registro A junto con su firma RRSIG
3. El resolutor obtiene la clave DNSKEY necesaria para verificar la firma RRSIG
4. El resolutor verifica que el resumen criptográfico del DS publicado en la zona padre corresponde a la DNSKEY de la zona hija
5. El resolutor continúa validando la cadena de confianza nivel por nivel hasta llegar a la raíz
6. Si todas las firmas son válidas, el resolutor autentica la respuesta.
Qué puede ayudar a detectar la validación de DNSSEC
Estas comprobaciones requieren conjuntos de registros DNS (RRset) firmados y un resolutor validador con una cadena de confianza intacta. Los datos sin firmar o inseguros no pueden autenticarse.
| Amenaza | Ejemplo | Protección de DNSSEC |
|---|---|---|
| Envenenamiento de caché | Datos DNS falsificados introducidos en la caché de un resolutor | Un resolutor validador puede rechazar los datos que no superen la validación de la firma o de la cadena. |
| Manipulación de respuestas | Se modifica durante el tránsito un conjunto de registros DNS firmado | Los datos modificados no superan la verificación de la firma. |
| Suplantación de DNS | Se proporciona una respuesta falsificada para una zona firmada | Un resolutor validador puede rechazar una respuesta que no supere la validación. |
Consideraciones de Implementación
- Rendimiento: Respuestas más grandes debido a firmas (~1000-4000 bytes vs ~100 bytes)
- Gestión de claves: Requiere generación, almacenamiento y rotación seguros de claves
- Firma de zona: Debe refirmar zona cuando los registros cambian
- Soporte de resolutor: Los clientes necesitan resolutores que validen DNSSEC
Mejores Prácticas
1. Elige un algoritmo de firma DNSSEC: el [registro de algoritmos DNSSEC de IANA](https://www.iana.org/assignments/dns-sec-alg-numbers) recomienda ECDSAP256SHA256 (algoritmo 13) para firmar y validar. ECDSAP384SHA384 (14) puede ser adecuado para aplicaciones que necesiten 192 bits de seguridad. Comprueba que los resolutores son compatibles antes de cambiar de algoritmo ([RFC 9904](https://www.rfc-editor.org/rfc/rfc9904.html), [RFC 8624 §3.1](https://www.rfc-editor.org/rfc/rfc8624.html#section-3.1)).
2. Automatiza la rotación de claves: utiliza herramientas como OpenDNSSEC para gestionar el ciclo de vida de las claves.
3. Vigila la caducidad de las firmas: las firmas RRSIG solo son válidas durante un periodo limitado.
4. Prueba la zona antes de desplegarla: valídala con herramientas como dnsviz.net.
5. Prepárate para las emergencias: documenta los procedimientos de rotación de claves para emergencias.
Cuando un resolutor validador verifica la cadena, DNSSEC autentica el origen y la integridad de los datos DNS firmados. Esto no permite concluir que el sitio web o el servidor que responde en una dirección devuelta sea de confianza.