DNSSEC y la seguridad del DNS en tu red local

Informatec Digital » Recursos » DNSSEC y la seguridad del DNS en tu red local

Internet se sostiene sobre un puñado de piezas clave que casi nunca vemos, pero que están ahí cada vez que abrimos el navegador. Una de las más importantes es el sistema de nombres de dominio, y cuando hablamos de DNSSEC y seguridad en una red local, en realidad estamos hablando de blindar ese cimiento para evitar redirecciones fraudulentas, suplantaciones y otros ataques bastante serios.

Antes la prioridad era que todo funcionara y punto; hoy sabemos que eso no basta. El DNS nació en los años 80 sin pensar en ciberataques masivos, pero ahora necesitamos que, además de resolver nombres, valide la autenticidad e integridad de cada respuesta. Ahí es donde entra en juego DNSSEC y, más recientemente, propuestas como E-DNSSEC que buscan añadir también confidencialidad, algo clave si te preocupa la seguridad de tu red local o corporativa.

Qué es el DNS y por qué es tan crítico para la seguridad

El sistema DNS (Domain Name System) es la agenda telefónica de Internet: se encarga de traducir nombres fáciles de recordar (como www.ejemplo.es) a direcciones IP numéricas que entienden los equipos (por ejemplo, 192.168.2.15 o una IPv6). Sin este mecanismo, tendríamos que memorizar números en lugar de nombres, algo totalmente impráctico.

Esta infraestructura se organiza como una base de datos distribuida en forma de árbol, con una zona raíz en la parte superior, seguida de dominios de nivel superior (TLD como .es, .com, .org) y, debajo, dominios y subdominios. Cada porción de esa base de datos se denomina “zona” y se aloja en uno o varios servidores de nombres autoritativos, que son los que publican la información “oficial” de cada dominio.

Cuando tu ordenador, móvil o cualquier dispositivo quiere acceder a una web, empieza preguntando a un resolutor mínimo (stub resolver), que forma parte del sistema operativo. Este resolutor envía la consulta a un servidor DNS recursivo (habitualmente el de tu operador, de tu empresa o uno público como Google Public DNS, OpenDNS o Quad9). Este servidor recursivo se encarga de ir buscando la respuesta preguntando a varios servidores autoritativos hasta encontrar la IP correcta.

Los resolutores recursivos guardan en memoria caché las respuestas que obtienen para acelerar las siguientes consultas. Esto es muy eficiente, pero también abre la puerta a que un atacante pueda “envenenar la caché” del DNS y colar datos falsos, de forma que muchas peticiones posteriores se resuelvan con esa información manipulada sin que el usuario lo note.

El gran problema es que, en su diseño original, el DNS no tiene forma sólida de verificar la autenticidad de las respuestas. El resolutor básicamente comprueba que la respuesta parece venir de la misma dirección IP a la que preguntó, pero esa IP de origen se puede falsificar (suplantar) con relativa facilidad. Eso permite ataques de redirección silenciosa hacia sitios fraudulentos que imitan, por ejemplo, la web de tu banco.

Limitaciones de seguridad del DNS tradicional

El protocolo DNS fue creado en una época en la que la seguridad no era una preocupación central. Por eso, hoy sabemos que las consultas y respuestas DNS viajan en texto claro, sin cifrado, y que los datos de los registros pueden ser falsificados si no hay un mecanismo adicional de protección.

Esto abre la puerta a varios tipos de ataques, entre los que destacan el envenenamiento de caché DNS (DNS cache poisoning) y los ataques de intermediario (Man-in-the-Middle). En ambos casos, el atacante introduce respuestas falsificadas en el camino, haciendo que los usuarios acaben en webs bajo su control sin percibir nada raro, ya que el nombre del dominio mostrado en el navegador sigue siendo el legítimo.

Imagina que accedes a la web de tu banco: tu equipo pide al servidor recursivo la IP del dominio del banco, pero un atacante ha conseguido que ese recursivo acepte una respuesta falsa con la IP de una web idéntica pero controlada por él. El usuario introduce sus credenciales pensando que todo es normal, y el ciberdelincuente las recibe en claro para usarlas en el sitio real después.

