Introducción a DNSSEC

Casi cualquier usuario de Internet, no digamos ya administradores de sistemas, sabe lo que es el DNS. El Domain Name System consiste, básicamente, en una base de datos distribuída de cobertura mundial que, para el común de los mortales, se encarga de convertir nombres aptos para seres humanos a direcciones IP, que es lo que realmente entiende un ordenador. Así, podemos escribir en nuestro navegador http://blog.jcea.es/, en vez de pedirle que se conecte a la dirección IP 10.71.238.11.

Teniendo en cuenta la longevidad y la sencillez del sistema DNS, resulta sorprendente (demos a sus creadores el crédito que se merecen) lo bien que suele funcionar en la práctica. De todos los protocolos de nivel de aplicación de Internet, el DNS debe ser el más fundamental y el único que no falla nunca :-).

Al menos no falla de forma accidental, porque siendo un protocolo nacido en una era más pacífica y tranquila de Internet (como ocurrió con el correo electrónico), la seguridad no entraba dentro de los puntos a ser considerados. Pero hoy en día Internet es una infraestructura crítica y zona de guerra permanente. El DNS tradicional es muy vulnerable a ataques y todos los demás servicios se sustentan en el DNS. Los cimientos están podridos.

Hace 10 años, en 2004, se publicó el RFC 3833: Threat Analysis of the Domain Name System (DNS). En él se describen modelos de ataque inherentes al propio protocolo DNS. Durante los años se han sucedido los ataques al protocolo DNS, débil por diseño. Y una vez que se consigue contaminar la caché de un servidor DNS importante, como el de un gran ISP, se puede afectar al funcionamiento Internet de millones de usuarios durante días, aunque el ataque haya durado unos pocos segundos. Dan Kaminsky, por ejemplo, se hizo famoso en 2008 por demostrar que los ataques de DNS spoofing eran prácticos. Y, de hecho, fáciles de llevar a cabo. Una búsqueda simple en Google muestra decenas de miles de tutoriales sobre cómo hacerlos.

No son ataques teóricos. Un ejemplo que ha transcendido a los medios: Google’s Malaysian Domains Hit with DNS Cache Poisoning Attack. El reciente caso de censura de Twitter en Turquía muestra a las claras la fragilidad de la infraestructura DNS actual y el valor que puede aportar DNSSEC.

El hecho es que el protocolo DNS es inseguro por diseño. Pero todo Internet depende de su buen funcionamiento.

DNSSEC

El RFC 2065: Domain Name System Security Extensions, hoy obsoleto, se publicó en 1997. Definía una extensión opcional del sistema DNS, denominada Domain Name System Security Extensions. Este RFC ha evolucionado y se ha convertido en el actual protocolo DNSSEC.

DNSSEC permite que los registros DNS se firmen digitalmente por el origen. De esta forma un cliente DNS puede verificar que los datos DNS que ha obtenido no han sido alterados de ninguna manera. Es decir, DNSSEC proporciona autenticación e integridad.

El logro es extraordinario. Y las dificultades para implantarlo también lo están siendo.

La primera propuesta DNSSEC se publicó en 1997, pero no fue hasta 2010 cuando se firmó la zona raíz del DNS. Aunque ya existían pruebas regionales (el primer país en desplegar DNSSEC fue Suecia, en octubre de 2005) firmar la zona raíz permite que todo el árbol DNSSEC se valide a sí mismo sin tener que recurrir a anclas de confianza gestionadas manualmente o mediante servicios como el DNSSEC Look-aside Validation (DLV) de ISC (creadores de BIND, el servidor DNS más popular del mundo)

Una vez implantado en la zona raíz DNS, ya solo quedaba que los gestores de cada dominio lo fuesen activando para su zona respectiva. La zona *.au (Australia) se firmó el 1 de enero de 2011. La zona *.com se firmó el 1 de abril de 2011. La lista ha crecido rápido.

Andorra activó DNSSEC en mayo de 2014. España entrará en el club el 8 de julio de 2014. Por fin.

Estructura de firma y verificación DNSSEC

