¿Qué es DNSSEC?

En Internet, tanto los usuarios como las páginas comparten la misma forma de ide­n­ti­fi­car­se: mediante una dirección IP única, compuesta de varias cifras. Para poder in­tro­du­cir en el navegador un nombre de dominio como ionos.es, existe el de­no­mi­na­do sistema de nombres de dominio o DNS, re­s­po­n­sa­ble de la re­so­lu­ción de nombres y uno de los servicios más im­po­r­ta­n­tes en redes basadas en IP. Compuesto por di­fe­re­n­tes se­r­vi­do­res de nombres (o se­r­vi­do­res DNS), el sistema de nombres de dominio traduce nombres en di­re­c­cio­nes IP y permite al programa-cliente es­ta­ble­cer el contacto deseado.

Sin embargo, la co­mu­ni­ca­ción entre el servidor de nombres y el cliente implica un gran riesgo para la seguridad, ya que, al no co­m­pro­bar­se la identidad del emisor, el receptor no puede saber si la respuesta del DNS realmente proviene del servidor al que se preguntó. Entre el servidor de nombres y el cliente, un atacante podría pro­po­r­cio­nar al receptor una dirección IP falsa. El mecanismo de pro­te­c­ción DNSSEC, im­pla­n­ta­do en el dominio .es desde 2011, se de­sa­rro­lló pre­ci­sa­me­n­te para solventar este problema.

Las ex­te­n­sio­nes de seguridad del sistema de nombres de dominio o DNSSEC por su nombre en inglés (Domain Name System Security Ex­te­n­sio­ns) co­n­s­ti­tu­yen una serie de es­pe­ci­fi­ca­cio­nes que completan el sistema de nombres de dominio con un método de au­te­n­ti­ca­ción de la fuente de donde proviene la in­fo­r­ma­ción para ga­ra­n­ti­zar la veracidad y la in­te­gri­dad de los datos.

Desde que se co­m­pro­ba­ra 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 ex­te­n­sio­nes de seguridad del DNS fueran fi­na­l­me­n­te pu­bli­ca­das en los tres RFC (Request for Comments) RFC 4033, RFC 4034 y RFC 4035 y, a partir de ahí, es­ta­n­da­ri­za­das. En 2010, esta técnica se desplegó por primera vez en el nivel de la raíz de Internet, co­n­cre­ta­me­n­te en los trece se­r­vi­do­res de nombres de raíz re­s­po­n­sa­bles de la re­so­lu­ción de los dominios de nivel superior. DNSSEC se apoya en un sistema cri­p­to­grá­fi­co de clave pública, un pro­ce­di­mie­n­to de en­cri­p­ta­do asi­mé­tri­co por el cual las dos partes im­pli­ca­das, en lugar de compartir una clave secreta común, recurren a un par de claves co­n­si­s­te­n­te 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 in­fo­r­ma­ción del DNS. El programa-cliente puede verificar esta firma con ayuda de la clave pública, co­n­fi­r­ma­n­do así la veracidad de la fuente.

Cada servidor de nombres en el DNS es re­s­po­n­sa­ble de una zona de­te­r­mi­na­da. 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 se­r­vi­do­res 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 in­fo­r­ma­ción. Es así como se originan los RRSIG Resource records, que son en­tre­ga­dos junto a los registros ori­gi­na­les. Esta co­m­bi­na­ción se mantiene, in­de­pe­n­die­n­te­me­n­te de si se almacena en caché o se tra­n­s­fie­re a un servidor DNS diferente, para ser entregada, por último, al cliente so­li­ci­ta­n­te, 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 si­n­tá­c­ti­ca­me­n­te idéntica que verifica adi­cio­na­l­me­n­te su au­te­n­ti­ci­dad (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 in­fo­r­ma­ción a los se­r­vi­do­res de nombres de manera iterativa o recursiva. En el primer caso, el resolver obtiene la in­fo­r­ma­ción so­li­ci­ta­da del servidor al que la solicitó o una re­fe­re­n­cia al próximo servidor de nombres donde la puede conseguir y así procede hasta que resuelve la dirección. Los resolvers que trabajan re­cu­r­si­va­me­n­te, también llamados stub resolvers, típicos de clientes tan ha­bi­tua­les como los na­ve­ga­do­res web, envían una solicitud al servidor de nombres al cual está su­bo­r­di­na­do en la red local o en la red del proveedor. Si no se encuentra la in­fo­r­ma­ción so­li­ci­ta­da en la base de datos, la re­s­po­n­sa­bi­li­dad de la re­so­lu­ción de esta dirección recae en este servidor, que envía entonces, por su parte, so­li­ci­tu­des ite­ra­ti­vas para re­so­l­ve­r­la.

Para poder gozar de las ventajas del protocolo DNSSEC es necesario disponer de un resolver que pueda validar y evaluar toda la in­fo­r­ma­ción adicional generada. Con esta finalidad, el resolver ha de soportar los me­ca­ni­s­mos de extensión para DNS (EDNS, Extension Me­cha­ni­s­ms for DNS). Solo así puede ser activada la va­li­da­ción en el en­ca­be­za­do del DNS.

La expansión de DNSSEC es muy difícil debido, pri­n­ci­pa­l­me­n­te, a la co­m­ple­ji­dad de sus re­qui­si­tos, pues tanto el ad­mi­ni­s­tra­dor de una página como el usuario han de soportar la técnica. Los pro­pie­ta­rios del dominio dependen también de que el re­gi­s­tra­dor soporte este método de en­cri­p­ta­do. Los usuarios no tienen ninguna in­flue­n­cia sobre la pro­te­c­ción o no de una página mediante firmas de DNSSEC y necesitan, además, un resolver que la valide.

En de­fi­ni­ti­va, para be­ne­fi­ciar­se de la extensión de seguridad DNSSEC, hay que:

• ad­mi­ni­s­trar un resolver propio como Bind,
• usar ex­te­n­sio­nes 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 au­te­n­ti­fi­ca la re­so­lu­ción de nombres, no los datos tra­n­s­mi­ti­dos, los cuales quedan sin proteger. Como co­n­se­cue­n­cia, es obli­ga­to­rio co­m­bi­nar­lo con pro­to­co­los de tra­n­s­mi­sión en­cri­p­ta­da como TSL.

Algunos problemas re­s­po­n­sa­bles de la lentitud en la ace­p­ta­ción de estas es­pe­ci­fi­ca­cio­nes pueden ser:

• Una mayor so­bre­ca­r­ga en el servidor de nombres que aumenta la pro­ba­bi­li­dad de ataques de de­ne­ga­ción de servicio (Denial of Service), oca­sio­na­n­do la pérdida de di­s­po­ni­bi­li­dad de una web.
• Como las claves públicas están re­pa­r­ti­das en el DNS, se pone en peligro la cadena de confianza.
• Sin un resolver propio cabe la po­si­bi­li­dad de un ataque entre el cliente y el servidor de nombres del proveedor, aunque este esté ca­pa­ci­ta­do para verificar firmas DNSSEC.

Otros puntos débiles, como el llamado Zone Walking (enu­me­ra­ción de zona), ya han obtenido reacción. En este tipo de amenaza, el atacante puede in­te­r­pre­tar el contenido completo de una zona protegida con DNSSEC. Para pro­te­ge­r­los, los nuevos resolvers nombran a los registros de recursos con un valor hash en lugar de con un texto.