Existen mecanismos como TSIG (Transaction Signatures), recogido en el RFC 2845, que sirven para proteger determinadas operaciones entre servidores DNS (por ejemplo, transferencias de zona entre servidores maestro y esclavo y actualizaciones dinámicas). TSIG permite que dos máquinas que comparten una clave secreta verifiquen la identidad del otro extremo y la integridad de los mensajes en tránsito.

Sin embargo, TSIG tiene un alcance muy limitado: no autentica el origen “real” de los datos DNS, solo asegura que el intercambio entre dos servidores concretos no ha sido manipulado. Si la información original de una zona ya estaba comprometida o se ha manipulado antes de llegar a esos servidores, TSIG no lo detecta. Por eso, aunque se usa de forma habitual para las transferencias de zona, no resuelve el problema de fondo de la autenticidad de los datos DNS publicados.

Qué es DNSSEC y qué aporta a la seguridad

Como respuesta a todas estas debilidades, se desarrollaron las Extensiones de Seguridad para el Sistema de Nombres de Dominio (DNSSEC, Domain Name System Security Extensions). DNSSEC no reemplaza al DNS clásico, sino que lo amplía con una capa de seguridad que permite verificar que los datos recibidos son legítimos y no han sido alterados.

DNSSEC se basa en criptografía de clave pública (criptografía asimétrica). Cada zona DNS dispone de un par de claves: una clave privada, que se mantiene en secreto, y una clave pública, que se publica en el propio DNS. El propietario de la zona utiliza la clave privada para firmar digitalmente los registros de esa zona; la clave pública se usa para comprobar esas firmas.

Cuando un servidor recursivo realiza una consulta sobre un dominio que utiliza DNSSEC, junto con la información habitual (por ejemplo, la IP asociada a un nombre) recibe también firmas digitales y claves públicas necesarias para su validación. El servidor recursivo valida las firmas con las claves públicas publicadas; si la comprobación es correcta, los datos se consideran auténticos y no modificados desde que se firmaron.

Si la validación falla, el resolutor entiende que algo va mal (por ejemplo, un intento de suplantación o una manipulación en tránsito) y responde al cliente con un código de error, típicamente SERVFAIL. De este modo, el usuario no llega a recibir datos potencialmente maliciosos, aunque desde su punto de vista lo único que verá es que la página “no carga” o da error.

DNSSEC introduce además el concepto de cadena de confianza, que aprovecha la jerarquía ya existente del DNS. La zona raíz firma las claves de los dominios de nivel superior (como .es, .com), estos firman las claves de sus dominios secundarios, y así sucesivamente, de manera que se puede validar cualquier dominio a partir de un único anclaje de confianza: la clave pública de la zona raíz.

Claves KSK y ZSK, registros y cadena de confianza

Para organizar mejor la seguridad, DNSSEC utiliza dos tipos de claves distintas: la Key Signing Key (KSK) y la Zone Signing Key (ZSK). Aunque técnicamente son iguales (criptográficamente hablando), su función es diferente dentro del sistema.

La clave ZSK es la que se usa para firmar todos los registros de recursos de la zona (A, AAAA, MX, etc.). Suele rotarse con cierta frecuencia para minimizar riesgos, ya que cualquier compromiso de esta clave afectaría a todos los registros de la zona. La KSK, en cambio, tiene como cometido principal firmar la propia clave de zona (ZSK), y su huella digital (hash) es la que se publica como registro DS (Delegation Signer) en la zona padre.

Gracias a esta separación de roles, cambiar la ZSK es más sencillo: basta con generar una nueva ZSK, firmarla con la KSK, publicarla en los registros DNSKEY de la zona y dejar que los resolutores actualicen su información. No es necesario tocar la zona padre, ya que el DS sigue apuntando a la misma KSK, que permanece estable durante más tiempo.

DNSSEC añade varios tipos de registros específicos al protocolo DNS, destinados a soportar la firma y validación de datos. Entre los más importantes se encuentran DNSKEY, RRSIG, DS, NSEC/NSEC3 y NSEC3PARAM. Todos ellos permiten construir la lógica de autenticación sin cambiar el funcionamiento básico de las consultas.

El registro DNSKEY almacena la clave pública de la zona, necesaria para verificar las firmas. El registro RRSIG contiene la firma digital asociada a un conjunto de registros concreto (un “Resource Record Set”). El registro DS es un hash de la DNSKEY de la zona hija que se publica en la zona padre y sirve como eslabón en la cadena de confianza.

