¿Cómo funcionan los ataques de DNS over HTTPS (DoH)?

El pecado original del protocolo DNS

Para entender por qué el DNS over HTTPS (DoH) es hoy un campo de batalla, debemos retroceder a 1983. Cuando Paul Mockapetris diseñó el Sistema de Nombres de Dominio (DNS), internet era un vecindario pequeño y confiable. El protocolo se construyó sobre UDP en el puerto 53, priorizando la velocidad sobre la seguridad. Las consultas viajaban en texto plano, permitiendo que cualquier nodo intermedio —desde tu ISP hasta un vecino malintencionado en una red Wi-Fi pública— pudiera espiar, interceptar o incluso modificar tus destinos digitales.

Esta vulnerabilidad estructural dio pie a décadas de envenenamiento de caché (DNS Spoofing) y censura estatal. Como respuesta, la industria impulsó el cifrado. Primero llegó DNS over TLS (DoT) y finalmente, en 2018, el IETF ratificó el RFC 8484, dando vida al DoH. La promesa era noble: envolver las consultas DNS dentro de una sesión HTTPS estándar (puerto 443). Sin embargo, lo que para el usuario es una capa de privacidad, para el administrador de seguridad es un agujero negro.

La anatomía técnica de una consulta DoH

A diferencia del DNS tradicional, que utiliza un formato binario simple, DoH encapsula esos mismos mensajes DNS (Wireformat) dentro de solicitudes HTTP/2 o HTTP/3. Esto significa que una resolución de nombre ahora se parece a cualquier otra navegación web: lleva cabeceras, cookies y, lo más importante, está protegida por el cifrado TLS.

Desde una perspectiva de red, el tráfico DoH es indistinguible de una compra en Amazon o una sesión de banca online. Esta invisibilidad es precisamente lo que los atacantes han aprendido a explotar con una eficacia quirúrgica. Al utilizar el puerto 443, el malware puede saltarse los firewalls que bloquean el puerto 53, ya que ninguna empresa se atreve a cerrar el tráfico HTTPS sin paralizar su operación.

Cómo el malware abusa de DoH: El caso Godlua y más allá

El primer gran hito en la historia del abuso de este protocolo fue el backdoor Godlua, descubierto en 2019. Fue el primer malware documentado que utilizaba DoH para ocultar sus comunicaciones de Comando y Control (C2). Godlua no consultaba a los servidores DNS locales; en su lugar, realizaba peticiones HTTPS directamente a los resolvedores de Cloudflare o Google para obtener las direcciones IP de sus servidores de ataque.

¿Por qué es esto tan peligroso? Porque rompe la cadena de visibilidad. En un entorno corporativo estándar, el equipo de seguridad monitoriza los registros DNS para detectar dominios maliciosos conocidos. Con DoH, el malware crea un túnel privado que el firewall no puede inspeccionar. El atacante puede exfiltrar datos sensibles —como contraseñas o documentos— codificándolos dentro de los subdominios de una consulta DoH, todo bajo el manto protector del cifrado TLS 1.3.

Exfiltración de datos mediante túneles DoH

El proceso es sutil pero devastador. Imaginemos que un equipo está infectado. El malware quiere enviar un archivo secreto de 10 MB. En lugar de una conexión directa sospechosa, divide el archivo en miles de pequeños fragmentos. Cada fragmento se convierte en un subdominio, por ejemplo: «parte1-secreta.atancante.com». El malware envía una petición DoH consultando ese dominio. El servidor del atacante recibe la consulta, extrae el prefijo y responde con un registro TXT inocuo. Para el analista de seguridad, solo hubo tráfico HTTPS hacia un proveedor confiable como Google DNS.

La paradoja de la privacidad: Seguridad vs. Visibilidad

Aquí entramos en un terreno ético y técnico complejo. Navegadores como Firefox y Chrome han activado DoH por defecto para proteger a los usuarios de ISPs que venden sus datos de navegación. Es una victoria para la privacidad individual, pero una pesadilla para la ciberseguridad industrial. Grupos de amenazas persistentes avanzadas (APT), como OilRig (APT34), han perfeccionado estas técnicas para mantener la persistencia en redes críticas durante meses sin ser detectados.

El uso de DoH elimina herramientas clásicas como el filtrado de contenidos basado en DNS. Si un empleado intenta entrar en un sitio de phishing, y su navegador usa DoH, el filtro de la empresa no podrá intervenir porque ni siquiera sabe qué dominio se está consultando. Estamos ante una «superautopista de ataques» donde el cifrado, diseñado para protegernos, se convierte en el mejor aliado del cibercrimen.

Estrategias de defensa en un mundo cifrado

¿Estamos indefensos? No, pero las reglas han cambiado. La defensa ya no puede basarse en mirar el contenido del paquete, sino en analizar el comportamiento. Las organizaciones modernas están adoptando varias estrategias:

• Inspección SSL/TLS (Man-in-the-Middle): Desencriptar el tráfico HTTPS en el firewall para inspeccionar qué hay dentro. Es costoso y plantea dilemas de privacidad, pero es la única forma de ver el DoH real.
• Canary Domains: Algunos navegadores buscan dominios específicos (como use-application-dns.net) para decidir si activar DoH. Si la red bloquea estos dominios, el navegador vuelve al DNS tradicional controlable.
• Análisis de entropía y patrones: El tráfico de túnel DoH suele tener una cadencia y un tamaño de paquete distinto a la navegación humana. El uso de IA y Machine Learning para detectar estas anomalías es hoy una necesidad.
• Bloqueo de resolvedores públicos: Impedir que los dispositivos internos se conecten a IPs conocidas de proveedores DoH (Cloudflare, Google, Quad9), obligándolos a usar el resolvedor interno de la empresa.

Preguntas Frecuentes (FAQs)