DNSSEC (1): qué es DNSSEC

Tarsis.net, 20 de abril de 2024

Créditos de la imagen: Google Deepmind

En el centro de la vasta red de información que es Internet hay un elemento esencial para que la mayor parte de las transacciones que se realizan puedan tener éxito: el Sistema de Nombres de Dominio (DNS). Sin embargo el DNS es un servicio Internet de los más antiguos (data de mediados de los años 80) y su concepción original estaba pensada para entornos menos hostiles que los actuales. Como consecuencia de ello a principios de este siglo se vio la necesidad de desarrollar las extensiones de seguridad de DNS que hoy se conocen como DNSSEC.

ATENCIÓN: Este artículo presupone un conocimiento del funcionamiento del servicio de resolución de nombres de dominio (DNS) convencional y de los principios básicos de la criptografía asimétrica.

¿Cuáles son los problemas de DNS que DNSSEC pretende resolver?

El sistema de nombres de dominio (DNS) es una parte fundamental de la infraestructura de Internet, actuando como una guía para dirigir el tráfico web hacia los destinos correctos. En Internet hay innumerables artículos que explican cómo funciona el servicio tradicional de DNS, por lo que no vamos a explicar aquí su funcionamiento.

Sin embargo, como cualquier sistema, el DNS no está libre de posibles problemas. Los años transcurridos desde su puesta en marcha han puesto de manifiesto los diferentes tipos de vulnerabilidades que suelen afectarle:

• Suplantación de DNS (DNS Spoofing): En este tipo de ataque un atacante manipula las respuestas del servidor DNS para redirigir a los usuarios a sitios web maliciosos o fraudulentos¹. Esto puede llevar a la suplantación de identidad, robo de datos y otros tipos de ataques.
• Envenenamiento de caché (Cache Poisoning): Los servidores DNS utilizan cachés para almacenar temporalmente la información de resolución de nombres de dominio. En un ataque de envenenamiento de caché, un atacante introduce información falsa en la caché de un servidor DNS, lo que puede resultar en la devolución de datos incorrectos a los clientes del servidor de DNS y que como consecuencia estos dirijan su tráfico hacia destinos no deseados.
• Ataques de denegación de servicio (DoS): Los ataques de denegación de servicio dirigidos específicamente al DNS de una zona pueden provocar la inaccesibilidad del servicio de DNS y, subsidiariamente, de los demás servicios del dominio (web, correo, API, etc).
• Amplificación de DNS: Se aprovecha de servidores DNS de terceros, abiertos y mal configurados, para amplificar el tráfico hacia un objetivo específico. Los atacantes envían consultas falsas a los servidores DNS abiertos, que luego responden con grandes cantidades de datos hacia la dirección IP de la víctima, abrumando su capacidad de red y provocando una denegación de servicio distribuida (DDoS).
• Ataques de desbordamiento de búfer (buffer overflow): En este tipo de ataque un atacante envía datos especialmente diseñados para sobrepasar los límites de almacenamiento en memoria del servidor DNS y ejecutar código malicioso en el sistema. Esto puede resultar en la toma de control del servidor y el acceso no autorizado a la red.

Existen otros tipos de vulnerabilidades ligadas al DNS y a riesgos de seguridad, pero en lo que atañe a DNSSEC, éste soluciona los problemas derivados de los dos primeros casos (suplantación y envenenamiento). Los otros problemas son respectivamente casos que deben resolverse mediante un correcto filtrado de red y una buena escritura y control de calidad del software del servidor de DNS.

El tipo de problema que trata de resolver DNSSEC es: cómo estar seguros de que los datos que nos devuelve el servidor de DNS tras una consulta son auténticos (provienen de una fuente legítima) y no han sido alterados en tránsito.

Es importante observar que DNSSEC no proporciona privacidad en las consultas que nuestro navegador u otro tipo de cliente pueda hacer al servidor de DNS. Las consultas de DNS se realizan en claro² y las respuestas vuelven también en claro. Esto no varía en DNSSEC, que se comportará de la misma manera.

