Vulnerabilidades del DNS: 10 puntos débiles habituales y cómo solucionarlos

Una vulnerabilidad del DNS es una deficiencia en la configuración, el alojamiento o la gestión del DNS de un dominio que un atacante puede aprovechar, como un resolutor abierto, la falta de una firma DNSSEC o un registro CNAME olvidado. La mayoría de estas deficiencias se deben a configuraciones erróneas y a registros obsoletos, más que a fallos de software, lo que significa que es posible detectarlas y solucionarlas antes de que se produzca un incidente.

¿Qué son las vulnerabilidades DNS?

Una vulnerabilidad del DNS es un fallo operativo, arquitectónico o de configuración en la implementación del Sistema de Nombres de Dominio que pone en peligro la confidencialidad, la integridad o la disponibilidad del tráfico de red.

Estas deficiencias suelen darse en cuatro niveles operativos fundamentales:

Gestión del registrador y de las cuentas: Credenciales compartidas, falta de autenticación multifactorial y omisión de bloqueos de registro que dejan expuesto el control de tus servidores de nombres.
Servidores de nombres autoritativos: Reglas de transferencia de zona poco restrictivas, demonios de servidor sin parches, falta de límites en la frecuencia de consultas o ausencia de redundancia de proveedores.
Resolventes y transporte: Resolventes recursivos accesibles desde la red pública de Internet, transmisión sin cifrar a través de UDP en texto plano o identificadores de transacción con aleatorización deficiente.
Registros DNS: Entradas CNAME huérfanas que apuntan a infraestructura fuera de servicio, cadenas criptográficas DNSSEC incompletas o registros de correo electrónico y certificados ausentes.

Es importante diferenciar entre vulnerabilidades y ataques. Una vulnerabilidad es el fallo subyacente o la configuración incorrecta que existe en tu sistema. Un ataque es el aprovechamiento deliberado de esa debilidad por parte de un tercero malintencionado. Comprender esta distinción permite a los equipos de seguridad eliminar las debilidades antes de los ataques al DNS puedan materializarse.

10 vulnerabilidades comunes del DNS

Las siguientes diez vulnerabilidades de seguridad constituyen los fallos más habituales que se detectan en las implementaciones de DNS de las empresas.

