¿Qué es el envenenamiento de DNS? Explicación del envenenamiento de la caché de DNS

El envenenamiento de caché DNS (suplantación de DNS) aprovecha las vulnerabilidades de su DNS y sus servidores. Descubra qué es y cómo solucionar este ciberataque.

Un ataque de envenenamiento de la caché DNS, también conocido como suplantación de DNS , es una de esas amenazas de las que no se habla tanto como del phishing o el malware. Ignorarla es el peor error que se puede cometer. El DNS es la base de casi todo lo demás en Internet. Por eso, cuando se ve comprometido, las consecuencias se extienden rápidamente. Los resultados son siempre dramáticos: se erosiona la confianza en los dominios, se rompe la autenticación del correo electrónico, se socava la seguridad del transporte y la reputación de la marca se ve afectada. 

Cuando alguien altera la forma en que los servidores de correo o los usuarios resuelven tu dominio, suele tratarse de suplantación de identidad, robo de credenciales, phishing o correos electrónicos que simplemente dejan de llegar. 

Esto es lo que realmente ocurre entre bastidores y por qué es tan difícil de detectar.

¿Qué es el envenenamiento de la caché DNS?

La función principal del DNS consiste en traducir los nombres de dominio a direcciones IP. El envenenamiento de caché se produce justo después de ese paso de traducción. Un atacante introduce datos DNS falsificados en un terminal, un navegador o un sistema. Así, cada vez que una víctima intenta acceder a una página web concreta, en lugar de llegar al sitio real, acaba en otro lugar. A menudo, se trata de una página que imita a la original y que se ha creado específicamente para recopilar información. 

Caché de DNS se asemeja a un ataque de tipo «hombre en medio». Un resolutor recibe datos falsificados, los almacena y empieza a proporcionar una dirección IP errónea para un dominio que, a simple vista, sigue pareciendo legítimo. A partir de ese momento, cualquier persona que utilice el resolutor contaminado es redirigida a la IP del atacante, y esto continúa hasta que caduca el registro almacenado en la caché. El atacante ni siquiera necesita acceder directamente al servidor DNS. Basta con que una sola respuesta falsificada llegue a la caché del resolutor para redirigir a todos los usuarios posteriores.
Veamos un ejemplo de cómo se desarrolla esto en la práctica.

¿Cómo funciona el envenenamiento de DNS?

Todo se reduce a una carrera. El atacante necesita que su respuesta falsa llegue al resolutor antes que la verdadera. A continuación se explica cómo se desarrolla todo paso a paso:

1. El usuario inicia una consulta DNS: Un navegador o una aplicación envía una consulta DNS a un resolutor recursivo solicitando la dirección IP de un dominio (por ejemplo, bank.com).
2. El resolutor comprueba su caché: Si la respuesta está almacenada en la caché y aún se encuentra dentro de su TTL, el resolutor la devuelve inmediatamente. De lo contrario, reenvía la consulta a los servidores DNS autoritativos.
3. El atacante inyecta una respuesta falsificada: Antes de que llegue la respuesta legítima y autorizada, el atacante envía una respuesta DNS falsificada que contiene una dirección IP maliciosa. Esto es posible adivinando o mediante un ataque de fuerza bruta el ID de transacción y el puerto de origen utilizados en la consulta original, una técnica conocida como «ataque Kaminsky».
4. El resolutor almacena el registro falsificado: Si la respuesta falsificada del atacante llega primero y coincide con el ID de transacción y el puerto esperados, el resolutor acepta y almacena en caché la dirección IP fraudulenta.
5. Los usuarios son redirigidos: Todas las consultas posteriores para ese dominio, procedentes de cualquier usuario que acceda al resolutor malicioso, devuelven la dirección IP del atacante, redirigiéndolos a un sitio fraudulento hasta que caduque el TTL de la caché o se vacíe manualmente la caché.