Para solventar el problema de la privacidad de las consultas de DNS hay que recurrir a otro tipo de soluciones técnicas como son DNS over HTTPS (DoH) o DNS over TLS (DoT), que realizan consultas de DNS encapsulándolas dentro del protocolo HTTPS o TLS, que sí ofrecen privacidad.

Cómo funciona DNSSEC: Autenticación criptográfica de datos DNS

DNSSEC, o Extensiones de Seguridad del Sistema de Nombres de Dominio, emplean la criptografía asimétrica (un par de claves privada/pública) para firmar las respuestas a las consultas de DNS. De esta manera se garantiza que el emisor de la respuesta es un servidor de DNS autoritativo para ese dominio y se permite al cliente verificar que la respuesta no ha sido alterada en tránsito.

La clave privada permanece siempre secreta, en poder del servidor de DNS y sirve para encriptar las respuestas, mientras que la clave pública es universalmente accesible a través del DNS mediante un registro de tipo DNSKEY y sirve para desencriptar las respuestas. Esta técnica criptográfica garantiza la autenticidad y la integridad de los datos transmitidos a través del DNS.

Al igual que ocurre con las autoridades de certificación (CA) en el tráfico HTTPS, se requiere la intervención de una autoridad superior, que se articula en forma de una cadena de confianza. Nuestra autoridad de registro de ese dominio de primer nivel (que debe soportar DNSSEC) conserva un hash de la clave pública (DNSKEY) y que hace público mediante un registro de DNS de tipo DS. Esto crea una cadena de confianza desde arriba hacia abajo en la que un tercero actúa como validador de la información que envía el servidor de DNS en su respuesta.

Veamos un ejemplo: si utilizamos la herramienta host para consultar el DNS para conocer la dirección del nombre de servidor tarsis.net, su respuesta nos devuelve un registro de DNS de tipo A (dirección IPv4) de esta manera:

$ host -t a tarsis.net
tarsis.net has address 66.39.31.59

La herramienta host no proporciona ninguna verificación de la información que nos haya proporcionado el servidor de DNS que haya atendido esa pregunta. Simplemente nos devuelve la información que hemos solicitado (direcciones IPv4 correspondientes a un nombre de host), y lo hace recurriendo a los registros que proporciona el DNS tradicional.

Cuando un servidor DNS autenticado con DNSSEC responde a una consulta de resolución de nombres de dominio, incluye una firma digital junto con los registros DNS, añadiendo a la respuesta un registro de tipo RRSIG (Resource Record SIGnature). Esta firma digital se genera utilizando la clave privada del servidor DNS para encriptar un hash de los datos de la respuesta. Los clientes pueden verificar esta firma utilizando la clave pública correspondiente, que está disponible a través de registros DNS especiales llamados DNSKEY, y comprobando la validez de ese registro DNSKEY recurriendo al registro DS que está almacenado y públicamente accesible en los servidores autoritativos del dominio de primer nivel (TLD), en este caso .net. Si todo cuadra la solicitud será tenida por válida y si hay discrepancias se considerará una respuesta no segura.

Para comprobar esto vamos a utilizar la herramienta delv (otra herramienta popular para hacer consultas DNSSEC es drill):

$ delv tarsis.net -t a
; fully validated
tarsis.net. 2255 IN A 66.39.31.59
tarsis.net. 2255 IN RRSIG A 13 2 3600 20240411000000 20240321000000 49610 tarsis.net. vojYWCysD6m0NbJbVuOwpsLSErzlWYbx4Z5DRBQDIAjWiDcCH0ryR+wa EY5neXzfrCPou58CXi1CqzoseJSx3w==

Aquí podemos ver que, además de proporcionarnos el registro A con la dirección IP del servidor tarsis.net, el servidor de DNS nos está devolviendo también un registro RRSIG conteniendo la firma digital de los datos anteriores.