Los registros NSEC y NSEC3 se utilizan para proporcionar denegación de existencia autenticada; es decir, para demostrar criptográficamente que un nombre de dominio o un registro no existe, evitando ataques en los que se intentan colar respuestas falsas indicando que algo no existe cuando en realidad sí existe (o al revés).

Cadena de confianza y validación de respuestas DNSSEC

La llamada cadena de confianza en DNSSEC se construye encadenando registros DNSKEY y DS desde la raíz hasta el dominio que queremos validar. El punto de partida es la clave pública de la zona raíz, que actúa como anclaje de confianza y suele estar configurada directamente en los resolutores recursivos.

Por ejemplo, si quieres validar un dominio como miweb.es, el proceso lógico sería: el resolutor confía en la clave pública de la raíz, que firma la clave de .es; la zona .es publica un registro DS correspondiente a la clave KSK de miweb.es; al validar ese DS con la clave de .es, el resolutor confía en la DNSKEY de miweb.es y, a partir de ahí, puede verificar los RRSIG sobre todos sus registros.

Si en algún punto de ese encadenado falta una firma correcta o no existe el DS donde debería, la cadena de confianza se rompe. En ese caso, el servidor recursivo que realiza la validación no considera los datos como seguros y, dependiendo de su configuración, o bien no responde con los registros solicitados o bien marca la respuesta como no validada.

Esta relación jerárquica implica también que, para que DNSSEC sea realmente efectivo, no basta con firmar únicamente tu zona: la zona padre (por ejemplo, .es) y la raíz también deben estar firmadas y con sus DS correctamente publicados. A día de hoy, la zona raíz del DNS y prácticamente todos los dominios genéricos de primer nivel (gTLD) y muchos dominios de país (ccTLD) ya están firmados.

Cuando un servidor recursivo con validación DNSSEC activa detecta que la firma no cuadra o que falta algún eslabón, la respuesta que devuelve al cliente suele ir acompañada de un código de error RCODE SERVFAIL. Para el usuario final puede resultar confuso (“la web no funciona”), pero desde el punto de vista de seguridad es una medida de protección frente a datos potencialmente manipulados.

DNSSEC introduce además dos características clave: la autenticación del origen de los datos, que permite comprobar que los registros proceden realmente de la zona esperada, y la protección de la integridad, que garantiza que la información no se ha modificado desde que fue firmada por el propietario de la zona con su clave privada.

Ataques que mitiga DNSSEC y relación con TLS/HTTPS

Implementar DNSSEC ayuda a proteger frente a varios tipos de amenazas muy habituales. En primer lugar, dificulta enormemente la suplantación de respuestas DNS, ya que el atacante tendría que generar firmas válidas sin conocer la clave privada de la zona, algo criptográficamente inviable si las claves se gestionan correctamente.

Además, DNSSEC reduce el riesgo de envenenamiento de caché en servidores recursivos, al impedir que se acepten respuestas manipuladas que no superen la validación de firma. También complica los ataques de intermediario (MITM) sobre el tráfico DNS, en los que un atacante modifica las respuestas en tránsito: si la respuesta no valida, el resolutor la descarta.

Es importante entender, eso sí, lo que DNSSEC no hace. Estas extensiones no están pensadas para cifrar el contenido de las consultas ni de las respuestas. Todo el tráfico DNS, incluso con DNSSEC, sigue viajando en texto claro salvo que utilices otras tecnologías complementarias (como DoT, DoH o propuestas tipo E-DNSSEC). DNSSEC se centra en que lo que recibes sea auténtico y no haya sido alterado, no en ocultar lo que preguntas.

Esto lo diferencia claramente de protocolos como TLS y HTTPS. Mientras que HTTPS cifra el tráfico entre el navegador y el servidor web para evitar que terceros espíen o modifiquen la comunicación, DNSSEC simplemente firma los datos DNS para detectar falsificaciones. Un sitio puede tener HTTPS sin DNSSEC o DNSSEC sin HTTPS, pero la combinación de ambos ofrece una protección mucho más completa frente a suplantaciones y espionaje.

Organismos como la ICANN y la IETF llevan años impulsando la adopción masiva de DNSSEC por parte de registros, registradores, ISPs y operadores de redes. El objetivo es que cada vez más zonas estén firmadas y que más resolutores validen activamente, de forma que el usuario medio, sin hacer nada especial, se beneficie de estas garantías criptográficas.