Para poder utilizar DNSSEC se requiere lo siguiente:

  1. En la parte del servidor:

    1. Los servidores DNS (primario y secundarios) que hospedan el dominio deben soportar DNSSEC.

    2. El administrador del dominio debe generar una clave criptográfica para firmar su zona DNS [1].

    3. Dichas claves se suministran al software DNS del servidor primario y se firma la zona.

    4. La clave pública de la zona se comunica a la zona padre [2], que la añade a la información que proporciona sobre nuestro dominio. Como por ejemplo, los servidores DNS que se hacen responsables del mismo.

      • Si la zona padre no soporta DNSSEC, todavía podremos desplegar DNSSEC de forma parcial en nuestro dominio empleando mecanismos como DNSSEC Look-aside Validation (DLV).

        Tenía planificado un artículo sobre esto, pero con el despliegue inminente de DNSSEC en la zona *.es soy un hombre feliz y ya no necesito lidiar personalmente con DLV.

    Con lo anterior estaremos firmando nuestra zona DNS, nuestro dominio, y proporcionamos información al árbol DNS para que cualquiera pueda validarnos.

  2. En la parte del cliente final:

    1. El cliente debe usar un sistema de resolución DNS compatible con DNSSEC. Si no es así, la información DNSSEC sencillamente se ignora (de hecho, ni siquiera se pide a los servidores DNS. Aquí entra la compatibilidad) [3].

    2. En el caso de soportar DNSSEC, a medida que se recorre el árbol DNS para obtener la resolución de un nombre de dominio, se van descargando también las claves de las zonas DNS que se van atravesando, y el sistema de resolución DNS verifica que las firmas DNSSEC son correctas.

      • Si durante la resolución de un nombre atravesamos una zona DNS sin soporte de DNSSEC lo sabremos porque su zona padre así nos los indicará (nos indicará que no hay claves criptográficas para esa zona). Aquí se desactivará la verificación DNSSEC. Durante muchos muchos años se permitirá la coexistencia de dominios con y sin DNSSEC, por una cuestión de compatibilidad.

        No es posible que un atacante nos engañe y simule que una zona DNSSEC no está firmada, porque tendría que manipular las respuestas del servidor DNS del dominio padre que, a su vez, están también firmadas con DNSSEC. Y así, toda la cadena de resolución superior.

        Una zona padre maliciosa puede tomarnos el pelo, pero en Internet eso sería relativamente fácil de detectar simplemente comprobando desde diferentes sitios qué claves de anclaje de zonas nos suministra.

        La confianza en las entidades registradoras de nombres de dominio será tema de un futuro artículo.

Como puede deducirse de la explicación anterior, una de las características fascinantes de DNSSEC es que puede desplegarse de forma gradual, dominio a dominio.

Algunos de los puntos negativos de DNSSEC son que es complejo de gestionar, que las transferencias de zona entre el DNS primario y los secundarios son más pesadas, y que las respuestas DNSSEC son mucho más voluminosas. La carga de CPU también es mayor, pero el sistema está diseñado para que el grueso de la carga la tengan los clientes DNSSEC, lo que escala infinitamente mejor que si el coste criptográfico lo paga el servidor DNS.

[1]

En realidad DNSSEC maneja dos claves, la ZSK: Zone Signing Key y la KSK: Key Signing Key. De momento no nos preocupamos de ello. Será tema de un futuro artículo.

Tampoco tocamos el tema del key rollover. Otro artículo pendiente :-).
[2] Cómo notificar a la zona padre nuestra clave pública es material de otro artículo.
[3] El uso masivo de Google como servidor DNS (el popular 8.8.8.8) tiene un impacto importante en la difusión y la seguridad de DNSSEC, tanto bueno como malo. Artículo futuro.

Conclusión

DNSSEC ha llegado para quedarse. Desplegarlo no es complejo y la mejora de seguridad es inmensa. Tanto es así que permite utilizar el DNS que, recordemos, es una base de datos jerárquica distribuída, como una fuente de información confiable. Esto abre la puerta a nuevos servicios y protocolos, como DANE: DNS-based Authentication of Named Entities, herramientas antispam o SSHFP.

Es cierto que el soporte en la parte cliente está en pañales y que la mayoría de los usuarios no se van a beneficiar a corto plazo de esta mejora de seguridad, pero se trata del huevo y la gallina y alguien tiene que dar el primer paso. Y no olvidemos que la situación puede cambiar de la noche a la mañana simplemente con una actualización del sistema operativo de nuestro ordenador, o del firmware del router ADSL.

Otro detalle a tener en cuenta es que DNSSEC proporciona autenticación e integridad, pero no confidencialidad [4]. Es decir, las peticiones DNSSEC son visibles para cualquiera que esté espiando la red, como ocurre con el DNS tradicional.

Cualquier administrador de DNS debería pensar y argumentar seriamente por qué todavía no está usando DNSSEC. Tal vez las excusas sean simplemente eso, excusas.

[4]

Existen otras propuestas de extensiones de seguridad para el DNS que proporcionan también confidencialidad. Por ejemplo, DNSCurve. Lamentablemente su uso es extremadamente minoritario. Hoy por hoy, DNSSEC es la única alternativa realista para proporcionar seguridad al DNS a nivel global.

Personalmente espero que esta funcionalidad se incorpore en una evolución futura de DNSSEC.

Agradecimientos

  • Elena Marcela González Gómez.
  • Juan Pedro Cerezo.
  • Fernando García Fernández.
  • Iñigo Ortiz de Urbina.
  • João Damas.
  • Luis González Fernández.