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

¿Cómo funciona DNSSEC?

El sistema de nombres de dominio (DNS) es la guía telefónica de Internet: indica a los equipos 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 DNS para redirigir sus mensajes, lo que significa que son vulnerables a problemas de seguridad en la infraestructura DNS. En septiembre de 2014, los investigadores de CMU descubrieron que el correo electrónico que se debía enviar mediante los servidores Yahoo!, Hotmail y Gmail en realidad se redirigían a través de servidores de correo no autorizados. Los atacantes estaban aprovechando una vulnerabilidad de décadas de antigüedad en el sistema de nombres de dominio (DNS), en el que no se comprobaban las credenciales antes de aceptar una respuesta.

La solución es un protocolo llamado DNSSEC, que añade una capa de confianza sobre el DNS en la que se solicita autenticación. Cuando un solucionador DNS busca blog.cloudflare.com, los servidores de nombres .com ayudan a la resolución a verificar los registros que se devuelven para cloudflare y, a su vez, cloudflare asiste en la verificación de los registros que se envían para el blog. Los servidores de nombres de raíz DNS ayudan a verificar .com, y la información que publica la raíz se aprueba mediante un procedimiento de seguridad, que incluye la ceremonia de firma del certificado raíz.

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.

Summary

Similar to HTTPS, DNSSEC adds a layer of security by enabling authenticated answers on top of an otherwise insecure protocol. Whereas HTTPS encrypts traffic so nobody on the wire can snoop on your Internet activities, DNSSEC merely signs responses so that forgeries are detectable. DNSSEC provides a solution to a real problem without the need to incorporate encryption.

Cloudflare’s goal is to make it as easy as possible to enable DNSSEC. All Cloudflare customers can add DNSSEC to their web properties by flipping a switch to enable DNSSEC and uploading a DS record (which we'll generate automatically) to their registrar.: Learn more about how to get DNSSEC.

We’ve also published an Internet Draft outlining an automated way for registries and registrars to upload DS records on behalf of our customers. This will enable Cloudflare to automatically enable DNSSEC for our entire community. Stay tuned for updates.

Millones de propiedades de Internet de todos los sectores confían en nosotros

Ver casos prácticos

Logotipo con la confianza de doordash gris