El atacante debe actuar antes de que caduque el TTL de los datos almacenados en caché. El DNS tradicional carece de validación criptográfica integrada, por lo que los resolutores no pueden confirmar si una respuesta es auténtica a menos que se hayan implementado DNSSEC y prácticas seguras de resolución. Hasta que caduque el registro falsificado, el resolutor sigue proporcionando la dirección IP falsa a los usuarios y sistemas afectados.

Cómo los atacantes contaminan las cachés de DNS

No hay una única forma de lograrlo. Los atacantes recurren a una serie de técnicas probadas para introducir registros DNS falsificados en la caché de un resolutor:

¿Por qué son eficaces los ataques de envenenamiento de DNS?

El DNS se diseñó pensando en la disponibilidad, no en la autenticación. El protocolo original nunca incluyó ninguna forma de confirmar que una respuesta fuera auténtica. Por lo tanto, a menos que se implemente DNSSEC y se valide realmente, los resolutores acaban confiando en las respuestas únicamente porque el identificador de transacción y el puerto coinciden por casualidad.

En la práctica, esa diferencia plantea varios problemas:

• Los registros almacenados en caché difunden datos erróneos a gran escala. Un resolutor contaminado puede proporcionar silenciosamente una respuesta errónea a miles de usuarios, organizaciones o resolutores posteriores, todo ello antes de que caduque el TTL.
• Los usuarios confían en los nombres de dominio que les resultan familiares. El navegador sigue mostrando una URL que parece correcta, por lo que a menudo no hay ningún indicio visible de que algo vaya mal, sobre todo cuando la página del atacante es una copia visual muy parecida a la auténtica.
• La visibilidad de los resolutores suele ser limitada. La mayoría de las organizaciones no disponen de mucha información sobre el comportamiento real de los resolutores recursivos que utilizan sus empleados, clientes o socios, lo que ralentiza la detección.
• La ventana de consulta-respuesta es vulnerable. Es estrecha, pero no lo suficiente. Los resolutores con un comportamiento predecible o una aleatorización deficiente ofrecen a los atacantes el margen justo para ganar la carrera.

Riesgos e impacto del envenenamiento del DNS

El envenenamiento de la caché DNS es un de suplantación de identidad: el atacante se hace pasar por un dominio legítimo y engaña a los usuarios para que accedan a un sitio web fraudulento. Funciona especialmente bien porque el DNS tradicional nunca se diseñó teniendo en cuenta la validación criptográfica, por lo que, por defecto, no hay nada que filtre los datos erróneos almacenados en la caché. Sin DNSSEC, los resolutores simplemente no tienen forma de distinguir una respuesta legítima de una falsificada.

He aquí por qué es importante:

1. Confianza en la marca y confianza de los clientes

Cuando los clientes son redirigidos desde tu dominio legítimo a uno falso, no culpan al DNS, sino a ti. Esa asociación puede minar silenciosamente la confianza con el paso del tiempo, y el daño es aún mayor en sectores como el financiero, el sanitario, el educativo, el minorista y el público, donde la integridad del dominio está directamente ligada a las relaciones con los clientes y al cumplimiento normativo.

2. Distribución de malware

Cuando los usuarios, los empleados o los sistemas automatizados acceden a un destino controlado por un atacante, suele aparecer malware. Desde allí, puede propagarse por los terminales y las redes, y sustraer de forma sigilosa datos confidenciales, como propiedad intelectual, registros de clientes e información financiera, información confidencial cuya pérdida resulta muy costosa.

3. Robo de credenciales y fraude financiero

Los sitios web fraudulentos se crean para recopilar contraseñas, datos , credenciales corporativas… Se recopila todo lo que los usuarios introducen. A partir de ahí, el paso es corto hacia el compromiso de las cuentas, las transacciones no autorizadas y el fraude que acaba afectando a la organización o a sus clientes.

4. Problemas de seguridad en el correo electrónico y los dominios

