Imagina una organización que ha protegido correctamente su sitio web. La aplicación tiene los parches al día, el acceso exige autenticación multifactor y el tráfico va cifrado con HTTPS.
Un atacante compromete la cuenta con la que se administra el dominio de la organización y modifica un registro DNS. A partir de ese momento, los usuarios que escriben la dirección correcta del sitio web acaban en una infraestructura controlada por el atacante.
La aplicación no fue vulnerada. Lo que cambió fue la ruta que lleva a los usuarios hasta ella.
Por eso el DNS sigue siendo tan valioso para los atacantes. Interviene al principio de la mayoría de las conexiones de red y los sistemas que dependen de él confían en sus respuestas. Un ataque con éxito puede redirigir el tráfico, interrumpir servicios, facilitar el robo de credenciales u ocultar las comunicaciones de un malware.
La seguridad del DNS no se reduce a reforzar (hardening) un servidor. Cada parte del sistema DNS cumple una función distinta, y cada una crea una superficie de ataque diferente.
Tres funciones del DNS que no conviene confundir
| Función DNS | Qué hace | Qué obtiene un atacante |
|---|---|---|
| DNS autoritativo | Publica los registros oficiales de un dominio | La capacidad de redirigir o interrumpir los servicios que usan ese dominio |
| Resolutor recursivo | Busca las respuestas DNS para los usuarios y las guarda en caché | La capacidad de influir en el destino al que se conectan muchos clientes, o de observarlo |
| Administración del DNS | Controla dominios, servidores de nombres, registros y claves de firma | El control de la propia configuración DNS |
Una organización puede operar algunas de estas funciones internamente y contratar otras a registradores, proveedores de nube o servicios de DNS gestionado. Saber quién opera cada función es el primer paso para protegerla.
Por qué el DNS ofrece tanto poder de influencia
Forma parte de casi todas las conexiones
Los usuarios trabajan con nombres como portal.example.com. Las aplicaciones, en última instancia, necesitan direcciones de red y otra información sobre los servicios. El DNS establece esa correspondencia.
Si el DNS no está disponible, muchas aplicaciones parecen caídas aunque sus servidores funcionen bien. Si el DNS devuelve una respuesta falsa, el cliente puede conectarse al destino equivocado. Eso convierte al DNS a la vez en una dependencia y en un punto de control.
No solo sirve a los sitios web
Los registros DNS ayudan a localizar sistemas de correo electrónico, servicios de identidad, endpoints de aplicaciones y otras infraestructuras. Tecnologías como SPF, DKIM y DMARC también utilizan registros DNS como parte de la autenticación del correo electrónico.
En los entornos Windows, el DNS está estrechamente ligado al descubrimiento de servicios de Active Directory. Por eso, los daños en el DNS interno pueden afectar a la autenticación, a la aplicación de directivas y al acceso a los recursos de la organización.
Se diseñó para un modelo de confianza anterior
El DNS tradicional dio prioridad a la resolución de nombres distribuida y a la disponibilidad. Las respuestas DNS básicas no se diseñaron para demostrar criptográficamente que procedían del propietario legítimo ni que no habían sido alteradas.
Las extensiones de seguridad y los transportes cifrados resuelven parte de esta debilidad, pero su despliegue no es automático y cada control resuelve un problema distinto.
No todos los ataques son iguales
Secuestro de dominios y de registros
Si un atacante compromete una cuenta del registrador, del alojamiento DNS o de administración, puede modificar la delegación de servidores de nombres o registros concretos. Es un ataque al plano de control: el atacante usa funciones de gestión legítimas sin tener autoridad legítima.
Las consecuencias pueden ir más allá de redirigir un sitio web. Los cambios en el DNS pueden redirigir el correo electrónico, interferir en los procesos de validación de dominio o, en algunas circunstancias, ayudar a un atacante a obtener certificados de confianza.
Aquí importan más una autenticación robusta, unos roles de administración restringidos, los bloqueos de registro (registry lock) cuando estén disponibles, las alertas de cambios y un procedimiento de recuperación guardado de forma independiente que el refuerzo del software del servidor DNS.
Denegación de servicio
Los atacantes pueden inundar los servidores autoritativos o los resolutores (resolvers) hasta que las solicitudes legítimas dejen de recibir respuesta. Como tantas aplicaciones dependen del DNS, un solo ataque puede hacer que varios servicios parezcan caídos a la vez.
Tener servidores redundantes en el mismo edificio o en la misma red no aporta suficiente resiliencia. Las organizaciones necesitan una diversidad de proveedores, de redes y geográfica acorde con su nivel de riesgo. Las plataformas autoritativas gestionadas suelen usar anycast, que distribuye el servicio entre muchas ubicaciones, pero los clientes siguen teniendo que proteger las cuentas y las configuraciones que controlan ese servicio.
Envenenamiento de caché
Los resolutores recursivos guardan las respuestas en caché para mejorar el rendimiento. Si un atacante consigue que un resolutor almacene una respuesta falsificada, los clientes que confían en esa caché pueden acabar en un destino elegido por el atacante.
Los resolutores modernos incluyen protecciones, y DNSSEC puede permitir la validación de datos DNS firmados. Sin embargo, el envenenamiento de caché no ha desaparecido. El trabajo sobre el protocolo y sus implementaciones continúa, porque el análisis, el almacenamiento en caché y la validación siguen siendo complejos.
Reflexión y amplificación
El DNS suele usar UDP, que no establece una conexión antes de enviar una respuesta. Un atacante puede falsificar la dirección de origen de la víctima y enviar consultas a servidores DNS expuestos. Esos servidores envían entonces sus respuestas a la víctima.
Cuando una consulta pequeña genera una respuesta mayor, el ataque se amplifica. Limitar el servicio recursivo a clientes autorizados, evitar los resolutores abiertos y aplicar la validación de direcciones de origen ayudan a reducir este abuso.
El DNS como canal para el malware
El malware a menudo necesita localizar su infraestructura de mando o enviar información fuera de la red. Los atacantes pueden usar dominios que cambian rápidamente, nombres de dominio generados, infraestructura fast-flux o tunelización DNS para que esa comunicación sea más difícil de bloquear.
Por tanto, el DNS no es solo algo que proteger. También es una valiosa fuente de telemetría de seguridad. Volúmenes de consultas inusuales, nombres largos que parecen codificados, dominios recién registrados y fallos repetidos pueden delatar dispositivos comprometidos.
Qué resuelven realmente DNSSEC y el DNS cifrado
En los debates sobre seguridad del DNS se suele tratar DNSSEC, DNS over HTTPS y DNS over TLS como mejoras intercambiables. Protegen propiedades diferentes.
DNSSEC permite que un resolutor validador verifique el origen y la integridad de los datos DNS firmados. Ayuda a defenderse de las respuestas falsificadas y del envenenamiento de caché. No cifra la consulta, no oculta qué dominio se solicitó ni mantiene disponible un servicio DNS durante un ataque.
DNS over HTTPS (DoH) y DNS over TLS (DoT) cifran el tráfico DNS entre un cliente y el resolutor. Eso protege la consulta frente a la simple observación o alteración en ese trayecto. No demuestra que el propietario del dominio haya publicado el registro correcto, y tampoco hace que el resolutor elegido sea de confianza.
El DNS cifrado también plantea un compromiso operativo. Si los dispositivos usan resolutores externos sin que nadie lo note, una organización puede perder la aplicación de políticas y la supervisión en su servicio DNS autorizado. Por eso, un despliegue seguro exige algo más que activar el cifrado: hay que decidir qué resolutores están autorizados y cómo seguirá siendo observable la actividad DNS.
Un modelo de defensa práctico
Proteger la autoridad
- Usa autenticación multifactor resistente al phishing en las cuentas del registrador y del alojamiento DNS, cuando esté disponible.
- Separa las cuentas de uso diario de la administración del DNS.
- Restringe quién puede modificar la delegación, los registros y las claves DNSSEC.
- Configura alertas ante cambios en servidores de nombres, zonas, registros y cuentas.
- Mantén los contactos de recuperación y las pruebas de propiedad del dominio fuera de la plataforma DNS afectada.
Separar las funciones
Los servidores autoritativos deben publicar zonas. Los resolutores recursivos deben responder a los clientes. Combinar un servicio autoritativo público con recursión sin restricciones aumenta la exposición y hace que las políticas sean más difíciles de analizar.
Limita la recursión a redes o identidades autorizadas. Permite las transferencias de zona solo a servidores secundarios autorizados. Mantén las interfaces de gestión fuera de internet siempre que sea posible.
Diseñar para el fallo
Usa servidores autoritativos independientes y elimina las dependencias de un único proveedor o de una única red cuando el impacto en el negocio lo justifique. Supervisa el DNS desde fuera de la organización para poder detectar fallos incluso cuando la supervisión interna dependa del mismo servicio DNS.
Haz copias de seguridad de los datos de zona y de la configuración, pero prueba también la restauración. Una copia de seguridad no resuelve la vulneración del registrador ni los cambios maliciosos en la delegación, salvo que el proceso de recuperación cubra esas capas.
Usar el DNS como control de seguridad
Los servicios de DNS de protección (Protective DNS) bloquean la resolución de dominios maliciosos conocidos antes de que se establezca una conexión. CISA y el National Cyber Security Centre del Reino Unido describen el DNS de protección como una forma de reducir la eficacia del phishing, el malware, las botnets y el ransomware.
Recopila los registros (logs) de los resolutores con controles adecuados de privacidad y de conservación. Relaciona los eventos DNS con las evidencias de endpoints, de identidad y de red. Una consulta sospechosa resulta más útil cuando los analistas pueden identificar el dispositivo que la hizo, el usuario y la conexión posterior.
Aplicar parches en todo el recorrido
La seguridad del DNS depende de algo más que el software DNS dedicado. Los sistemas operativos, los routers, los cortafuegos, los registradores, los portales de gestión y las credenciales de automatización pueden influir en el comportamiento del DNS.
En 2026, el National Cyber Security Centre del Reino Unido informó de que APT28 había explotado routers vulnerables para facilitar el secuestro de DNS y actividades de tipo adversary-in-the-middle. La lección va más allá de esa campaña: un atacante puede manipular el DNS a través de la infraestructura que lo rodea, sin necesidad de comprometer directamente el servidor autoritativo.
Lo que deben saber los profesionales de la tecnología
La mayoría de los desarrolladores no necesita operar servidores DNS, pero sí debe entender que la disponibilidad y la identidad de una aplicación empiezan antes de que la solicitud llegue a su código.
Los ingenieros de nube y de plataforma deben saber qué servicio es autoritativo, qué resolutores usan las cargas de trabajo, cómo interactúan las zonas privadas y públicas, y cómo falla el DNS entre regiones. Los equipos de seguridad deben tratar la administración de dominios como infraestructura privilegiada y usar los logs de DNS como parte de la detección. Los responsables deben saber quién puede recuperar el dominio si la cuenta de administración habitual no está disponible o ha sido comprometida.
La pregunta más útil para empezar es sencilla:
Si hoy nuestras respuestas DNS dejaran de estar disponibles o de ser fiables, ¿qué servicios fallarían—y quién podría restablecer la autoridad?
Si nadie puede responder con seguridad, la organización ha encontrado una brecha de seguridad y de resiliencia que vale la pena corregir.
Para profundizar
- NIST SP 800-81 Revision 3: Secure Domain Name System Deployment Guide — guía vigente sobre DNS autoritativo, resolutores recursivos, DNSSEC, DNS cifrado, DNS de protección y seguridad del despliegue. Publicada en marzo de 2026.
- CISA and NSA guidance on Protective DNS — explica cómo el filtrado DNS puede reducir la exposición a dominios maliciosos.
- RFC 7873: Domain Name System Cookies — describe una protección limitada frente a ataques de denegación de servicio, amplificación, falsificación y envenenamiento de caché.
- Microsoft guidance for securing DNS zone transfers — indicaciones prácticas para restringir las transferencias de zona del DNS de Windows.
- NCSC advisory on APT28 DNS hijacking — un ejemplo de 2026 de manipulación del DNS a través de infraestructura circundante comprometida.