#main-nav-header { display:none; }

Cómo funciona DNSSEC

El sistema de nombres de dominio (DNS) es la guía telefónica de Internet: dice a los ordenadores dónde enviar y recuperar información. Desafortunadamente, también acepta cualquier dirección que se le dé, sin hacer preguntas.

Los servidores de correo electrónico utilizan el DNS para enrutar sus mensajes, por lo que son vulnerables a los problemas de seguridad en la infraestructura del DNS. En septiembre de 2014 investigadores de la CMU descubrieron correos electrónicos que debían enviarse a través de los servidores de Yahoo!, Hotmail y Gmail, y en su lugar se enrutaban a través de servidores de correo no autorizados. Los atacantes estaban explotando una vulnerabilidad con décadas de antigüedad en el sistema de nombres de dominio (DNS); no comprueba las credenciales antes de aceptar una respuesta.

La solución es un protocolo llamado DNSSEC; añade una capa de confianza al DNS al proporcionar autenticación. Cuando un solucionador de DNS busca blog.cloudflare.com, los servidores de nombres .com ayudan al solucionador a verificar los registros de cloudflare devueltos, y cloudflare ayuda a verificar los registros de blog devueltos. Los servidores de nombres DNS raíz ayudan a verificar .com y la información publicada por la raíz es examinada por un procedimiento de seguridad exhaustivo, que incluye la ceromonia de firma de la zona raíz.

Introducción sencilla a DNSSEC

DNSSEC crea un sistema de nombres de dominio seguro añadiendo firmas criptográficas a los registros DNS existentes. Estas firmas digitales se almacenan en servidores de nombres DNS junto con tipos de registros comunes como A, AAAA, MX, CNAME, etc. Al comprobar su firma asociada, puedes verificar que un registro DNS solicitado proviene de su servidor de nombres autoritativo y no se ha alterado en la ruta, a diferencia de los registros falsos inyectados en los ataques de intermediario.

Para facilitar la validación de la firma, DNSSEC añade algunos nuevos tipos de registro DNS:

RRSIG: contiene una firma criptográfica.
DNSKEY: contiene una clave de firma pública.
DS: contiene el hash de un registro de DNSKEY.
NSEC y NSEC3: para la negación explícita de la existencia de un registro DNS.
CDNSKEY y CDS: para una zona secundaria que solicita actualizaciones de registros DS en la zona principal.

La interacción entre los registros RRSIG, DNSKEY y DS, así como la forma en que añaden una capa de confianza sobre el DNS, es el tema de este artículo.

Conjuntos de registros de recursos

El primer paso para proteger una zona con DNSSEC es agrupar todos los registros del mismo tipo en un conjunto de registros de recursos (RRset, por sus siglas en inglés). Por ejemplo, si tienes tres registros AAAA en tu zona con la misma etiqueta (es decir, label.example.com), todos se agruparán en un único RRset AAAA.

De hecho, este RRset completo es lo que se firma digitalmente, en lugar de los registros DNS individuales. Por supuesto, eso también significa que debes solicitar y validar todos los registros AAAA de una zona con la misma etiqueta, en lugar de validar solo uno de ellos.

Claves de firma de zona

Cada zona de DNSSEC tiene un par de claves de firma de zona (ZSK, por sus siglas en inglés): la parte privada de la clave firma digitalmente cada RRset de la zona, mientras que la parte pública verifica la firma. Para habilitar DNSSEC, un operador de zona crea firmas digitales para cada RRset usando la ZSK privada y la almacena en su servidor de nombres como registros RRSIG. Es como decir: "Estos son mis registros DNS, provienen de mi servidor y deben ser así".

Sin embargo, estos registros RRSIG son inútiles a menos que los solucionadores de DNS tengan una forma de verificar las firmas. El operador de zona también tiene que proveer su ZSK pública añadiéndola a su servidor de nombres en un registro DNSKEY.