Los registros DNS constituyen la base sobre la que se sustenta la autenticación del correo electrónico. Por eso, cuando los datos del DNS son indebidos o erróneos, el problema no se limita a ese ámbito, sino que se propaga a los registros SPF, DKIM, DMARC, BIMI, MTA-STS y TLS-RPT, lo que da lugar a lagunas de visibilidad, fallos en la entrega, riesgo de suplantación de identidad y exposición a incumplimientos normativos. Una vez que se rompe la integridad del DNS, toda la cadena de autenticación del correo electrónico deja de ser fiable.

5. Repercusiones en el cumplimiento normativo y la respuesta ante incidentes

Para las organizaciones que operan bajo las normas PCI DSS, el RGPD, la HIPAA o los marcos gubernamentales de ciberseguridad, un incidente de envenenamiento de DNS puede suponer un riesgo real de incumplimiento normativo. Además, la carga de trabajo que supone la respuesta ante incidentes no aumenta de forma gradual. Cuando los registros DNS envenenados afectan a varios dominios, servicios o entornos de clientes a la vez, la limpieza se complica rápidamente.

Por qué el envenenamiento de la caché DNS es importante para los MSP y los MSSP

Para los MSP y MSSP que gestionan múltiples dominios de clientes, los ataques relacionados con el DNS y las configuraciones erróneas pueden suponer rápidamente un elevado coste operativo. Un solo dominio contaminado o mal configurado puede dar lugar a incidencias de soporte técnico, quejas sobre la entrega de correos electrónicos, preocupaciones por el phishing y problemas de confianza de los clientes en toda una cartera gestionada. La supervisión centralizada de dominios, los informes de autenticación y el acceso basado en roles ayudan a los proveedores de servicios a identificar los problemas más rápidamente y a gestionar los dominios de los clientes sin tener que cambiar entre herramientas inconexas.

Ejemplos reales de ataques de envenenamiento de DNS

Se han observado ataques de envenenamiento de DNS en diversos sectores y escenarios de ataque. Los siguientes ejemplos ilustran los patrones habituales, las repercusiones y las lecciones aprendidas:

Cómo detectar el envenenamiento de la caché DNS

La mayoría de las personas a las que se redirige a través de una caché DNS contaminada nunca se dan cuenta. Por eso es tan difícil detectarlo desde el punto de vista del usuario, por lo que la detección suele recaer en quien supervisa la infraestructura. Algunos aspectos a los que hay que prestar atención:

• Redireccionamientos inesperados en páginas web. Alguien escribe el dominio que visita habitualmente y acaba en una página que no le resulta familiar.
• Advertencias por discrepancia en los certificados SSL/TLS. Si el navegador muestra un error de certificado, no lo ignores. Normalmente significa que la conexión no está llegando a donde debería.
• Páginas de inicio de sesión falsificadas. A simple vista, la página parece correcta, pero la URL, el diseño o los detalles del certificado presentan pequeñas discrepancias. Merece la pena echar un segundo vistazo cada vez.
• Respuestas DNS que varían según el servidor de resolución. Realiza una consulta sobre el mismo dominio a través de tu servidor de resolución corporativo y, a continuación, a través de uno público, por ejemplo, 1.1.1.1 u 8.8.8.8. Si las respuestas son diferentes, significa que hay algún problema.
• Entradas inusuales en los registros DNS. Valores TTL extraños, fuentes de respuesta que no se ajustan a lo esperado o un repunte repentino de consultas para un dominio concreto.
• Una caída del tráfico sin motivo aparente. Si las tasas de análisis o de autenticación bajan y no hay una causa evidente, conviene comprobar el DNS antes de descartarlo.
• Alertas procedentes de tu infraestructura de seguridad. No hay que ignorar las alertas de las herramientas SIEM, EDR o de supervisión de redes que señalan actividad DNS o conexiones a rangos de IP conocidos como maliciosos.
• Anomalías en los informes DMARC. Un aumento repentino de los errores de autenticación puede ser un indicio de que se han manipulado los registros SPF, DKIM o DMARC vinculados a tu dominio.

Qué hacer si sospechas que se ha producido un envenenamiento de la caché DNS

