Diagnosticar el secuestro de DNS por parte del ISP cuando los resolutores estándar fallan

Karthikey Hegde descubrió que su contenedor Podman no podía acceder a un sitio web específico, a pesar de seguir los pasos habituales de resolución de problemas. Las consultas enviadas a grandes resolutores públicos como Google y Cloudflare devolvían todas una dirección IP propiedad de su proveedor de servicios de Internet (ISP), mientras que el DNS cifrado revelaba el destino correcto. Este incidente pone de manifiesto una vulnerabilidad crítica para quienes alojan sus propios servicios: cambiar la configuración del servidor DNS suele no ofrecer ninguna protección si el ISP intercepta el tráfico en el puerto 53.

Qué ocurrió

La investigación de Hegde comenzó cuando un servicio en su entorno local no logró resolver un nombre de dominio. Probó varios resolutores DNS públicos, incluidos 1.1.1.1, 8.8.8.8 y 9.9.9.9. Sorprendentemente, cada consulta en texto plano devolvía la misma dirección IP, lo cual una búsqueda WHOIS confirmó que pertenecía a su ISP. Cuando utilizó el endpoint de DNS sobre HTTPS (DoH) de Cloudflare, la consulta devolvió la dirección IP legítima del sitio objetivo. Esta discrepancia demostró que su ISP estaba interceptando activamente y reescribiendo paquetes DNS UDP en el puerto 53, independientemente de la dirección del resolutor especificada.

Este comportamiento hace ineficaz el consejo habitual. Decir a los usuarios que cambien a 1.1.1.1 o 8.8.8.8 asume que el ISP reenviará fielmente esos paquetes. En realidad, el tráfico UDP sin autenticación en el puerto 53 puede ser interceptado por cualquier dispositivo de red en el camino. Como se señaló en las discusiones técnicas alrededor del incidente, la interceptación de DNS UDP es trivial para los operadores de red. El equipo del ISP simplemente captura el paquete y responde con una respuesta falsificada, haciendo parecer que el resolutor solicitado proporcionó datos incorrectos.

Detalles clave

• Las consultas DNS en texto plano en el puerto 53 carecen de autenticación, permitiendo a los ISPs interceptar y reescribir respuestas fácilmente.
• Que múltiples resolutores públicos devuelvan la misma IP incorrecta sugiere un único punto de interceptación, no errores independientes de los resolutores.
• DNS sobre HTTPS (DoH) y DNS sobre TLS (DoT) cifran las consultas, impidiendo su modificación en tránsito por redes intermedias.
• Una discrepancia entre los resultados de DNS en texto plano y cifrados requiere verificación vía WHOIS para distinguir la manipulación de la geografía de CDN.
• Solo aproximadamente el 7.1% de los dominios evaluados estaban firmados con DNSSEC y eran válidos a noviembre de 2026, limitando la cobertura de detección.
• Los resolutores recursivos autoalojados como Unbound también son vulnerables si reenvían consultas vía UDP en texto plano por el puerto 53.

Antecedentes

La resolución DNS tradicional depende del puerto UDP 53, un protocolo diseñado para la velocidad más que para la seguridad. No verifica la identidad del respondedor ni la integridad de los datos. Cuando configuras un dispositivo para usar un servidor DNS específico, tu sistema operativo envía una solicitud a esa dirección IP. Sin embargo, sin cifrado, cualquier router o cortafuegos entre tu dispositivo y el resolutor pretendido puede leer la consulta e inyectar una respuesta falsa. Esto se conoce como secuestro o suplantación de DNS.

Los protocolos de DNS cifrado como DoH y DoT envuelven estas consultas en TLS, similar a cómo HTTPS asegura la navegación web. Esto impide que los operadores de red vean o alteren el contenido de la consulta. No obstante, la adopción no es universal. Muchas configuraciones autoalojadas aún dependen del reenvío en texto plano por simplicidad o compatibilidad. Además, DNSSEC añade una capa de validación criptográfica para asegurar la integridad de los datos, pero requiere que tanto el propietario del dominio firme los registros como que el resolutor los valide. Con solo una pequeña fracción de dominios que soportan DNSSEC, sigue siendo un escudo incompleto contra el secuestro.

Por qué importa

Para equipos que ejecutan software autoalojado, la resolución DNS fiable es fundamental. Si tu ISP secuestra el DNS, tus servicios internos pueden fallar al conectar con APIs externas, repositorios de paquetes o servidores de actualización. Más críticamente, podrías ser dirigido a servidores maliciosos controlados por el interceptor. Aunque los ISPs a menudo afirman que esto es para filtrado o caché, la falta de transparencia significa que no puedes confiar en el enrutamiento. Las herramientas de monitoreo estándar pueden reportar servicios como "caídos" cuando simplemente son inalcanzables debido a una resolución DNS incorrecta, llevando a tiempo perdido en la resolución de problemas.

Además, depender de resolutores públicos sin cifrado da una falsa sensación de seguridad. Los administradores de sistemas a menudo asumen que apuntar su cortafuegos o router a 1.1.1.1 asegura su tráfico DNS. Este incidente demuestra que esa suposición es errónea. Si tu ISP es lo suficientemente agresivo como para interceptar el tráfico del puerto 53 globalmente, tu elección de resolutor upstream es irrelevante a menos que impongas el cifrado en el borde de tu red. Esto afecta desde la orquestación de contenedores hasta simples tareas cron que obtienen datos externos.

Qué puedes hacer

• Prueba el secuestro comparando los resultados de dig en texto plano contra un endpoint DoH como el de Cloudflare para un dominio que falla.
• Verifica la propiedad de direcciones IP sospechosas usando búsquedas WHOIS para confirmar si pertenecen a tu ISP.
• Implementa DNS sobre HTTPS o DNS sobre TLS en tu resolutor local, como configurar AdGuard Home con dnscrypt-proxy.
• Evita usar el puerto 5353 para proxies de DNS cifrados para prevenir conflictos con servicios de multicast DNS como Avahi.
• Configura Unbound para reenviar consultas sobre TLS especificando forward-tls-upstream: yes y proporcionando un bundle CA.
• Usa herramientas como OONI para realizar mediciones independientes si sospechas de interferencia de red más allá del DNS.