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.

Icono de DNSSec

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 ceremonia de firma de la 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.

diagrama rrsets

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í".

diagrama de zona de claves de firma 1

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.

diagrama de zona de claves de firma 2

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.

diagrama de claves de firma de clave 1

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.
diagrama de claves de firma de clave 2

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.

diagrama de registros de delegation signer

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 DNSSEC: complejidades y consideraciones, 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.

diagrama 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 del Internet global.

En la denominada ceremonia de firma de 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.

Configurar Cloudflare es fácil

Configura un dominio en menos de 5 minutos. Mantén tu proveedor de alojamiento. No se requieren cambios de código.

Precios de Cloudflare

La aplicación de Internet de cualquier persona puede beneficiarse del uso de Cloudflare.Elige un plan que se ajuste a tus necesidades.

Gratis $ 0 /mes, por sitio web
Ampliar para ver más Ocultar
Para sitios web y blogs personales, y para cualquier persona que desee explorar Cloudflare.

Más información

El Plan Free incluye todas estas funciones:
  • Mitigación de uso no medido de DDoS
  • Red global de entrega de contenido
  • Certificado SSL compartido
  • Acceso a registros de auditoría de las cuentas
  • 3 page rules
Comparar todas las funciones
Pro $ 20 /mes por sitio web
Ampliar para ver más Ocultar
Para sitios web, blogs y carteras profesionales que necesiten seguridad y funcionamiento básicos.

Más información

El Plan Pro ofrece todo lo que incluye el Plan Free, más:
  • Web Application Firewall (WAF) con conjuntos de reglas de Cloudflare
  • Optimización de imágenes con Polish™
  • Optimización móvil con Mirage™
  • Modo I'm Under Attack™
  • Acceso a registros de auditoría de las cuentas
  • 20 page rules
Comparar todas las funciones
Business $ 200 /mes por sitio web
Ampliar para ver más Ocultar
Para empresas y sitios web de comercio electrónico pequeños que necesiten seguridad y funcionamiento avanzados, cumplimiento de PCI y asistencia prioritaria por correo electrónico.

Más información

El Plan Business ofrece todo lo que incluye el Plan Pro, más:
  • Web Application Firewall (WAF) con 25 conjuntos de reglas personalizados
  • Carga de certificado SSL personalizado
  • Cumplimiento de PCI mediante WAF y modo Modern TLS Only
  • Omisión de caché en cookie
  • Acelera las entregas de contenido dinámico con Railgun™
  • Asistencia priorizada por correo electrónico
  • Acceso a registros de auditoría de las cuentas
  • 50 page rules
Comparar todas las funciones
Enterprise contacta con nosotros
Ampliar para ver más Ocultar
Las empresas que precisen un funcionamiento y una seguridad de nivel empresarial recibirán asistencia ininterrumpida por teléfono, correo electrónico o chat de forma prioritaria, y disfrutarán de un tiempo de funcionamiento garantizado.

Más información

El Plan Enterprise ofrece todo lo que incluye el Plan Business, más:
  • Asistencia ininterrumpida todo el año priorizada por teléfono, correo electrónico o chat
  • Garantía del 100 % de tiempo de actividad con SLA de reembolso de 25 veces el valor del tiempo de inactividad
  • Protección contra DDoS de nivel empresarial con prioridad de red
  • Web Application Firewall (WAF) avanzado con conjuntos de reglas personalizados ilimitados
  • Acceso a cuentas basado en roles multiusuario
  • Múltiples cargas de certificados SSL personalizados
  • Acceso a registros sin procesar
  • Acceso a registros de auditoría de las cuentas
  • Asignación de soluciones e ingenieros para el éxito del cliente
  • Acceso a centros de datos CDN en China (costo adicional)
  • 100 page rules
Comparar todas las funciones

Gratuito

$ 0 / mes
 
Para sitios web y blogs personales, y para cualquier persona que desee explorar Cloudflare.

Pro

$ 20 / mes
por dominio
Para sitios web, blogs y carteras profesionales que necesiten seguridad y funcionamiento básicos.

Business

$ 200 / mes
por dominio
For small eCommerce websites and businesses requiring advanced security and performance, PCI compliance, and prioritized email support.

Enterprise

Contacta con nosotros
 
For companies requiring enterprise-grade security and performance, prioritized 24/7/365 phone, email, or chat support, and guaranteed uptime.

Contamos con la confianza de

Más de 25.000.000 propiedades de Internet

trustedby crunchbase black
trustedby ao com black
trustedby zendesk black
logo sofi gray 32px wrapper
trustedby log me in black
trustedby digital ocean black
trustedby okcupid black
trustedby montecito black
trustedby discord black
trustedby library of congress black
trustedby udacity black
trustedby marketo black