• Blog
  • ¿Qué es el DNSSEC y cómo funciona?

¿Qué es el DNSSEC y cómo funciona?

DNSSEC autentica las consultas y respuestas del DNS mediante firmas digitales criptográficas. Obtén más información y descubre cómo BlueCat puede ayudarte a facilitar la implementación.

padlock and key
Puntos claveLos puntos clave se generan con la ayuda de la inteligencia artificial. Dado que los resúmenes automáticos pueden contener en ocasiones errores u omitir contexto importante, consulta siempre la entrada completa del blog para obtener toda la información.

El artículo explica el DNSSEC (Extensiones de Seguridad del Sistema de Nombres de Dominio) como un conjunto de especificaciones criptográficas que autentica las consultas y respuestas del DNS para mitigar los ataques inherentes a la resolución tradicional del DNS, como el envenenamiento de la caché del DNS y la suplantación de identidad de tipo «hombre en el medio». Describe cómo funciona el DNS de forma ingenua al aceptar cualquier respuesta útil, por qué eso permite los ataques y cómo DNSSEC añade firmas digitales (RRSIG), claves públicas y privadas (ZSK y KSK), así como registros DNSKEY y DS, para construir una cadena de confianza validada por los resolutores. El artículo también describe los pasos operativos para la resolución DNSSEC, las ventajas de la validación en caché y la prueba de inexistencia (PNE), y detalla cómo BlueCat centraliza y automatiza las tareas clave de DNSSEC —generación de claves, firma, gestión de DS, renovaciones, mantenimiento de PNE y supervisión— para reducir la complejidad y evitar que las zonas dejen de estar disponibles.

What specific DNS vulnerabilities does DNSSEC address and how does it prevent them?

DNSSEC addresses vulnerabilities in standard DNS that allow attackers to inject forged responses (DNS cache poisoning or DNS spoofing) and man-in-the-middle attacks. Traditional DNS will accept any response that satisfies a resolver’s query, enabling an attacker to substitute a malicious IP address and have that response cached for the resolver’s TTL. DNSSEC prevents this by signing RRsets with private keys (stored as RRSIG records) and providing public keys (DNSKEY) and DS records to establish a verifiable chain of trust up to configured trust anchors. A validating recursive resolver uses those signatures and keys to verify authenticity; if verification fails the resolver returns SERVFAIL rather than the forged response, preventing clients from being redirected to attacker-controlled sites. DNSSEC also provides proof of non-existence (PNE) to prevent fake NXDOMAIN injections.

What are the main DNSSEC components (records and keys) and how do they interact in validation?

Core DNSSEC components are RRsets and their RRSIG signatures, zone-signing keys (ZSK) and key-signing keys (KSK), DNSKEY records, and DS records linking parent and child zones. Administrators sign RRsets with the zone’s private ZSK; those signatures are stored in RRSIG records. The ZSK public key is published in a DNSKEY record. A KSK signs the DNSKEY RRset (including the ZSK public key) and produces an RRSIG over DNSKEY, enabling validation that the ZSK hasn’t been compromised. The parent zone stores a DS record containing a hash of the child zone’s DNSKEY (typically the KSK), forming a chain of trust from parent to child. A validating resolver walks this chain—verifying RRSIGs against DNSKEYs and DS records up to a trust anchor (e.g., the root)—and returns SERVFAIL if any step fails.

How does BlueCat simplify DNSSEC implementation and ongoing operations?

BlueCat centralizes and automates many DNSSEC tasks that are error-prone and operationally complex when performed manually. According to the article, BlueCat handles background generation of cryptographic key pairs, maintains the PNE chain using NSEC or NSEC3 records, signs zones and all associated DNS records, and generates DS records for parent zones. It automates scheduled KSK and ZSK rollovers and can generate new keys for emergency rollovers, while monitoring key generation success and failure. BlueCat also provides the capability to manually generate key pairs if automated generation fails, and exposes a single platform to configure DNSSEC, reducing the risk of mistakes like incorrect resigning or PNE maintenance that could cause a zone to go dark.

