#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.

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.

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.

Contamos con la confianza de millones de propiedades de Internet

Ver casos prácticos