Empieza por comparar las respuestas DNS de varios resolutores utilizando la herramienta verificador de registros DNS de PowerDMARC o herramientas de línea de comandos como nslookup y dig. A partir de ahí:

1. Vacíe la caché de DNS en los sistemas afectados. Windows: ipconfig /flushdns. macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. Linux: sudo systemd-resolve –flush-caches.
2. Cambia a un servidor de resolución recursivo de confianza, como 1.1.1.1 u 8.8.8.8, mientras compruebas cuál es el problema con tu servidor de resolución principal.
3. Revisa los registros DNS de todos los dominios críticos, especialmente aquellos que admiten SPF, DKIM, DMARC, MTA-STS, TLS-RPT y BIMI, utilizando el analizador de dominios de PowerDMARC.
4. Comprueba el estado de validación de DNSSEC de tus dominios con la herramienta DNSSEC Checker de PowerDMARC.
5. Revisa los informes agregados de DMARC para detectar anomalías en la autenticación que puedan indicar una interrupción a nivel de DNS.
6. Notifica a los usuarios y partes interesadas afectados si el incidente ha supuesto la exposición de credenciales o redireccionamientos maliciosos relacionados con tu dominio.

Estrategias de prevención y mitigación del envenenamiento de DNS

1. Implementa DNSSEC cuando sea compatible

DNSSEC añade firmas criptográficas a los registros DNS, de modo que los resolutores pueden confirmar que una respuesta procede realmente de la fuente autorizada correcta y que no ha sido alterada durante el trayecto. El propio DNS sigue sin autenticar las respuestas por sí mismo, pero DNSSEC subsana esa carencia y reduce considerablemente la probabilidad de que se cuelen respuestas falsificadas. Puedes verificar tu propia configuración utilizando el comprobador de DNSSEC de PowerDMARC.

2. Mantén actualizados los resolutores DNS y la infraestructura

Las vulnerabilidades conocidas del DNS son objeto de ataques constantes, por lo que mantenerse al día es más importante de lo que podría parecer. La gestión periódica de parches, las auditorías de configuración y el uso de resolutores recursivos de confianza y bien mantenidos reducen la superficie de ataque. Hay dos ajustes que conviene comprobar: la aleatorización del puerto de origen y la entropía del ID de consulta. Ambos hacen que sea mucho más difícil adivinar el ID de la transacción.

3. Utiliza resolutores recursivos de confianza

Configura los puntos finales y las redes para que utilicen servidores DNS centrados en la seguridad, como Cloudflare (1.1.1.1), Google (8.8.8.8) o Quad9 (9.9.9.9). Estos proveedores realizan validaciones DNSSEC, admiten protocolos DNS cifrados (DoH y DoT) y filtran activamente los dominios conocidos por ser maliciosos, lo que elimina gran parte del riesgo sin que ello suponga un esfuerzo adicional por tu parte.

4. Solucionar los registros DNS mal configurados o abandonados

Los registros DNS antiguos o mal configurados, como las entradas DNS «colgadas» , crean vulnerabilidades que los atacantes no dudan en aprovechar, incluida la apropiación de subdominios, lo que no hace sino agravar los riesgos que ya plantea el envenenamiento de caché. Las auditorías periódicas de tus registros DNS mediante el verificador de registros DNS de PowerDMARC resultan de gran ayuda en este sentido.

5. Supervisar y reforzar los registros de autenticación del correo electrónico

SPF, DKIM, DMARC, BIMI, MTA-STS y TLS-RPT dependen del DNS para funcionar. Un solo cambio no autorizado en tu zona DNS puede afectar silenciosamente a la autenticación del correo electrónico sin que haya ninguna advertencia evidente, y precisamente por eso es necesario que se trate de una comprobación continua y no de una configuración puntual. El Analizador de dominios de PowerDMARC está diseñado para auditar tu estado de autenticación completo de una sola vez.

6. Reforzar la seguridad del transporte de correo electrónico con MTA-STS y TLS-RPT