Ahora queda que el cliente verifique que efectivamente la respuesta es legítima. Para ello hará uso de la clave pública del dominio, que está accesible para todo el mundo en la propia zona de DNS:

$ delv tarsis.net -t DNSKEY
; fully validated
tarsis.net. 1250 IN DNSKEY 257 3 13 a07bfNpPv9kgh6nBtS5o7qfa/hR/xdiV/sZQTv75r3JQecufNg6t8A8C Je4Mg/CX8RC2eeHjwO0STBOO7z1m/Q== ; KSK; alg = ECDSAP256SHA256 ; key id = 49610
tarsis.net. 1250 IN RRSIG DNSKEY 13 2 3600 20240411000000 20240321000000 49610 tarsis.net. 8ckXaY4Tp3pjEP/z3yhIwyyAuNMveEMZQAEHK8SG5RHwiWrWdkcMN4eX mMoEHHfO0AH6mC7GAAhMVtPFtJFAKg==

Observe también que la propia consulta sobre la clave pública está también firmada (registro RRSIG).

¡Un momento, un momento! Si es el propio servidor de DNS el que nos ofrece la clave pública y además está firmando las respuestas, ¿no es eso un agujero de seguridad para que cualquiera suplante al servidor de DNS auténtico, utilice su propio par de claves y nos engañe a todos?

¡Exacto!, por eso se requiere el concurso de un tercero, los servidores de DNS de la autoridad del dominio de primer nivel (en este caso .net), que envían también la clave pública (DNSKEY) del dominio en cuestión, firmada a su vez, en forma de registro DS (Digital Signature). De esta forma la autoridad de registro del dominio de primer nivel actúa como notario en la verificación de la propia clave pública del dominio³:

$ delv tarsis.net -t DS
; fully validated
tarsis.net. 10665 IN DS 49610 13 2 B719DCAFB08898CA5756806C3FD1779C6498A9CC3357D2FE666A9732 13174508
tarsis.net. 10665 IN DS 49610 13 4 C6087E38355DF5D9144BD845811675D38C3A95C71ECA38F60A7B6553 EEAE1DDD897E2662835F79D61D1C5D5535320A66
tarsis.net. 10665 IN RRSIG DS 13 2 86400 20240402070154 20240326055154 34730 net. dV33zMgw663xpoEn4YT6oxYo4/xH6+UzBfGMyMredkv9rB6WbhtOuZvE 3W1bA2huD/CX4hCAf3WqAoYOrFPcIQ==

Pero volvamos a la petición de DNS que nos ocupa. El proceso de verificación de los datos cuando estos llegan al cliente se lleva a cabo según el siguiente proceso:

1. El servidor de DNS calcula un valor hash de los datos enviados y encripta el digest resultante con la clave privada del dominio, lo que constituye una firma digital que se adjunta a la respuesta (RRSIG).
2. El cliente recibe los datos, y rehace el hash sobre los datos obteniendo un digest; y por otro lado desencripta la firma con la clave pública del dominio (DNSKEY), lo que le proporciona un segundo digest. Si ambos valores coinciden, esto confirma que los datos no han sido alterados en tránsito y que provienen de una fuente confiable. Si no coinciden, entonces la validación se dará por fallida y habrá que sospechar que algo peligroso puede estar ocurriendo con ese dominio.

¡Guau! Menudo viaje, pero eso no es todo, porque DNSSEC debe también resolver un problema ligeramente más enrevesado: ¿Cómo demostrar que un nombre de servidor o cualquier otro tipo de registro no existe? No se pierda el siguiente episodio…

La no existencia certificada y el siguiente en la lista: NSEC y NSEC3

Hasta el momento hemos estado hablando de una forma más segura en la que un servicio de DNS certifica el resultado de una consulta sobre un registro de recurso (RR) pero, ¿se le ha pasado por la cabeza que pueda ser necesario certificar que determinado recurso no exista? Imagínese que alguien cree un servidor que responda al nombre web.sudominio.com (en lugar de su sitio legítimo sudominio.com o www.sudominio.com), y que se las arregle para envenenar el DNS de su zona y hacer que el tráfico que debería ir a su web legítima sea en realidad dirigido a la web fraudulenta. ¿Puede DNSSEC ayudarnos a prevenir ese caso?