1. Resolutores DNS abiertos {#open-dns-resolvers}

Un resolutor recursivo abierto es un servidor DNS conectado a la red pública de Internet que resuelve consultas recursivas para cualquier persona, en lugar de limitar la resolución a clientes locales autorizados.

Qué permite: Los atacantes suplantan la dirección IP de origen de la víctima y envían consultas a resolutores abiertos, generando respuestas masivas que desbordan a la víctima mediante un ataque distribuido ataques DDoS de amplificación DDoS de amplificación de DNS.
Cómo comprobarlo: Realiza una consulta a la dirección de tu servidor público desde una red externa:

dig @<your-server-ip> example.com

Si el servidor devuelve una respuesta con el indicador «ra» (recursión disponible) activada, su resolutor es vulnerable a la recursión pública no autorizada.
Solución: Desactivar por completo la recursividad en los servidores autoritativos o restringirla a rangos de IP y subredes de confianza mediante listas de control de acceso, de acuerdo con nuestras prácticas recomendadas de seguridad de DNS.

2. DNSSEC ausente o defectuoso

El DNSSEC (Extensiones de seguridad del Sistema de Nombres de Dominio) utiliza firmas criptográficas para validar la autenticidad de los datos del DNS. Si se opera sin DNSSEC, o si se permite que las configuraciones criptográficas se salten los registros RRSIG caducados o los registros DS que no coinciden en el registrador, las resoluciones quedan sin verificar.

Qué permite: Sin verificación criptográfica, los resolutores recursivos pueden aceptar paquetes de respuesta falsificados inyectados por atacantes en la ruta de red, lo que da lugar a el envenenamiento de la caché y la redirección del tráfico.
Cómo comprobarlo: Comprueba la cadena criptográfica de tu dominio utilizando nuestro verificador de DNSSEC gratuito basado en navegador verificador de DNSSEC, o descubre cómo las firmas vinculan los registros en nuestra guía básica sobre DNSSEC.
Solución: Firma tus archivos de zona, publica los registros de Delegation Signer (DS) correspondientes en tu registrador de dominios e implementa procedimientos automatizados de renovación de claves para evitar interrupciones en la validación.

3. Transferencias sin restricciones de zona (AXFR)

Una transferencia completa asíncrona (AXFR) es un mecanismo de protocolo diseñado para sincronizar los datos de la zona entre los servidores de nombres primarios y secundarios. Una transferencia de zona sin restricciones permite a cualquier usuario de Internet solicitar y descargar el archivo de zona completo.

Qué permite: Filtraciones de reconocimiento. Los adversarios obtienen un mapa completo de tu superficie de ataque digital, lo que deja al descubierto las convenciones de nomenclatura internas, los servidores de prueba, las puertas de enlace VPN y los subdominios no listados.
Cómo comprobarlo: Intenta realizar una consulta de transferencia de zona directamente en tu servidor de nombres autoritativo:

dig AXFR example.com @ns1.example.com

Un servidor seguro responde con «Transferencia fallida» o rechaza la conexión. Si el comando devuelve una lista completa de registros, significa que tu configuración de transferencia está abierta.
Solución: Restringir las solicitudes AXFR exclusivamente a direcciones IP explícitas pertenecientes a servidores de nombres secundarios autenticados mediante listas de control de acceso (ACL) estrictas.

4. Registros DNS sin asignar

Un registro DNS «suspenso» se produce cuando una entrada de tu zona (como un registro CNAME, A o NS) apunta a un recurso en la nube, un servidor web o un depósito de almacenamiento externo que se ha dado de baja o se ha eliminado sin eliminar el puntero DNS correspondiente.

Qué permite: Los atacantes identifican el nombre del objetivo abandonado, crean ese mismo recurso en la plataforma del proveedor (como AWS, Azure, GitHub Pages o Heroku) y se apropian del control de tu subdominio mediante una toma de control del subdominio.
Cómo comprobarlo: Exporta tu zona utilizando nuestro completo herramienta de búsqueda de registros DNS y comprueba que todos los puntos finales externos, destinos CNAME y hosts en la nube sigan estando activamente asignados a tu organización.
Solución: Establecer protocolos de desactivación automatizados para eliminar los registros DNS correspondientes cada vez que se retiren de servicio infraestructuras en la nube o servicios web de terceros.

5. Seguridad deficiente de las cuentas de los registradores

Los registradores de dominios gestionan las delegaciones de los servidores de nombres de nivel superior de tus dominios. Proteger el portal de tu registrador con credenciales de autenticación de un solo factor, buzones administrativos compartidos o no activar los bloqueos de protección a nivel de registrador crea un punto único de fallo.

Qué permite: Los atacantes se hacen con las credenciales de acceso del registrador, modifican las delegaciones de tu servidor de nombres autoritativo y redirigen todo el tráfico web y de correo global hacia una infraestructura maliciosa en un devastador secuestro de DNS .
Cómo comprobarlo: Revisa la consola de tu registrador para comprobar si la se aplica se aplica en todos los puestos de administrador y si están activas las marcas «Registry Lock» o «Registrar Lock».
Solución: Implantar la autenticación multifactorial en todos los inicios de sesión de los registradores, aplicar códigos de estado de bloqueo del registro a los dominios críticos y establecer un acceso empresarial específico basado en roles.

6. Servidores DNS y controles de acceso mal configurados

Las implementaciones de software predeterminadas suelen incluir configuraciones de acceso amplias, interfaces administrativas abiertas a Internet y mensajes de versión que se muestran en respuesta a simples consultas de sondeo.

Qué permite: Los atacantes descubren el software del servidor y los niveles de parches mediante consultas de banner como version.bind, identifican vulnerabilidades sin parchear y aprovechan los controles de acceso débiles para manipular los parámetros de configuración. Consulta nuestra guía básica sobre qué es un servidor DNS para comprender las bases operativas seguras.
Cómo comprobarlo: Consulta la cadena de identidad del servidor desde un terminal:

dig version.bind CHAOS TXT @ns1.example.com

Un servidor bien protegido oculta esta información o devuelve una respuesta genérica.
Solución: Ocultar las cadenas de versión del servidor, restringir el acceso a las interfaces de gestión a las VPN administrativas, implementar la limitación de la tasa de respuesta (RRL) y aplicar el principio del mínimo privilegio en todos los archivos de configuración.

7. Punto único de fallo en el alojamiento de DNS

Alojar todos los servidores de nombres autoritativos con un único proveedor de DNS, o implementar servidores de nombres dentro del mismo sistema autónomo (AS) físico, genera una peligrosa fragilidad operativa.

Qué permite: Un ataque DDoS dirigido, una interrupción del servicio del proveedor o un error de enrutamiento inhabilitan por completo sus servidores de nombres autoritativos, lo que hace que sus sitios web, API y correo electrónico empresarial queden totalmente inaccesibles, tal y como quedó demostrado durante la interrupción generalizada de Dyn en 2016.
Cómo comprobarlo: Revisa los registros NS de tu dominio para comprobar si tus servidores de nombres se resuelven en bloques de red distintos y sistemas autónomos independientes.
Solución: Implementar una arquitectura de DNS secundario con dos proveedores, distribuyendo la resolución autoritativa entre dos servicios de DNS independientes y geográficamente dispersos.

8. Tráfico DNS sin cifrar

Las consultas y respuestas DNS tradicionales se transmiten a través del puerto 53 mediante UDP y TCP en texto sin cifrar. Sin cifrado, las redes locales, los proveedores de servicios de Internet y los operadores de tránsito pueden leer todas las consultas de dominio.

Qué permite: Escucha en la ruta, elaboración de perfiles de usuarios y manipulación en la ruta, en la que los atacantes de la red interceptan consultas en texto claro y devuelven respuestas fraudulentas.
Cómo comprobarlo: Revisa la configuración del punto final y del router para comprobar si las resoluciones se enrutan a través de DNS sobre HTTPS (DoH), DNS sobre TLS (DoT) o DNS sobre QUIC (DoQ), en lugar de a través del puerto UDP 53 sin cifrar.
Solución: Configurar los resolutores locales, los puntos finales y los reenviadores para exigir el cifrado de transporte moderno mediante TLS estándar.

9. Software de DNS sin parches

Los demonios de DNS como BIND, Unbound, PowerDNS y el DNS de Windows Server requieren un mantenimiento periódico mediante parches. El uso de versiones antiguas de estos demonios expone a las redes a vulnerabilidades conocidas documentadas en las bases de datos públicas de CVE.

Lo que permite: La ejecución remota de código, la corrupción de memoria y los ataques de complejidad algorítmica que bloquean los servidores de nombres, como la vulnerabilidad KeyTrap (CVE-2023-50387) en los motores de validación DNSSEC o el vector de envenenamiento de caché DNS SAD (CVE-2020-25705).
Cómo comprobarlo: Compara las cadenas de compilación de los demonios en ejecución con los avisos de seguridad de los proveedores y suscríbete a los canales de notificación de los principales desarrolladores de software de DNS.
Solución: Mantener programas de aplicación de parches activos, aislar los servicios DNS en contenedores restringidos o entornos operativos mínimos, y verificar que las compilaciones se ajusten a las versiones de seguridad actuales.

10. Falta de registros de seguridad y de correo electrónico

Si no publicas los registros de seguridad afirmativos en el archivo de zona DNS, tu dominio queda expuesto a la emisión no autorizada de certificados y a la suplantación de identidad en el correo electrónico saliente.

Qué permite: Sin un registro CAA, cualquier autoridad de certificación pública puede emitir certificados SSL/TLS para tu nombre de dominio. Del mismo modo, omitir las políticas SPF, DKIM y las estrictas políticas DMARC estrictas permite a los spammers enviar mensajes fraudulentos suplantando directamente la identidad de tu marca.
Cómo comprobarlo: Comprueba tus configuraciones de seguridad actuales con nuestro herramienta de comprobación de CAA, revisa tus políticas de autenticación con nuestro comprobador de registros DMARC, o realiza una evaluación completa a través del analizador de dominios.
Solución: Publicar registros CAA restrictivos que detallen los emisores de certificados autorizados y aplicar DMARC en p=reject en todos los dominios y subdominios de la organización.

Riesgos de seguridad del DNS: cuánto te cuestan estas vulnerabilidades

Dejar sin resolver las vulnerabilidades del DNS supone un riesgo directo para la empresa en los ámbitos financiero, operativo y normativo.

Tiempo de inactividad y pérdida de ingresos: Las configuraciones con un único proveedor y los riesgos de amplificación no mitigados favorecen las interrupciones que dejan fuera de servicio las operaciones web y las plataformas comerciales.
Interceptación de credenciales y redireccionamientos fraudulentos: El envenenamiento de caché y el secuestro de DNS desvían a los visitantes hacia servidores falsos diseñados para recopilar las credenciales de inicio de sesión de las empresas.
Fuga de datos corporativos: Los resolutores sin restricciones y los reenviadores mal configurados permiten a los atacantes eludir los cortafuegos y sustraer datos internos.
Suplantación de marcas y compromiso del correo electrónico empresarial: La ausencia de registros SPF, DKIM y DMARC permite a los atacantes engañar a clientes, socios y empleados con correos electrónicos falsificados.
Generación de certificados fraudulentos: La omisión de registros CAA aumenta la probabilidad de que se creen certificados TLS fraudulentos, lo que socava los supuestos de seguridad del transporte.
Incumplimientos en las auditorías y sanciones normativas: Los activos DNS no gestionados suelen incumplir los requisitos de control obligatorios establecidos en las normas SOC 2, ISO 27001 y PCI DSS.

La tabla siguiente resume cómo las vulnerabilidades habituales en la configuración del DNS se corresponden directamente con los vectores de ciberataque que estas permiten:

Vulnerabilidad de DNS detectada	Vector de ataque habilitado
Resolutores recursivos abiertos	Ataques de amplificación y reflexión del DNS
DNSSEC ausente o no validado	Envenenamiento y suplantación de la caché DNS
Transferencias de zona sin restricciones (AXFR)	Reconocimiento de la superficie de ataque y detección de la red interna
Registros CNAME y A sin asignar	Apropiación de subdominios y suplantación de cuentas
Cuentas de registrador sin proteger	Secuestro de DNS y redireccionamiento de dominios
Controles de acceso permisivos a los servidores de nombres	Aprovechamiento de vulnerabilidades del servidor y manipulación no autorizada de zonas
Proveedor de alojamiento con un único servidor de nombres	Interrupción total del servicio durante las caídas de los proveedores
Tráfico en texto claro por el puerto UDP 53	Interceptación en la ruta y manipulación no autorizada de consultas
Versiones obsoletas del demonio DNS	Denegación de servicio remota y explotación de servidores
Faltan los registros CAA y DMARC	Emisión no autorizada de certificados SSL y suplantación de dominios salientes

Cómo comprobar si tu dominio tiene vulnerabilidades de DNS

La realización de una auditoría estructurada en todo su conjunto de dominios permite detectar errores de configuración antes de que los atacantes los identifiquen:

Realiza un análisis básico del dominio: Introduce tu dominio Apex en nuestro analizador de dominios gratuito para evaluar tu estado general de seguridad e identificar las configuraciones que faltan.
Comprueba tu cadena DNSSEC: Comprueba tus claves raíz y delegadas con nuestro verificador de DNSSEC para asegurarte de que las firmas son válidas y de que las claves no han caducado.
Test authoritative zone transfer restrictions: Execute dig AXFR example.com @<nameserver> against every authoritative host to confirm that public zone dumping is rejected.
Comprueba los permisos de recursividad: Consulta tus servidores de autoridad desde fuera del rango de direcciones IP de tu empresa para asegurarte de que la resolución recursiva está desactivada.
Comprobar si hay punteros sueltos en los registros de la zona activa: Exporta todas las entradas publicadas utilizando nuestra herramienta de búsqueda de registros DNS y confirma que todos los recursos en la nube externos y los destinos CNAME siguen siendo válidos.
Comprueba los certificados y las medidas de protección del correo electrónico: Audita las entidades certificadoras autorizadas con nuestro verificador CAA y confirma las políticas de aplicación con nuestro verificador de registros DMARC.
Revisar la configuración de seguridad del registrador: Auditar las listas de acceso administrativo, confirmar la activación de la autenticación multifactorial y comprobar que los bloqueos del registro siguen activados.

Una auditoría puntual de la infraestructura ofrece una visión general del estado actual, pero para mantener una visibilidad constante es necesario realizar un seguimiento continuo de la seguridad del DNS con el fin de detectar desviaciones en tiempo real.

Cómo solucionar las vulnerabilidades del DNS

Para corregir las vulnerabilidades del DNS es necesario dar prioridad a las configuraciones administrativas y estructurales de mayor impacto:

Protege la capa de gestión: Aplica la autenticación multifactorial en los portales de los registradores de dominios y de DNS en la nube, asigna roles con el mínimo de privilegios y activa inmediatamente las protecciones de bloqueo del registrador.
Reducir la exposición de la red: Restringir las transferencias de zona exclusivamente a direcciones IP secundarias designadas, desactivar la recursividad en los servidores autoritativos e implementar la limitación de tasa.
Eliminar registros huérfanos: Elimina los registros CNAME, A y NS huérfanos que apuntan a infraestructuras abandonadas o a aplicaciones en la nube de terceros que ya no se utilizan.
Implementa la verificación criptográfica: Firma tus zonas con DNSSEC, verifica los registros DS del registrador y aplica una autenticación estricta del correo electrónico mediante DMARC, SPF y DKIM.

Para consultar nuestro proceso completo de refuerzo de la seguridad administrativa, lee las directrices de seguridad del NIST para el DNS.

Preguntas frecuentes

¿Cuál es la vulnerabilidad más habitual del DNS?

La vulnerabilidad más habitual del DNS es una configuración incorrecta. Los ajustes poco restrictivos, como los resolutores recursivos abiertos, las transferencias de zona sin autenticación, los registros huérfanos olvidados y los controles de acceso administrativo deficientes, son responsables de muchos más incidentes de seguridad que los ataques de «día cero» al software.

¿Cuál es la diferencia entre una vulnerabilidad del DNS y un ataque al DNS?

Una vulnerabilidad del DNS es una debilidad subyacente, una configuración incorrecta o una deficiencia arquitectónica en el sistema de dominios. Un ataque al DNS es el intento activo por parte de un adversario de aprovechar esa vulnerabilidad para robar datos, redirigir el tráfico o provocar interrupciones en el servicio.

¿Supone el puerto 53 un riesgo para la seguridad?

El puerto 53 no es intrínsecamente malicioso; es el puerto estándar para el DNS a través de UDP y TCP. Sin embargo, dejar el puerto 53 abierto a consultas recursivas del público en general convierte al servidor en un resolutor abierto, vulnerable a ataques de amplificación y a la inspección.

¿Con qué frecuencia debería realizar una auditoría de vulnerabilidades en el DNS?

Debes revisar constantemente tus configuraciones de DNS. Aunque las revisiones manuales de los permisos de los registradores y de los archivos de zona deben realizarse al menos una vez al trimestre, se recomienda llevar a cabo una supervisión automatizada para detectar modificaciones no autorizadas en los registros, certificados caducados y nombres de host sin asignar en cuanto surjan.

Palabras finales

Las vulnerabilidades del DNS ofrecen a los atacantes vías de acceso para interceptar el tráfico, lanzar ataques de denegación de servicio y suplantar marcas empresariales. Dado que la mayoría de los problemas de seguridad del DNS se deben a descuidos administrativos habituales y a desviaciones en la configuración, más que a vulnerabilidades de código de «día cero», las auditorías proactivas y un mantenimiento constante reducen significativamente la superficie de ataque global.