DNSSEC en dominios .es y obligaciones del propietario

En el caso concreto de España, la unidad de Dominios “.es” gestionada por Red.es ha incorporado desde hace tiempo tecnologías y procedimientos adicionales para mejorar la calidad y la seguridad del servicio DNS bajo el código de país .es. Entre estas medidas se encuentra la implantación de un protocolo de seguridad DNSSEC conforme a las especificaciones de la IETF.

Dominios .es se encarga de firmar la zona de nivel superior .ES y de obtener la autorización desde la raíz del DNS, integrándose así en la cadena de confianza global. Esto significa que, si eres titular de un dominio .es, puedes apoyarte en esa infraestructura para asegurar tu propio dominio con DNSSEC.

Como propietario de un dominio, el procedimiento general para habilitar DNSSEC pasa por asegurarte de que tus servidores DNS autoritativos publican la zona firmada. Normalmente, esto supone generar una clave pública para tu zona, firmar los registros, publicar la DNSKEY y, a continuación, enviar el material de la clave (o directamente el registro DS) al registro o a tu registrador para que cree el correspondiente DS en la zona padre.

En la práctica, muchos proveedores de alojamiento DNS y registradores ya ofrecen una opción bastante sencilla para activar DNSSEC, a veces tan simple como marcar una casilla en el panel de control. No obstante, puede existir un pequeño coste anual asociado a esa funcionalidad, dependiendo del proveedor y del nivel de servicio.

Una vez que la zona está firmada y el DS se ha publicado correctamente, tu dominio pasa a formar parte de la cadena de confianza de DNSSEC. Desde ese momento, las resoluciones DNS de tu dominio pueden ser validadas criptográficamente por los resolutores que tengan activada la validación DNSSEC, lo que aumenta la confianza de tus usuarios y reduce el riesgo de ataques de suplantación.

DNSSEC en la red local: validación del lado del usuario

Desde la perspectiva del usuario final o de una empresa preocupada por la seguridad de su red local, la pregunta clave es: ¿qué hace falta para beneficiarse de DNSSEC? La buena noticia es que no necesitas configurar nada en cada ordenador de forma individual, siempre que tu servidor DNS recursivo (el que usan tus equipos) valide DNSSEC.

Para ello, basta con que el proveedor de DNS que utilizas (tu ISP, un resolutor público o el DNS interno de tu organización) tenga un servidor recursivo con validación DNSSEC habilitada y correctamente configurada. Prácticamente todos los resolutores modernos soportan DNSSEC desde hace años; activarlo suele implicar solo unos pocos cambios en su archivo de configuración y la inclusión del anclaje de confianza de la raíz.

Una vez activada la validación, cuando uno de tus equipos en la red local realiza una consulta sobre un dominio firmado, el resolutor recursivo se encarga de verificar todas las firmas y la cadena de confianza antes de devolver la respuesta. Si algo no cuadra, no devuelve registros y el usuario ve un error, lo que en la práctica le impide conectar con un sitio posiblemente fraudulento.

Para comprobar si tu dominio está protegido por DNSSEC, existen diversas herramientas en línea, como DNSSEC Analyzer y otras utilidades de validación. Al introducir tu dominio, deberías ver registros como RRSIG (firmas criptográficas), DNSKEY (claves públicas) y DS (hash de la DNSKEY en la zona padre). Si la herramienta indica que no hay firma digital asociada a los registros, tu dominio se considerará “no firmado” o “inseguro”.

Si tras esta comprobación detectas que tu dominio o los DNS que usas en la red local no están aprovechando DNSSEC, lo recomendable es contactar con tu proveedor de servicios o con tu ISP para solicitar su activación. Si no ofrecen esta posibilidad, puede ser un buen momento para valorar un cambio a un proveedor que sí soporte la validación DNSSEC, elevando así el nivel de seguridad tanto para tu empresa como para tus clientes.

Limitaciones de DNSSEC: privacidad y otros aspectos

A pesar de todas sus ventajas, DNSSEC no es una solución mágica a todos los problemas de seguridad del DNS. Un aspecto fundamental es que no proporciona confidencialidad de las consultas. Los paquetes DNS, incluso con DNSSEC, siguen viajando en texto claro, por lo que cualquiera con acceso al tráfico (por ejemplo, en una red WiFi pública poco segura) puede ver qué dominios se están consultando.