Dado que el DNS se diseñó pensando en la escalabilidad —y no en la seguridad—, el DNSSEC puede ser un complemento fundamental para su cartera de seguridad.

Pero, ¿qué es el DNSSEC? Para empezar, son las siglas de «Extensiones de Seguridad del Sistema de Nombres de Dominio». Se trata de un conjunto de especificaciones que utiliza firmas digitales basadas en criptografía para autenticar las consultas y respuestas del Sistema de Nombres de Dominio (DNS).

A primera vista, la implementación de DNSSEC puede parecer abrumadora. Sin embargo, cualquier dominio de acceso público puede beneficiarse de sus ventajas.

En esta entrada se abordará, en primer lugar, qué es exactamente el DNSSEC. A continuación, se detallará cómo funciona la resolución DNS tradicional y por qué es tan vulnerable a los ciberataques. Además, se profundizará en los detalles del funcionamiento del DNSSEC y en los pasos de autenticación que lleva a cabo. Por último, se analizará cómo BlueCat puede ayudar a facilitar la implementación del DNSSEC.

¿Qué es DNSSEC?

Es importante señalar que DNSSEC y la seguridad del DNS no son lo mismo. Aunque sus nombres parezcan similares, DNSSEC no es una abreviatura de «seguridad del DNS». (Este último es un término genérico que abarca numerosas estrategias y productos).

Entonces, ¿qué hace exactamente el DNSSEC? Cuando está habilitado, el DNSSEC ayuda a un servidor DNS a responder a las siguientes preguntas:

  • ¿Está autorizado el servidor de nombres raíz o autoritativo para proporcionar una respuesta a la consulta?
  • ¿Puedo confiar en el contenido de la respuesta a la consulta?
  • Además, ¿puedo confiar en que la respuesta no ha sufrido modificaciones durante la transmisión?

Cuantos más dominios sean compatibles con DNSSEC, más segura será Internet para todos. Según las estadísticas sobre DNSSEC de Internet Society, la mayoría de los dominios de primer nivel ya lo han implementado.

DNS sin DNSSEC

La resolución DNS normal es bastante sencilla: cuando un dispositivo envía una consulta DNS, los servidores de nombres de dominio y los resolutores intervienen para realizar una búsqueda DNS. Se aseguran de que la consulta DNS obtenga una respuesta con una dirección IP procedente del registro correspondiente.

Por desgracia, en este caso, «sencillo» también significa «ingenuo». Los atributos inherentes al protocolo DNS pueden exponer a cualquier entidad al riesgo de sufrir ciberataques.

Siempre que el resolutor reciba datos que respondan al objetivo de su solicitud, continuará con la consulta hasta que pueda enviar una dirección IP al cliente. La resolución DNS normal no puede filtrar las respuestas que recibe ni responder a las tres preguntas anteriores.

Esto hace que las consultas DNS estándar sean vulnerables a ataques de tipo «hombre en medio», como el envenenamiento de la caché DNS (y el envenenamiento DNS, estrechamente relacionado, también denominado suplantación de DNS). Un atacante inyecta una respuesta falsificada para sustituir la respuesta legítima a una solicitud de DNS. La respuesta falsificada apunta a un servidor controlado por el atacante, a menudo configurado para que parezca idéntico al sitio legítimo. Esto puede hacer que el usuario final no se dé cuenta en absoluto de que se encuentra en un sitio en el que no debería estar.

Si no se tiene habilitado el DNSSEC, el sitio malicioso también se almacena en la caché del resolutor. Como resultado, otros dispositivos que utilicen el mismo resolutor DNS también accederán al sitio malicioso. Este permanece en la caché hasta que expira su tiempo de vida predeterminado, lo que puede afectar a innumerables dispositivos.

DNSSEC: cómo funciona

A nivel básico, el DNSSEC valida las respuestas a las consultas DNS antes de devolverlas al dispositivo del cliente. El DNSSEC utiliza firmas digitales almacenadas en los servidores de nombres junto con los tipos de registros DNS habituales.