MTA-STS exige que los servidores de correo utilicen TLS al enviar mensajes a tu dominio. Aunque no impedirá directamente el envenenamiento de la caché DNS, sí reduce los riesgos de ataques de degradación que suelen ir de la mano de un DNS comprometido. Combínalo con TLS-RPT y obtendrás visibilidad sobre los fallos de entrega en la capa de transporte y las infracciones de las políticas, lo que resulta ser una señal útil cuando intentas averiguar si el DNS es la causa de una interrupción en el servicio de correo electrónico.

7. Actualizar el software de seguridad de los dispositivos finales

Si un dispositivo ya ha accedido a un sitio malicioso debido a un envenenamiento de DNS, hay que actuar con rapidez. Actualiza el antivirus y el software de seguridad del dispositivo y, a continuación, ejecuta un análisis completo para detectar y eliminar cualquier elemento que se haya podido instalar. Se trata de una medida reactiva por naturaleza, pero es un paso necesario tanto para los usuarios finales como para los equipos de TI a la hora de responder a un incidente activo.

Además de estas estrategias, resulta útil disponer de un conjunto de herramientas fiables de análisis de DNS y dominios para realizar una validación continua. El conjunto de herramientas de PowerDMARC cubre este aspecto con el DNS Record Checker, el DNSSEC Checker y el Domain Analyzer, el verificador de MTA-STSy el verificador de TLS-RPT.

Cómo ayuda PowerDMARC a reforzar la seguridad de los dominios y del correo electrónico

La seguridad del DNS y la autenticación del correo electrónico están estrechamente relacionadas. SPF, DKIM, DMARC, BIMI, MTA-STS y TLS-RPT dependen todos de registros DNS precisos y fiables. Si estos registros faltan, están mal configurados o son difíciles de supervisar, las organizaciones se enfrentan a un mayor riesgo de suplantación de identidad, fallos en la entrega y riesgos de incumplimiento normativo, todo lo cual se ve agravado cuando se ve comprometida la integridad del DNS.

PowerDMARC ofrece a los equipos de seguridad y a los proveedores de servicios gestionados (MSP) una plataforma centralizada para gestionar la autenticación del correo electrónico en distintos dominios. La plataforma proporciona informes claros, una rápida detección de incidencias, servicios de autenticación alojados y herramientas para simplificar la gestión de protocolos basados en DNS, sin necesidad de realizar cambios manuales en el DNS con cada actualización.

• Supervisión y generación de informes de DMARC: visibilidad de las fuentes de envío, los fallos de autenticación y los intentos de suplantación de identidad, incluidas las anomalías que puedan indicar una interrupción a nivel de DNS.
• SPF alojado y gestión automatizada de SPF: elimina los problemas relacionados con los límites de consultas SPF y reduce la necesidad de realizar cambios manuales en el DNS al añadir nuevas fuentes de envío.
• MTA-STS y TLS-RPTalojados: refuerzan la seguridad del transporte del correo electrónico y ofrecen informes sobre los y problemas relacionados con las políticas.
• BIMI alojado: ayuda a mejorar la confianza en la marca y el reconocimiento en la bandeja de entrada mediante la gestión de los registros BIMI y los requisitos de certificación.
• Agrupación de dominios y acceso basado en roles: imprescindibles para empresas y proveedores de servicios gestionados (MSP) que gestionan varios dominios o carteras de clientes desde una única plataforma.
• Inteligencia sobre amenazas basada en IA: identifica patrones de suplantación de identidad, fuentes de envío no autorizadas y anomalías en la autenticación utilizando datos en tiempo real procedentes de toda la base de clientes global de PowerDMARC.

PowerDMARC también ofrece asistencia especializada a nivel mundial para ayudar a los equipos de seguridad, a los administradores y a los proveedores de servicios gestionados (MSP) a configurar, supervisar y resolver problemas relacionados con los registros de autenticación con total confianza. 

