DNSSEC para una navegación más segura

En Internet, tanto los usuarios como las páginas comparten la misma forma de identificarse: mediante una dirección IP única, compuesta de varias cifras. Para poder introducir en el navegador un nombre de dominio como ionos.es, existe el denominado sistema de nombres de dominio o DNS, responsable de la resolución de nombres y uno de los servicios más importantes en redes basadas en IP. Compuesto por diferentes servidores de nombres (o servidores DNS), el sistema de nombres de dominio traduce nombres en direcciones IP y permite al programa-cliente establecer el contacto deseado.

Sin embargo, la comunicación entre el servidor de nombres y el cliente implica un gran riesgo para la seguridad, ya que, al no comprobarse la identidad del emisor, el receptor no puede saber si la respuesta del DNS realmente proviene del servidoral que se preguntó. Entre el servidor de nombres y el cliente, un atacante podría proporcionar al receptor una dirección IP falsa. El mecanismo de protección DNSSEC, implantado en el dominio .es desde 2011, se desarrolló precisamente para solventar este problema.

Las extensiones de seguridad del sistema de nombres de dominio o DNSSEC por su nombre en inglés (Domain Name System Security Extensions) constituyen una serie de especificaciones que completan el sistema de nombres de dominio con un método de autenticación de la fuente de donde proviene la información para garantizar la veracidad y la integridad de los datos.

Desde que se comprobara que la primera versión de 1999 ya no era idónea para grandes redes, tuvieron que pasar aún algunos años hasta que las extensiones de seguridad del DNS fueran finalmente publicadas en los tres RFC (Request for Comments) RFC 4033, RFC 4034 y RFC 4035 y, a partir de ahí, estandarizadas. En 2010, esta técnica se desplegó por primera vez en el nivel de la raíz de Internet, concretamente en los trece servidores de nombres de raíz responsables de la resolución de los dominios de nivel superior. DNSSEC se apoya en un sistema criptográfico de clave pública, un procedimiento de encriptado asimétrico por el cual las dos partes implicadas, en lugar de compartir una clave secreta común, recurren a un par de claves consistente en una pública (public key) y una privada (private key). La clave privada otorga una firma digital a los registros de recursos (resource records) que contienen toda la información del DNS. El programa-cliente puede verificar esta firma con ayuda de la clave pública, confirmando así la veracidad de la fuente.

Cada servidor de nombres en el DNS es responsable de una zona determinada. En el archivo de esta zona, el servidor gestiona una lista completa de todos los registros de recursos que la describen, protegida con una clave de zona propia. Todos los servidores de nombres cuentan con su propia clave. La clave pública de la clave de zona está integrada en el archivo de la zona como DNSKEY Resource record y con su ayuda se firman todas las unidades de información. Es así como se originan los RRSIG Resource records, que son entregados junto a los registros originales. Esta combinación se mantiene, independientemente de si se almacena en caché o se transfiere a un servidor DNS diferente, para ser entregada, por último, al cliente solicitante, que puede validar la firma con ayuda de un “resolver” y de la clave pública.

Para facilitar la gestión de las claves y crear una cadena de confianza (chain of trust) existe, además de la clave de zona, una clave sintácticamente idéntica que verifica adicionalmente su autenticidad (una clave para verificar a otra clave). Un valor hash de esta clave se guarda en una entrada de su zona como trusted key. El “resolver” solo puede conocer la clave pública del nivel de raíz.

Los resolvers son módulos de software de los clientes que pueden solicitar información a los servidores de nombres de manera iterativa o recursiva. En el primer caso, el resolver obtiene la información solicitada del servidor al que la solicitó o una referencia al próximo servidor de nombres donde la puede conseguir y así procede hasta que resuelve la dirección. Los resolvers que trabajan recursivamente, también llamados stub resolvers, típicos de clientes tan habituales como los navegadores web, envían una solicitud al servidor de nombres al cual está subordinado en la red local o en la red del proveedor. Si no se encuentra la información solicitada en la base de datos, la responsabilidad de la resolución de esta dirección recae en este servidor, que envía entonces, por su parte, solicitudes iterativas para resolverla.

Para poder gozar de las ventajas del protocolo DNSSEC es necesario disponer de un resolver que pueda validar y evaluar toda la información adicional generada. Con esta finalidad, el resolver ha de soportar los mecanismos de extensión para DNS (EDNS, Extension Mechanisms for DNS). Solo así puede ser activada la validación en el encabezado del DNS.

La expansión de DNSSEC es muy difícil debido, principalmente, a la complejidad de sus requisitos, pues tanto el administrador de una página como el usuario han de soportar la técnica. Los propietarios del dominio dependen también de que el registrador soporte este método de encriptado. Los usuarios no tienen ninguna influencia sobre la protección o no de una página mediante firmas de DNSSEC y necesitan, además, un resolver que la valide.

En definitiva, para beneficiarse de la extensión de seguridad DNSSEC, hay que:

• administrar un resolver propio como Bind,
• usar extensiones para el navegador como el DNSSEC Validator
• o buscar un proveedor que verifique las firmas DNSSEC.

En cualquier caso, hay que observar que DNSSEC solamente autentifica la resolución de nombres, no los datos transmitidos, los cuales quedan sin proteger. Como consecuencia, es obligatorio combinarlo con protocolos de transmisión encriptada como TSL.

Algunos problemas responsables de la lentitud en la aceptación de estas especificaciones pueden ser:

• Una mayor sobrecarga en el servidor de nombres que aumenta la probabilidad de ataques de denegación de servicio (Denial of Service), ocasionando la pérdida de disponibilidad de una web.
• Como las claves públicas están repartidas en el DNS, se pone en peligro la cadena de confianza.
• Sin un resolver propio cabe la posibilidad de un ataque entre el cliente y el servidor de nombres del proveedor, aunque este esté capacitado para verificar firmas DNSSEC.

Otros puntos débiles, como el llamado Zone Walking (enumeración de zona), ya han obtenido reacción. En este tipo de amenaza, el atacante puede interpretar el contenido completo de una zona protegida con DNSSEC. Para protegerlos, los nuevos resolvers nombran a los registros de recursos con un valor hash en lugar de con un texto.