En el núcleo de DNSSEC se encuentra un par de claves pública-privada. Cada zona DNS tiene una clave pública y una clave privada.

La criptografía de clave pública es el punto de partida para la validación de DNSSEC. Accesible para todo el mundo, una clave pública proporciona los medios para descifrar mensajes firmados por la clave privada correspondiente.

Para que quede claro, la seguridad de DNSSEC no incluye medidas habituales como el cifrado de datos DNS, los certificados SSL o los secretos compartidos.

Algunos términos clave (sin doble sentido)

Registro RRSIG: la protección de una zona DNS con DNSSEC comienza agrupando los registros DNS del mismo nombre y tipo (por ejemplo, registros A) en un conjunto de registros de recursos, o RRset. Es el RRset —y no los registros DNS individuales— lo que realmente se firma. Un registro RRSIG contiene una firma criptográfica para un RRset.

Par de claves de firma de zona (ZSK): cada zona habilitada para DNSSEC cuenta con un par de claves pública y privada ZSK. Los administradores de red crean firmas criptográficas para cada conjunto de registros (RRset) de la zona con la clave privada y las almacenan como registros RRSIG. La clave pública ZSK verifica la firma y se almacena en el registro DNSKEY.

Registro DNSKEY: un registro DNSKEY almacena la clave pública. Normalmente hay dos por zona, para la clave de firma de zona (ZSK) y la clave de firma de claves (KSK). Los resolutores utilizan los registros DNSKEY para verificar que las firmas de los registros RRSIG son legítimas.

Clave de firma de claves (KSK): Para garantizar que la ZSK no se haya visto comprometida, los servidores de nombres DNS también disponen de una KSK para validar la ZSK pública. Esta firma la clave pública de la ZSK y crea un RRSIG para el registro DNSKEY. La KSK privada firma las claves públicas tanto de las ZSK como de las KSK.

Registro DS: El registro DS demuestra la relación entre una zona principal y una zona secundaria. Los registros DS residen en la zona principal y contienen un hash del DNSKEY de la zona secundaria que contiene la KSK. Los registros DS apuntan a la siguiente clave en la cadena de confianza.

La cadena de confianza

Dado que cada clave criptográfica firma la clave criptográfica siguiente, lo que permite que cada zona DNS valide el nivel inmediatamente inferior, se crea lo que se denomina una cadena de confianza. En la parte superior de la cadena se encuentran los anclajes de confianza.

Cada nivel del sistema de nombres de dominio lleva a cabo una validación. Tras verificar la autenticidad de las respuestas, el dispositivo cliente recibe la respuesta. Si la cadena de confianza se rompe en cualquier punto y no se puede realizar la verificación del registro, el servidor DNS responderá con un código de respuesta DNS «SERVFAIL».

Explicación paso a paso de DNSSEC

Los pasos básicos de la resolución y validación de DNSSEC son los siguientes:

  1. En primer lugar, el cliente solicita un registro A para example.com a su servidor recursivo de validación local.
  2. El servidor recursivo de validación sigue la ruta de recursión habitual desde la raíz hasta los servidores autoritativos de la zona de example.com.
  3. A continuación, el servidor recursivo solicita el registro A al servidor autoritativo.
  4. El servidor autoritativo responde con el registro A y el registro RRSIG A correspondiente para example.com.
  5. A continuación, el servidor recursivo solicita al servidor autoritativo de example.com el registro DNSKEY de la zona.
  6. El servidor autoritativo de example.com devuelve el registro DNSKEY y el registro RRSIG DNSKEY correspondiente para example.com.
Steps 1 to 6 of DNSSEC resolution and validation
  1. A continuación, el servidor recursivo solicita a .com el registro DS de example.com.
  2. El servidor .com responde con el registro DS y el registro RRSIG DS correspondiente para example.com.
  3. A continuación, el servidor recursivo solicita el registro DNSKEY al servidor .com.
  4. El servidor .com responde con el registro DNSKEY y el registro RRSIG DNSKEY correspondiente.