Efectivamente, uno de los tipos de registro que brinda DNSSEC es la negación de existencia. El DNS tradicional ha venido ofreciendo un código de respuesta NXDOMAIN (Non-eXistent DOMAIN) en estos casos, pero DNSSEC va más allá, certificando que un determinado registro no existe. Para ello utilizó inicialmente un tipo de respuesta NSEC (Next SECure) en el que el servidor de DNSSEC certifica mediante firma de la respuesta que un determinado registro no existe, y además proporciona el nombre del siguiente servidor legítimo que se encuentra en esa zona de DNS. Esta última parte resultó pronto evidente que era un punto débil, cuando se explotó para recorrer (zone walking) una zona de DNS y averiguar otros nombres de servidor disponibles.

Esto puso de relieve la necesidad de mejorar NSEC para que las respuestas de «siguiente servidor» fueran también encriptadas con un hash y evitar así su explotación, lo que dio lugar a la aparición de NSEC3, que se utiliza hoy en día.

Resumen de registros DNSSEC: DNSKEY, DS, RRSIG, NSEC/NSEC3

Para poder tener una idea más compacta de los nuevos tipos de registros que encontraremos en DNSSEC le ofrecemos aquí una lista de esos tipos y su función:

• RR (Registro de recurso): Cualquier tipo de registro que ofrezca información sobre un recurso, como por ejemplo A, AAAA, CNAME, MX, TXT, etc.
• DNSKEY: Claves pública ofrecidas por servidores DNS autorizados, utilizadas para validar firmas de datos DNS.
• DS (Firmante de delegación): Digests de las DNSKEY de la zona que están almacenadas en los servidores de DNS del dominio de primer nivel (TLD). Esto establece una cadena de confianza desde la zona padre a la zona hija.
• RRSIG (Firma de registro de recursos): Acompañan a los registros de recursos DNS y contienen firmas digitales de los recursos que se listan en la respuesta.
• NSEC y NSEC3: Sirven para certificar la no existencia de un nombre de host y para proporcionar el nombre del siguiente host válido (en orden alfabético).

Una infraestructura más segura para transacciones cada vez más vitales

Como decíamos al principio de este artículo, el servicio de DNS es un servicio que forma parte de la infraestructura más básica de Internet. El tráfico web, el correo electrónico, las redes sociales, las aplicaciones móviles, los servicios de streaming, las API, todos ellos, y los que vengan, van a requerir un servicio para determinar información a partir un nombre de host.

Es difícil exagerar la importancia que para una organización tiene disponer de una base segura para sus transacciones Internet. Grandes empresas, tiendas de comercio electrónico, medios de comunicación, instituciones, empresas de transporte o del sector logístico… ¿quién puede arriesgarse a que alguien suplante a sus servidores?

¿Su dominio necesita un DNS rápido, seguro y confiable? Tarsis.net proporciona servicios de consultoría para la adecuación de DNS a los estándares modernos, alojamiento gestionado de DNS anycast y monitorización. Infórmese.

¹ Con la excusa de la seguridad de sus clientes algunos proveedores de acceso Internet interceptan todo el tráfico DNS y lo dirigen a sus propios servidores de DNS, lo cual constituye una suplantación del servicio.

² El formato de pregunta y respuesta de DNS no es un formato de texto, sino binario, pero eso no significa que esos datos no sean accesibles a terceras partes que sean capaces de interceptarlas en tránsito.

³ Esta consulta nos devuelve dos registros DS, porque se ofrece la respuesta mediante digests que utilizan dos diferentes funciones criptográficas de hash (4 y 2, que se corresponden respectivamente con SHA-384 y SHA-256).