DNS seguro: DNSSEC y DNS sobre HTTPS (DoH)

El Sistema de nombres de dominio (DNS) traduce los nombres de dominio legibles por las personas en direcciones IP. Diseñado en la década de 1980, el DNS se creó sin seguridad: las consultas y respuestas viajan por el puerto UDP/TCP 53 en texto sin cifrar y sin autenticación. Esto crea dos vulnerabilidades principales: el envenenamiento de la caché DNS (inyectar respuestas DNS falsificadas para redirigir a los usuarios a servidores maliciosos) y la interceptación de DNS (observar qué dominios consulta un usuario revela su actividad de navegación). Dos estándares abordan estos problemas: DNSSEC evita la falsificación y DNS over HTTPS (DoH) evita la interceptación.

El envenenamiento de la caché DNS (ataque de Kaminsky) explota la falta de autenticación del protocolo DNS. Un resolver envía una consulta a un servidor DNS autoritativo y almacena en caché la respuesta durante el periodo TTL. Un atacante que pueda adivinar el ID de transacción (de 16 bits y predecible) y el puerto de origen (utilizado como entropía adicional desde RFC 5452) puede enviar respuestas falsificadas que el resolver almacena en caché, redirigiendo a todos los usuarios que consulten ese resolver al servidor del atacante. Una vez envenenada la caché, los usuarios son dirigidos a servidores falsos aunque hayan escrito el dominio correcto. DNSSEC evita esto mediante la firma digital de las respuestas DNS.

DNSSEC añade firmas criptográficas a los registros DNS, lo que permite a los resolvers verificar que las respuestas proceden de la autoridad legítima de la zona y no han sido manipuladas. DNSSEC introduce nuevos tipos de registro: RRSIG (firma de registro de recursos, la firma propiamente dicha sobre un conjunto de registros), DNSKEY (la clave pública utilizada para verificar las firmas), DS (firmante de delegación, vincula las claves de las zonas principal y secundaria) y NSEC/NSEC3 (denegación autenticada de existencia: demuestra que un nombre no existe). DNSSEC crea una cadena de confianza desde la zona raíz (firmada por ICANN) a través de las zonas de nivel superior y las zonas autoritativas.

DNSSEC utiliza dos tipos de claves de firma. La Zone Signing Key (ZSK) firma los conjuntos de registros DNS individuales (RRSIG) y se cambia con frecuencia (mensual o trimestralmente) para facilitar la gestión operativa. La Key Signing Key (KSK) firma el conjunto de registros DNSKEY y proporciona el ancla de confianza de la zona. La KSK se cambia con menos frecuencia (anualmente), porque la zona principal debe actualizarse con el nuevo registro DS cada vez que cambia la KSK; este proceso requiere coordinación. La KSK verifica la ZSK; la ZSK firma los datos. Esta estructura de dos capas equilibra la seguridad (cambio frecuente de la ZSK) con la carga operativa (cambio poco frecuente de la KSK).

DNSSEC tiene limitaciones importantes. No cifra las consultas DNS: solo firma las respuestas para garantizar su integridad. Un intruso todavía puede ver todas las consultas DNS, aunque no puede falsificar las respuestas. Enumeración de zonas: los registros NSEC (que demuestran la inexistencia) permiten a los atacantes recorrer la zona y enumerar todos los nombres de dominio que contiene; NSEC3 mitiga este problema mediante nombres con hash, pero no es perfecto. Complejidad operativa: la gestión de claves, la caducidad de las firmas y la coordinación con la zona principal generan una carga operativa considerable. La adopción de DNSSEC sigue siendo incompleta: muchos TLD y registradores la admiten, pero muchas organizaciones aún no la han implementado.

DNS sobre HTTPS (DoH) cifra las consultas DNS dentro de HTTPS (RFC 8484), ocultando su contenido a los observadores de la red. Las consultas se envían a un resolvedor compatible con DoH mediante una URL HTTPS estándar, lo que hace que el tráfico DNS sea indistinguible del resto del tráfico HTTPS. Esto impide que los ISP, los empleadores y los atacantes en la ruta vean qué dominios consulta un usuario, solucionando la brecha de privacidad que deja DNSSEC. Sin embargo, DoH traslada la confianza del resolvedor DNS de la red al proveedor de DoH (normalmente Google 8.8.8.8, Cloudflare 1.1.1.1 o el resolvedor DoH de la propia organización). Actualmente, la mayoría de los principales navegadores admite DoH de forma nativa.