Steps 7 to 10 of DNSSEC resolution and validation
  1. A continuación, el servidor recursivo solicita el registro DS de .com a los servidores raíz.
  2. Los servidores raíz devuelven el registro DS y el registro RRSIG DS correspondiente para .com.
  3. A continuación, el servidor recursivo solicita el registro DNSKEY de la raíz.
  4. El servidor raíz devuelve el registro DNSKEY y el registro RRSIG DNSKEY correspondiente para la raíz.
  5. Por último, el servidor recursivo utiliza el ancla de confianza configurada para validar el registro DNSKEY y el registro RRSIG DNSKEY correspondiente para la raíz. Los resolutores compatibles con DNSSEC ya tienen incorporada la clave necesaria para validar las respuestas de los servidores raíz.
Steps 11 to 15 of DNSSEC resolution and validation

Respuestas almacenadas en caché

Estos pasos abarcan la primera consulta de una zona si la respuesta aún no está almacenada en caché. Una vez almacenada en caché, toda la validación a lo largo de la cadena hasta la raíz ya se ha validado. En ese caso, si un cliente solicita un registro A diferente de example.com, solo tiene que validar la firma del registro A.

La serie de seminarios web de 10 partes del Internet Systems Consortium sobre DNSSEC analiza el proceso en profundidad. Su cuarto seminario web sobre resolución y validación de DNSSEC resulta muy útil para obtener más información.

Interrupción de los ataques de «hombre en medio»

Con el DNSSEC activado durante un intento de ataque de tipo «hombre en el medio», el resolutor de validación rechaza la respuesta de un servidor malicioso porque este no dispone de los datos criptográficos que validan su origen. El resolutor no devuelve la respuesta falsa al cliente y este no es redirigido al sitio malicioso.

Además, DNSSEC proporciona la prueba de inexistencia (PNE). Con la PNE, las zonas firmadas con DNSSEC pueden demostrar que una respuesta NXDOMAIN (una respuesta del tipo «ese sitio no existe») es legítima. Esto impide que un atacante inyecte una respuesta NXDOMAIN falsa durante un ataque. Aunque no redirigirá al cliente a su servidor malicioso, hará que parezca que estás desconectado para cualquiera que se encuentre detrás del servidor con caché afectado.

BlueCat facilita la implementación de DNSSEC

A la hora de decidir cómo implementar DNSSEC, es fácil subestimar su complejidad y la cantidad de conocimientos que requiere. Sin una infraestructura DNS centralizada y automatizada, resulta aún más complicado.

Como mínimo, la implementación manual requiere el mantenimiento de los registros y la renovación de claves (actualización periódica de las claves para reducir el riesgo de que se vean comprometidas).

Pero, además, hay pasos importantes, como volver a firmar conjuntos de registros (RRsets) y zonas, que deben realizarse cada vez que se produce un cambio en una zona. Si alguno de estos pasos se realiza de forma incorrecta, la zona dejará de estar disponible. El mantenimiento de la cadena PNE es también una de las partes más tediosas —y en las que es más fácil cometer errores— de la gestión manual de las zonas firmadas con DNSSEC.

Cuando centralizas tu infraestructura DNS con BlueCat, estas tareas relacionadas con DNSSEC se realizan en segundo plano, de forma automática:

  • Generación de pares de claves criptográficas
  • Generación y mantenimiento de la cadena PNE (con registros NSEC o NSEC3) para cada registro de la zona
  • Firma de zonas y de todos los registros DNS asociados
  • Generación de registros DS para zonas principales
  • Renovación fluida de las KSK y las ZSK según un calendario definido
  • Generación de nuevas KSK o ZSK en caso de una renovación de emergencia
  • Supervisión del éxito y el fracaso en la generación de claves
  • Generación manual de nuevos pares de claves en caso de que la generación automática no se haya realizado correctamente

BlueCat simplifica el DNSSEC al permitir a los clientes configurarlo fácilmente desde una plataforma central. Descubre cómo puede ayudarte la plataforma BlueCat.