Seguridad DNS: DNSSEC, DoH/DoT y filtrado

La seguridad DNS es la disciplina de proteger la capa de resolución de nombres para que un dominio siempre apunte a la IP legítima, viaje cifrado y no se use como canal de ataque. Este artículo es una guía deliberadamente defensiva: no describe cómo se ataca el DNS (eso ya lo cubren nuestras piezas de pharming, spoofing y Man in the Middle), sino cómo se endurece. Recorre DNSSEC y sus límites reales, el transporte cifrado DoH frente a DoT, el hardening del resolver, el DNS protector como control frente a C2 de malware y phishing, y cierra con un checklist accionable para pymes.

Por qué el DNS es un punto ciego defensivo

El DNS se diseñó en los años ochenta para funcionar, no para ser seguro. El protocolo base viaja por UDP en el puerto 53, sin cifrado y sin autenticación de origen. Cualquier equipo intermedio puede leer qué dominios consulta un usuario y, en las condiciones adecuadas, falsificar la respuesta. Durante décadas esto se aceptó como un mal menor, y por eso el DNS acabó convertido en el punto ciego típico de muchas arquitecturas: se monitoriza el tráfico HTTP, el correo y los endpoints, pero nadie mira las consultas de nombres.

Esa ceguera tiene coste. La resolución DNS es la fase que el atacante manipula en un ataque de pharming, es el vector de las técnicas de spoofing sobre resolución de nombres y suele ser el primer paso de un Man in the Middle. Al mismo tiempo, el 90% del malware moderno usa DNS en algún momento: para localizar su servidor de mando y control (C2), para exfiltrar datos por tunneling o para resolver dominios generados por algoritmo (DGA). Defender el DNS significa cerrar a la vez un vector de entrada y un canal de salida.

DNSSEC: qué firma y qué no protege

DNSSEC (DNS Security Extensions, definido en las RFC 4033 a 4035) añade autenticación de origen e integridad a las respuestas DNS mediante firma digital. Cada zona firma sus registros y publica la firma en registros RRSIG, la clave pública en un registro DNSKEY y un hash de esa clave (DS) en la zona padre. Así se construye una cadena de confianza que sube hasta la raíz, cuya clave está anclada de forma global. Un resolver validante comprueba esa cadena y rechaza cualquier respuesta cuya firma no cuadre, lo que neutraliza el envenenamiento de caché y la mayoría de las falsificaciones de respuesta.

El punto que más se malinterpreta: DNSSEC no aporta confidencialidad. Firma, no cifra. Un observador de red sigue viendo en claro qué dominio se consulta y qué IP se devuelve. DNSSEC garantiza que la respuesta es auténtica y no ha sido alterada, nada más. La privacidad de la consulta es problema del transporte cifrado, que se trata en la sección siguiente. Otro matiz: los registros NSEC que prueban la no existencia de un nombre permiten enumerar la zona (zone walking); NSEC3 con salt e iteraciones mitiga ese problema, aunque no lo elimina del todo.

Cómo desplegar DNSSEC

1. Elegir algoritmo moderno. ECDSA P-256 (algoritmo 13) o Ed25519 (algoritmo 15) producen firmas pequeñas y rápidas. Evite RSA/SHA-1, ya obsoleto.
2. Firmar la zona. Con BIND se usa dnssec-signzone o la firma en línea (inline-signing); Knot DNS y PowerDNS ofrecen firma y rollover automáticos, que reducen mucho el riesgo operativo.
3. Publicar el registro DS en el registrador. Este paso cierra la cadena de confianza con la zona padre. Sin el DS publicado, la firma no valida hacia arriba.
4. Verificar. Compruebe la validación con dig +dnssec ejemplo.com (busque el flag ad, authenticated data), con delv o con la herramienta gráfica DNSViz.
5. Automatizar el rollover de claves. Separe KSK (Key Signing Key) y ZSK (Zone Signing Key) y programe la rotación. Una firma caducada deja la zona inaccesible para los resolvers validantes, uno de los fallos más habituales.

Transporte cifrado: DoH frente a DoT

El transporte cifrado resuelve lo que DNSSEC no toca: la confidencialidad de la consulta. Hay dos estándares principales.

• DoT (DNS over TLS, RFC 7858). Encapsula el DNS dentro de TLS sobre un puerto dedicado, el 853. Al usar un puerto propio, la organización lo distingue con claridad: puede permitirlo hacia sus resolvers de confianza, monitorizarlo o bloquearlo.
• DoH (DNS over HTTPS, RFC 8484). Envía las consultas como peticiones HTTPS por el puerto 443, mezcladas con el resto del tráfico web. Esto maximiza la privacidad frente a un observador externo, pero desde la óptica de la empresa complica la visibilidad: el DNS deja de ser distinguible del tráfico HTTPS normal.

El compromiso empresarial es claro. En una red corporativa, DoT hacia un resolver interno de confianza suele ser la mejor opción: cifra la consulta hasta el resolver, mantiene la visibilidad y respeta las políticas de filtrado. El riesgo real es el DoH del navegador, que puede saltarse el resolver corporativo y anular todo el filtrado DNS. Firefox y Chrome permiten desactivarlo por política (ADMX/GPO) y respetan el dominio canario use-application-dns.net: si su resolución falla, el navegador desactiva su DoH automático. Para escenarios de máxima privacidad existe además ODoH (Oblivious DoH), que separa la identidad del cliente del contenido de la consulta mediante un proxy intermedio.

Hardening del resolver

El resolver recursivo es el corazón de la seguridad DNS interna. Endurecerlo se apoya en varios controles concretos, en la misma línea que el bastionado de redes y sistemas:

• Upstreams de confianza. Reenvíe solo a resolvers conocidos (Quad9, Cloudflare, un servicio gestionado) y, preferiblemente, por DoT. Evite la recursión abierta a Internet.
• Cerrar la recursión abierta. Un resolver que responde consultas recursivas a cualquiera es un arma de amplificación en ataques DDoS de reflexión. Restrinja la recursión a las redes internas.
• Response Rate Limiting (RRL). Limita el ritmo de respuestas idénticas y frena tanto la amplificación como parte de la fuerza bruta de envenenamiento.
• Defensas contra cache poisoning. Aleatorización del puerto de origen, aleatorización de mayúsculas y minúsculas (0x20 encoding) y DNS Cookies (RFC 7873). Son la respuesta a familias como el ataque Kaminsky (CVE-2008-1447) y el más reciente SAD DNS (CVE-2020-25705). Mantener el software al día también cierra fallos críticos de servidor como SIGRed (CVE-2020-1350) en Windows DNS.
• QNAME minimisation (RFC 9156). El resolver envía a cada servidor autoritativo solo la parte del nombre que necesita, reduciendo la exposición de la consulta completa.
• Split-horizon (vistas). Separe la vista interna de la externa para que la infraestructura privada no se filtre en respuestas públicas. BIND (views), Unbound y Knot Resolver implementan este patrón.

DNS protector: filtrado contra C2 y phishing

El DNS protector (Protective DNS o PDNS) convierte el resolver en un control de seguridad activo: antes de resolver, comprueba el dominio contra inteligencia de amenazas y bloquea o redirige (sinkhole) lo malicioso. Es uno de los controles con mejor relación coste/impacto porque actúa antes de que se establezca la conexión, encaja de forma natural en una arquitectura Zero Trust y cubre a la vez varios escenarios:

• C2 de malware. Si un equipo se infecta, el bloqueo de la resolución del dominio de mando y control corta la comunicación con el atacante aunque el binario ya se ejecute.
• Phishing. Bloquear dominios de phishing conocidos y dominios recién registrados (una señal fuerte de abuso) reduce el clic exitoso.
• Dominios DGA y tunneling. El análisis de patrones detecta dominios generados por algoritmo y consultas anómalas de tipo TXT o NULL propias de la exfiltración por túnel DNS (iodine, dnscat2).

En la práctica se implementa con Response Policy Zones (RPZ) alimentadas por feeds de amenazas, o con servicios gestionados como Cisco Umbrella, Cloudflare Gateway, NextDNS o Quad9. En el ámbito público, DNS4EU en Europa y los servicios PDNS de agencias como el NCSC ofrecen filtrado de referencia. Tanto NIST como CISA recomiendan el PDNS como control base.

Checklist de seguridad DNS para pymes

Una pyme no necesita un equipo de DNS dedicado para elevar mucho su nivel. Este es el orden de prioridad:

1. Firmar los dominios propios con DNSSEC y publicar el DS en el registrador.
2. Fijar un resolver de confianza en toda la organización (por ejemplo 9.9.9.9 con filtrado) y usar DoT hacia él.
3. Activar un DNS protector que bloquee C2, phishing y dominios recién registrados.
4. Desactivar el DoH del navegador por política para que no salte el filtrado corporativo.
5. Cerrar la recursión abierta y aplicar rate limiting en cualquier resolver propio.
6. Registrar y revisar los logs de DNS: son de las telemetrías más rentables para detectar compromisos.
7. Mantener el software de DNS parcheado frente a fallos críticos de servidor.
8. Monitorizar la caducidad de firmas DNSSEC para evitar caídas por RRSIG expirado.

Si su organización carece de personal para operar estos controles, el servicio de ciberseguridad gestionada de Secra integra el filtrado DNS, la monitorización de consultas y la respuesta ante incidentes en una sola capa.

Preguntas frecuentes

¿DNSSEC cifra mis consultas DNS?

No. DNSSEC firma las respuestas para garantizar su autenticidad e integridad, pero no aporta confidencialidad: un observador de red sigue viendo en claro el dominio y la IP. Para cifrar la consulta necesita transporte cifrado como DoT o DoH. Son controles complementarios, no alternativos.

¿Qué es mejor para una empresa, DoH o DoT?

Para una red corporativa, DoT hacia un resolver interno de confianza suele ser preferible: cifra la consulta y mantiene la visibilidad y el filtrado. El riesgo es el DoH del navegador, que puede eludir el resolver corporativo; conviene desactivarlo por política y usarlo solo de forma controlada.

¿El DNS protector sustituye al antivirus o al firewall?

No, es una capa adicional. El DNS protector actúa antes de que se establezca la conexión, cortando la resolución de dominios maliciosos de C2 o phishing. Complementa al EDR, al firewall y al correo, pero no los reemplaza: forma parte de una defensa en profundidad.

¿DNSSEC evita el pharming y el envenenamiento de caché?

DNSSEC neutraliza el envenenamiento de caché y las respuestas falsificadas cuando tanto la zona firma como el resolver valida. No protege frente al pharming basado en el fichero hosts local ni frente a routers comprometidos, porque esos ataques ocurren fuera de la cadena de confianza DNS.

¿Cómo compruebo si un dominio tiene DNSSEC activo?

Con dig +dnssec dominio.com y verificando el flag ad (authenticated data) en la respuesta de un resolver validante, o con la herramienta delv. Para un diagnóstico visual de la cadena de confianza completa, DNSViz muestra cada eslabón y señala dónde falla la validación.