DNS sobre TLS (DoT) (RFC 7858) cifra las consultas DNS mediante TLS a través de un puerto TCP dedicado, el 853, en lugar de tunelizarlas mediante HTTPS. DoT ofrece los mismos beneficios de privacidad que DoH —ocultar el contenido de las consultas a los fisgones—, pero es más fácil de identificar y filtrar para los administradores de red (puerto 853 frente al puerto 443). Esto tiene dos caras: DoT es visible y los firewalls empresariales pueden bloquearlo, mientras que es más difícil bloquear DoH sin afectar al tráfico HTTPS general. Los resolvedores stub (a nivel del sistema operativo) suelen usar DoT; los navegadores suelen usar DoH.

El DNS cifrado plantea un desafío para los entornos empresariales que dependen del filtrado basado en DNS y de los sinkholes. Cuando los navegadores usan resolvedores DoH externos, se eluden los controles DNS internos. Contramedidas empresariales: implementar un resolvedor DoH/DoT interno (Cisco Umbrella, Pi-hole con DoH) y configurar todos los dispositivos para que lo utilicen; bloquear las IP de resolvedores DoH externos en el firewall (Google 8.8.8.8, Cloudflare 1.1.1.1) en el puerto 443; usar Group Policy para deshabilitar DoH a nivel del navegador en los endpoints administrados; y aplicar reglas de proxy transparente que intercepten DNS sobre TLS en el puerto 853. El objetivo es enrutar todo el DNS mediante el resolvedor controlado sin bloquear por completo el DNS cifrado.

Una estrategia completa de seguridad DNS combina varios controles. DNSSEC para sus zonas autoritativas evita el envenenamiento de caché de su dominio. El filtrado basado en DNS (Cisco Umbrella, Cloudflare Gateway) bloquea dominios maliciosos en el nivel del resolvedor. DoH/DoT hacia un resolvedor controlado proporciona privacidad de las consultas sin perder visibilidad del filtrado. El registro de DNS en el SIEM captura todas las consultas para la búsqueda de amenazas: los registros DNS revelan tráfico de C2, exfiltración de datos mediante túneles DNS y actividad de algoritmos de generación de dominios (DGA) de malware. La telemetría DNS es una de las fuentes de datos de seguridad más valiosas disponibles.

El túnel DNS codifica datos dentro de consultas y respuestas DNS para exfiltrar datos o establecer canales de C2 a través de redes donde se bloquea el resto del tráfico saliente. Herramientas como iodine, DNScat y dnscat2 codifican cargas útiles en etiquetas de subdominio (consulta de EXFILTRATEDDATA.evil.com) o en registros TXT. Para detectarlo, busque nombres de consulta DNS inusualmente largos (>100 caracteres), un volumen elevado de consultas desde un único host, consultas de dominios principales inexistentes, tipos de registro inusuales (TXT, NULL) y una entropía anómala en las etiquetas de dominio (los datos codificados presentan una entropía de Shannon elevada). Las plataformas de análisis de seguridad DNS marcan automáticamente los patrones de túnel.

Las zonas de políticas de respuesta DNS (RPZ) permiten que los resolvedores DNS apliquen políticas locales de sobrescritura a las respuestas DNS, creando básicamente un sinkhole local en el nivel del resolvedor sin modificar la infraestructura DNS global. Cuando un cliente consulta un dominio conocido por ser malicioso, la política RPZ devuelve NXDOMAIN, redirige a una IP de sinkhole o devuelve una respuesta de passthrough. Los feeds de RPZ están disponibles a través de proveedores de inteligencia sobre amenazas (Spamhaus, SURBL) y pueden importarse directamente en resolvedores BIND o Unbound. RPZ es una herramienta defensiva eficaz porque aplica el filtrado en la capa DNS a todos los dispositivos de la red sin ninguna configuración en el cliente.

Compruebe su comprensión de los conceptos de CompTIA Security+ (SY0-701) tratados en esta lección.

En esta lección ha aprendido lo siguiente: DNSSEC añade firmas criptográficas a los registros DNS mediante pares de claves KSK/ZSK para evitar el envenenamiento de caché, pero no cifra las consultas; DNS sobre HTTPS (DoH) cifra las consultas DNS dentro de HTTPS para evitar la interceptación, pero crea riesgos de elusión del filtrado empresarial; y el túnel DNS codifica datos en las consultas DNS y puede detectarse mediante el análisis de la longitud, el volumen y la entropía de las consultas. A continuación exploraremos IPsec, los protocolos VPN y la seguridad del acceso remoto.