Tampoco ofrece control de acceso ni defensa específica frente a ataques de denegación de servicio (DoS o DDoS). De hecho, al añadir más datos (firmas, claves, registros adicionales), aumenta el tamaño de las respuestas DNS, lo que puede ser aprovechado en ataques de amplificación si la infraestructura no está bien configurada y protegida.

Por otro lado, DNSSEC introduce cierta complejidad operativa: hay que gestionar pares de claves, rotar ZSK y KSK, coordinar la publicación de DS en la zona padre y vigilar que no haya desajustes que rompan la cadena de confianza. Un error en estos procedimientos puede provocar que un dominio deje de validar correctamente, generando fallos aparentes de “caída” del servicio.

Dentro del propio funcionamiento de DNSSEC existen bits de control en los mensajes (como el bit CD en consultas y el bit AD en respuestas) que influyen en cómo se realiza o se informa la validación. Un atacante que pudiera manipular estos bits en un entorno inseguro podría intentar degradar la protección que ofrece un resolutor recursivo, por lo que se recomienda que las comunicaciones entre resolutores y clientes que manejan DNSSEC se hagan sobre canales seguros.

A pesar de estas limitaciones, DNSSEC sigue siendo una pieza esencial para reforzar la autenticidad e integridad del DNS. Sin embargo, si se quiere ir un paso más allá y garantizar también la confidencialidad de las consultas, es necesario combinarlo con otras tecnologías o evolucionar hacia propuestas más avanzadas.

E-DNSSEC: hacia un DNS autenticado y cifrado

Para cubrir el hueco que DNSSEC deja en el terreno de la privacidad, se ha planteado el concepto de E-DNSSEC (DNSSEC encrypted). La idea de este enfoque es añadir cifrado a las consultas DNSSEC para que, además de estar autenticadas y firmadas, estén también protegidas frente a la inspección de terceros mientras viajan por Internet o a través de la red local.

El objetivo de E-DNSSEC es combinar las propiedades de DNSSEC (autenticidad e integridad) con mecanismos de cifrado que proporcionen confidencialidad de las consultas entre el cliente DNSSEC y el servidor DNSSEC. De esta forma, se incrementa el nivel de seguridad global del servicio DNS, evitando que observadores externos puedan ver qué nombres de dominio se resuelven.

El funcionamiento conceptual pasaría por analizar la consulta en el servidor recursivo, cifrarla antes de enviarla al servidor autoritativo y, una vez allí, descifrarla y procesarla de forma normal con DNSSEC. La respuesta, a su vez, se podría devolver firmada y cifrada de vuelta al recursivo o al cliente, manteniendo la confidencialidad en todo el trayecto.

Esta combinación permitiría que el mensaje DNS estuviera asegurado desde el inicio hasta el fin de la resolución: autenticado y con integridad gracias a DNSSEC, y protegido frente a miradas indiscretas gracias al cifrado adicional. En un contexto de redes locales o empresariales, un planteamiento de este tipo podría integrarse con otras soluciones de seguridad perimetral.

A día de hoy, propuestas como E-DNSSEC se enmarcan dentro del esfuerzo más amplio por reforzar la privacidad del DNS, junto con tecnologías como DNS over TLS (DoT) o DNS over HTTPS (DoH). La dirección de fondo es clara: el DNS del futuro debe ser tanto auténtico como confidencial, y no basta con resolver nombres de forma rápida; también hay que hacerlo de forma segura.

En un entorno donde cada vez hay más ciberataques sofisticados, suplantaciones y amenazas dirigidas a infraestructuras básicas, contar con DNSSEC ya es un requisito de seguridad importante para cualquier dominio serio, y avanzar hacia soluciones cifradas tipo E-DNSSEC o similares se perfila como un próximo paso lógico para reforzar aún más la protección de las redes, incluidas las redes locales.

Todo este ecosistema —desde DNS clásico hasta DNSSEC y las propuestas cifradas como E-DNSSEC— muestra que la seguridad del DNS no es un “extra” opcional, sino una parte central de la arquitectura de Internet y de cualquier red local moderna. Disponer de resolutores que validen, zonas firmadas, cadenas de confianza bien mantenidas y, en el futuro, canales cifrados para las consultas, marca la diferencia entre una red expuesta y una infraestructura preparada para los retos actuales y venideros.