Empieza tu prueba gratuita de 15 días y obtén una visión más clara del estado de la autenticación del correo electrónico de tu dominio.

Preguntas frecuentes sobre el envenenamiento de la caché DNS

¿Cómo se detecta el envenenamiento de DNS?

Presta atención a los redireccionamientos inesperados de sitios web, las advertencias sobre certificados SSL/TLS, las respuestas DNS incoherentes entre los distintos resolutores, las entradas inusuales en los registros DNS y las anomalías en los informes agregados de DMARC. Al comparar los resultados de las consultas con el verificador de registros DNS de PowerDMARC o con herramientas de línea de comandos como «dig» y «nslookup», se puede determinar rápidamente si un resolutor está devolviendo una dirección IP inesperada.

¿Cuál es un ejemplo real de envenenamiento de DNS?

Una técnica habitual tiene como objetivo a los usuarios de plataformas de intercambio de criptomonedas: los atacantes corrompen un resolutor DNS y los redirigen a un sitio de phishing visualmente idéntico que recopila credenciales y acceso a los monederos. Otra técnica es la manipulación a nivel de proveedor de servicios de Internet (ISP), en la que los resolutores inyectan respuestas falsificadas para redirigir discretamente a los usuarios a páginas publicitarias o de advertencia.

¿Cuál es la diferencia entre el envenenamiento de DNS y la suplantación de DNS?

El envenenamiento de la caché DNS consiste en introducir registros falsificados en la caché de un resolutor, de modo que las consultas devuelvan resultados maliciosos hasta que caduque el TTL. La suplantación de DNS es una categoría más amplia que abarca el envenenamiento de la caché y otros métodos, como la interceptación del tráfico DNS mediante un ataque de «hombre en el medio». En la práctica, ambos términos se utilizan indistintamente.

¿Puede el DNSSEC evitar el envenenamiento del DNS?

Sí, siempre que se implemente y se valide de principio a fin. El DNSSEC añade firmas criptográficas a los registros DNS, por lo que los resolutores que validen dichas firmas pueden detectar y rechazar las respuestas falsificadas. Solo funciona si el propietario del dominio firma los registros de zona y el resolutor los valida. Una implementación parcial o mal configurada puede generar una falsa sensación de seguridad.

¿Evita MTA-STS el envenenamiento de la caché DNS?

No. MTA-STS exige el cifrado TLS para la entrega de correo y reduce el riesgo de ataques de «downgrade», pero no aborda directamente el envenenamiento de la caché DNS. En combinación con TLS-RPT, añade informes sobre los fallos de entrega en la capa de transporte. Considéralo como un control complementario para la seguridad del transporte del correo electrónico, no como una defensa contra el DNS.

¿Por qué es importante la seguridad del DNS para la autenticación del correo electrónico?

SPF, DKIM, DMARC, BIMI, MTA-STS y TLS-RPT dependen todos de los registros DNS para funcionar. Si un atacante consigue manipular las respuestas del DNS, estos controles pueden desactivarse o eludirse, lo que abre la puerta a la suplantación de identidad, el phishing y los fallos en la entrega. La integridad del DNS es fundamental para una gestión eficaz de la seguridad del correo electrónico.

• Acerca de
• Últimas publicaciones

Ahona Rudra

Experto en seguridad de dominios y correo electrónico en PowerDMARC

Ahona es la Directora de Marketing de PowerDMARC, con más de 5 años de experiencia escribiendo sobre temas de ciberseguridad, especializada en seguridad de dominios y correo electrónico. Ahona tiene un posgrado en Periodismo y Comunicaciones, consolidando su carrera en el sector de la seguridad desde 2019.

Últimas publicaciones de Ahona Rudra (ver todas)

• ¿Qué ocurre cuando los chatbots con IA filtran datos internos de la empresa? - 21 de agosto de 2026
• PowerDMARC se integra de forma nativa con Autotask - 18 de agosto de 2026
• Protocolos SSL y TLS: ¿cuál es la diferencia? - 13 de agosto de 2026