Cuando un solucionador DNSSEC solicita un tipo de registro en particular (p. ej., AAAA), el servidor de nombres también devuelve el RRSIG correspondiente. Luego, el solucionador puede extraer el registro DNSKEY que contiene la ZSK pública del servidor de nombres. Juntos, el RRset, el RRSIG y la ZSK pública pueden validar la respuesta.

Si confiamos en la clave de firma de zona del registro DNSKEY, podemos confiar en todos los registros de la zona. Pero, ¿y si la clave de firma de zona queda comprometida? Necesitamos poder validar la ZSK pública.

Claves de firma de clave

Además de una clave de firma de zona, los servidores de nombres de DNSSEC también tienen una clave de firma de clave (KSK, por sus siglas en inglés). La KSK valida el registro DNSKEY exactamente de la misma manera que nuestra ZSK aseguró el resto de nuestros RRsets en la sección anterior: firma la ZSK pública (que se almacena en un registro DNSKEY), creando un RRSIG para la DNSKEY.

Al igual que la ZSK pública, el servidor de nombres publica la KSK pública en otro registro DNSKEY, lo que nos da el RRset de DNSKEY que se muestra arriba. Tanto la KSK pública como la ZSK pública están firmadas por la KSK privada. Los solucionadores pueden usar la KSK pública para validar la ZSK pública.

La validación de los solucionadores consiste ahora en lo siguiente:

Se solicita el RRset deseado, que también devuelve el registro RRSIG correspondiente.
Se solicitan los registros DNSKEY que contienen la ZSK pública y la KSK pública, que también devuelve el RRSIG para el RRset de DNSKEY.
Se verifica el RRSIG del RRset solicitado con la ZSK pública.
Se verifica el RRSIG del RRset de DNSKEY con la KSK pública.

Por supuesto, los registros RRset de DNSKEY y RRSIG correspondientes se pueden almacenar en caché, por lo que los servidores de nombres DNS no se ven bombardeados constantemente con solicitudes innecesarias.

¿Por qué usamos claves de firma de zona y claves de firma de clave separadas? Como explicaremos en la siguiente sección, es difícil cambiar una KSK antigua o comprometida. Cambiar la ZSK, no obstante, es mucho más fácil. Esto nos permite utilizar una ZSK más pequeña sin poner en peligro la seguridad del servidor, minimizando la cantidad de datos que el servidor tiene que enviar con cada respuesta.

Ya hemos establecido la confianza dentro de nuestra zona, pero el DNS es un sistema jerárquico, y las zonas no suelen operar de forma independiente. Para complicar más las cosas, la clave de firma de clave se firma a sí misma, lo que no proporciona ninguna confianza adicional. Hace falta una manera de conectar la confianza de nuestra zona con su zona principal.

Registros de Delegation Signer

DNSSEC introduce un registro de Delegation Signer (DS) para permitir la transferencia de confianza desde una zona principal a una zona secundaria. Un operador de zona realiza una función hash en el registro DNSKEY que contiene la KSK pública y se lo entrega a la zona principal para publicarlo como registro DS.

Cada vez que un solucionador se dirige a una zona secundaria, la zona principal también proporciona un registro DS. Este registro DS es la forma en que los solucionadores saben que la zona secundaria está habilitada para DNSSEC. Para comprobar la validez de la KSK pública de la zona secundaria, el solucionador realiza una función hash y la compara con el registro DS de la principal. Si coinciden, el solucionador puede asumir que la KSK pública no ha sido alterada, lo que significa que puede confiar en todos los registros de la zona secundaria. Así es como se establece una cadena de confianza en DNSSEC.

Debe tenerse en cuenta que cualquier cambio en la KSK también requiere un cambio en el registro DS de la zona principal. El cambio del registro DS es un proceso con varios pasos que puede terminar rompiendo la zona si se realiza de forma incorrecta. Primero, la zona principal tiene que agregar el nuevo registro de DS, luego tiene que esperar hasta que el TTL del registro original de DS caduque antes de quitarlo. Por eso es mucho más fácil cambiar las claves de firma de zona que las claves de firma de clave.

