¿Cómo funciona DNSSEC?

Una pequeña introducción a DNSSEC

DNSSEC crea un seguro sistema de nombres de dominio al agregar firmas criptográficas a los registros DNS existentes. Estas firmas digitales se almacenan en servidores de nombres DNS junto con tipos de registros comunes, tales como A, AAAA, MX, CNAME, etc. Para verificar que un registro DNS solicitado proviene de su servidor de nombres autoritativo, puedes comprobar su firma asociada. De esta manera, también te aseguras de que no sufrió ninguna alteración en ruta y lo distingues de un registro falso inyectado en un ataque de intermediario.

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

• RRSIG: Contiene una firma criptográfica

• DNSKEY: Contiene una clave de firma pública

• DS: Contiene el algoritmo hash de un registro DNSKEY

• NSEC y NSEC3: Para la negación explícita de la existencia de un registro DNS

• CDNSKEY y CDS: Para cuando se solicitan actualizaciones de los registros DS en la zona principal desde una zona secundaria.

En este artículo, hablaremos sobre cómo interactúan los registros RRSIG, DNSKEY y DS, y la forma en que añaden un mayor nivel de confianza al DNS.

Conjuntos de registros de recursos (RRsets)

El primer paso para asegurar una zona con DNSSEC es agrupar todos los registros del mismo tipo en un conjunto de registros de recursos (RRset). Por ejemplo, si tienes tres registros AAAA en tu zona con la misma etiqueta (por ejemplo, etiqueta.ejemplo.com), todos se agruparían en un único RRset AAAA.

En realidad, es este RRset completo el que se firma de manera digital, y no los registros de DNS individuales. Por supuesto, esto siempre requiere que solicites y valides todos los registros AAAA de una zona con la misma etiqueta, en lugar de validar solo uno de ellos.

Claves de firma de zonas

Cada zona de DNSSEC tiene un par de claves de firma de zonas (ZSK): la parte privada de la clave firma, de manera digital, 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 a partir de las ZSK privadas y las almacena en su servidor de nombres como registros RRSIG. Esto es como decir, "Estos son mis registros DNS, provienen de mi servidor y deberían verse así".

Sin embargo, estos registros RRSIG son inútiles a menos que las resoluciones de DNS tengan una forma de verificar las firmas. El operador de zona también necesita que las ZSK públicas estén disponibles. Para eso, debe agregarlas al servidor de nombres en un registro DNSKEY.

Cuando una resolución de DNSSEC solicita un tipo de registro en particular (por ejemplo, AAAA), el servidor de nombres también devuelve el RRSIG correspondiente. La resolución puede obtener el registro DNSKEY que contiene la ZSK pública del servidor de nombres. En conjunto, el RRset, el RRSIG y la ZSK pública pueden validar la respuesta.

Si confiamos en la clave de firma de zonas en el registro DNSKEY, podemos confiar en todos los registros de la zona. Pero ¿y si la clave de la firma de zonas se vio comprometida? Entonces, necesitamos una forma de validar la ZSK pública.

Claves de firma de claves

Además de una clave de firma de zonas, los servidores de nombres DNSSEC también tienen una clave de firma de claves (KSK). La KSK valida el registro DNSKEY de la misma manera que nuestra ZSK aseguró el resto de los RRsets en la sección anterior: firma la ZSK pública (que se almacena en un registro DNSKEY) y crea un RRSIG para el 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 como resultado el RRset DNSKEY que se muestra arriba. Tanto la KSK pública como la ZSK pública llevan la firma de la KSK privada. Las resoluciones pueden utilizar la KSK pública para validar la ZSK pública.

La validación para las resoluciones se ve así ahora:

• Solicita el RRset deseado, que también devuelve el registro RRSIG correspondiente.

• Solicita los registros DNSKEY que contienen la ZSK pública y la KSK pública, que también devuelve el RRSIG para el RRset DNSKEY.

• Verifica la RRSIG del RRset solicitado con la ZSK pública.

• Verifica el RRSIG del RRset DNSKEY con la KSK pública.

Por supuesto, el RRset DNSKEY y los registros RRSIG correspondientes se pueden almacenar en caché, y esto hace que los servidores de nombres DNS no reciban toneladas de solicitudes innecesarias.

¿Por qué usamos claves de firma de zonas y claves de firma de claves distintas? Como explicaremos en la siguiente sección, es difícil reemplazar una KSK antigua o comprometida. Cambiar la ZSK, por otro lado, es mucho más fácil. Esto nos permite usar una ZSK más pequeña sin comprometer la seguridad del servidor y minimiza la cantidad de datos que el servidor tiene que enviar con cada respuesta.

Ahora establecimos confianza dentro de nuestra zona, pero el DNS es un sistema jerárquico, y las zonas rara vez operan de forma independiente. Para complicar aún más las cosas, la clave de firma de claves está firmada por sí misma, y eso no ofrece ningún tipo de confianza adicional. Necesitamos una forma de conectar la confianza de nuestra zona con la zona principal.

Registros del firmante de la delegación