Negación explícita de existencia

Si le pides al DNS la dirección IP de un dominio que no existe, te devuelve una respuesta vacía, no hay forma de decir de forma explícita, "lo siento, la zona que solicitaste no existe". Esto es problemático si quieres autenticar la respuesta, ya que no hay ningún mensaje para firmar. DNSSEC lo soluciona añadiendo los tipos de registro NSEC y NSEC3. Ambos permiten la negación de existencia autenticada.

NSEC funciona devolviendo el registro "siguiente seguro". Por ejemplo, imaginemos un servidor de nombres que define los registros AAAA para api, blog y www. Si solicitas un registro para almacén, devolverá un registro NSEC que contenga www, lo que significa que no hay registros AAAA entre el almacén y la www cuando los registros están ordenados alfabéticamente. Esto efectivamente te dice que el almacén no existe. Y, como el registro de NSEC está firmado, puedes validar su RRSIG correspondiente como cualquier RRset.

Desafortunadamente, esta solución permite a cualquier persona recorrer la zona y reunir todos los registros sin saber cuáles está buscando. Puede ser una amenaza potencial de seguridad si el administrador de la zona contaba con que su contenido fuera privado. Puedes leer más sobre este problema en Complejidades y consideraciones del protocolo DNSSEC, así como la solución exclusiva de Cloudflare en DNSSEC bien hecho.

La cadena de confianza

Bien, entonces tenemos una forma de establecer la confianza dentro de una zona y conectarla a su zona principal, pero ¿cómo confiamos en el registro DS? Bueno, el registro DS está firmado como cualquier otro RRset, lo que significa que tiene un RRSIG correspondiente en la zona principal. Todo el proceso de validación se repite hasta llegar a la KSK pública de la zona principal. Para verificarlo, tenemos que ir al registro DS principal y a continuación ascendemos en la cadena de confianza.

Sin embargo, cuando finalmente llegamos a la zona raíz del DNS, tenemos un problema: no hay ningún registro DS principal para validar. Aquí es donde podemos ver un lado muy humano de la red pública de Internet.

En la denominada ceromonia de firma de la zona raíz, personas seleccionadas de todo el mundo se reúnen para firmar el RRset de DNSKEY raíz de manera pública y muy auditada. La ceremonia produce un registro RRSIG que se puede utilizar para verificar la KSK y ZSK públicas del servidor de nombre raíz. En lugar de confiar en la KSK pública por el registro DS de la zona principal, asumimos que es válida porque confiamos en los procedimientos de seguridad para acceder a la KSK privada.

La capacidad de establecer confianza entre la zona principal y la secundaria es una parte integral de DNSSEC. Si alguna parte de la cadena se rompe, no podemos confiar en los registros que solicitamos, porque un intermediario podría alterar los registros y dirigirnos a cualquier dirección IP que desee.

Resumen

Al igual que HTTPS, DNSSEC añade una capa de seguridad, al posibilitar respuestas autenticadas sobre un protocolo que de otra manera sería inseguro. Mientras que HTTPS encripta el tráfico para que nadie en línea pueda espiar tus actividades en Internet, DNSSEC simplemente firma las respuestas para que las falsificaciones sean detectables. DNSSEC proporciona una solución a un problema real sin necesidad de incorporar la encriptación.

El objetivo de Cloudflare es hacer que sea lo más fácil posible habilitar DNSSEC. Ahora mismo, los clientes con planes de pago de Cloudflare pueden añadir DNSSEC a sus propiedades web activando un botón para habilitar DNSSEC y cargando un registro DS (que generaremos automáticamente) en su registrador. Más información sobre cómo obtener DNSSEC.

También hemos publicado un borrador de Internet que resume una forma automatizada de que los registros y los registradores carguen registros DS en nombre de nuestros clientes. Esto permitirá a Cloudflare habilitar automáticamente DNSSEC para toda nuestra comunidad. Mantente al tanto de las actualizaciones.