DNSSEC dispone de un registro del firmante de la delegación (DS) para permitir la transferencia de confianza de una zona principal a una secundaria. Un operador de zona crea un algoritmo hash sobre el registro DNSKEY que contiene la KSK pública y se lo da a la zona principal para que lo publique como un registro DS.

Cada vez que se remite una resolución a una zona secundaria, la zona principal también brinda un registro DS. Este registro DS es la forma en que las resoluciones saben que la zona secundaria está habilitada para DNSSEC. Para comprobar la validez de la KSK pública de la zona secundaria, la resolución la guarda con un algoritmo hash y la compara con el registro DS de la zona principal. Si coinciden, la resolución puede suponer que nadie manipuló la KSK pública, lo que significa que puede confiar en todos los registros de la zona secundaria. Así es como se establece una cadena de confianza con las extensiones DNSSEC.

Ten en cuenta que cualquier cambio en la KSK también requiere un cambio en el registro DS de la zona principal. Cambiar el registro DS es un proceso de varios pasos que puede terminar dañando la zona si no se hace de forma correcta. Primero, se debe agregar el nuevo registro DS a la zona principal y, luego, esperar hasta que el TTL del registro DS original caduque para eliminarlo. Por este motivo es que resulta mucho más fácil cambiar las claves de firma de zonas que las claves de firma de claves.

Negación de existencia explícita

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 que te diga de manera explícita: "lo siento, la zona que solicitaste no existe". Esto es un problema si quieres autentificar la respuesta, ya que no hay ningún mensaje para firmar. Para solucionarlo, DNSSEC agrega los tipos de registro NSEC y NSEC3. Los dos permiten una negación de existencia autenticada.

NSEC se ejecuta y devuelve el "próximo registro seguro". Por ejemplo, piensa en un servidor de nombres que define los registros AAAA para api, blog y www. Si solicitas un registro para almacenar, devolverá un registro NSEC que contiene www, lo que significa que no hay registros AAAA entre el almacén y www cuando los registros se ordenan alfabéticamente. Esto indica que el almacén no existe. Además, como el registro NSEC está firmado, puedes validar el RRSIG correspondiente como cualquier RRset.

Por desgracia, esta solución permite a cualquiera entrar en la zona y reunir todos los registros sin siquiera saber cuáles están buscando. Esto puede ser una amenaza potencial a la seguridad si el administrador de la zona creía que los contenidos de esta eran privados. Puedes leer más sobre este problema en DNSSEC: Complexities and Considerations (DNSSEC: Complejidades y consideraciones), así como también consultar la excepcional solución de Cloudflare en DNSSEC Done Right (DNSSEC: El método correcto).

La cadena de confianza

Entonces, tenemos una forma de generar confianza dentro de una zona y conectarla a la zona principal, pero ¿cómo confiamos en el registro DS? Bien, el registro DS se firma como cualquier otro RRset, lo que significa que lleva su respectivo RRSIG en la zona principal. Todo el proceso de validación se repite hasta que llegamos a la KSK pública de la zona principal. Para verificarla, necesitamos ir al registro DS de esa zona, y así vamos escalando en la cadena de confianza.

Sin embargo, cuando al final llegamos a la zona raíz del DNS, tenemos un problema: no hay ningún registro DS en la zona principal con el cual llevar a cabo la validación. Esta es la parte en la que vemos el lado más humano de la Internet global.

En la ceremonia de firma del certificado raíz, se reúnen muchas personas de todo el mundo, seleccionadas con anterioridad, para firmar el RRset DNSKEY raíz en una instancia pública que se audita en detalle. En la ceremonia, se crea un registro RRSIG que se puede usar para verificar las KSK y ZSK públicas del servidor de nombres raíz. En lugar de confiar en la KSK pública ante la existencia del registro DS en la zona principal, asumimos que el proceso es válido porque confiamos en las medidas de seguridad que intervienen en el acceso a la KSK privada.

La capacidad de establecer confianza entre las zonas principales y secundarias es una parte integral del protocolo DNSSEC. Si alguna parte de la cadena se rompe, no podemos confiar en los registros que solicitamos porque un intermediario podría alterarlos y dirigirnos a cualquier dirección IP que quisiera.

Al igual que HTTPS, DNSSEC agrega una capa de seguridad al habilitar respuestas autenticadas sobre un protocolo que, de otra forma, sería inseguro. Mientras que HTTPS cifra el tráfico para que nadie en línea pueda husmear en las actividades que realizas en Internet, DNSSEC simplemente firma las respuestas para que se puedan detectar falsificaciones. DNSSEC provee una solución a un problema real sin la necesidad de incorporar encripción.

El objetivo de Cloudflare es facilitar al máximo la activación de DNSSEC. Todos los clientes de Cloudflare pueden agregar DNSSEC a sus propiedades web con un botón para activar DNSSEC y cargar un registro DS (que generaremos automáticamente) en su registrador. Obtén más información sobre cómo obtener DNSSEC

.También publicamos un borrador de Internet en el que se describe una forma automatizada para que los sitios de registros y los registradores carguen registros DS en nombre de nuestros clientes. Esto le permitirá a Cloudflare habilitar DNSSEC, de manera automática, para toda nuestra comunidad. Mantente atento a las actualizaciones.