El 3 de noviembre un admin de homelab contó algo que conviene verificar por lo menos una vez al año: su proveedor de internet estaba contestando consultas DNS con una IP que no era la real. Un contenedor doméstico no alcanzaba un sitio externo, error instantáneo, y el diagnóstico obvio era culpar al DNS casero, sospechoso de siempre en estos montajes. Al revisar a mano apareció la trampa: la misma consulta resuelta por el camino clásico devolvÃa una IP, resuelta por DNS-over-HTTPS devolvÃa otra distinta. Y la primera era, ni más ni menos, de su ISP.
La explicación no tiene mistérica: el DNS en texto plano viaja sin cifrar. El upstream tradicional es UDP al puerto 53, un paquete legible; si tu ISP intercepta la consulta y la responde él mismo, o muta la respuesta en tránsito, para ti es indistinguible, porque no existe nada que firmar ni comprobar en ese camino. Lo que parecÃa un bug de tu software era la red del medio escribiendo la respuesta.
La demostración toma cinco minutos y vale la pena tenerla anotada. Primero resuelves un dominio por el camino clásico, por ejemplo apuntando dig al 1.1.1.1 sin cifrar. Después pides el mismo registro por el endpoint DoH de Cloudflare, desde una terminal con curl y la cabecera JSON de DNS. Si las dos respuestas difieren, alguien en el medio está editando. Para cerrar el caso, un reverse lookup de la IP sospechosa te dice de quién es: en el incidente original, la IP devuelta pertenecÃa al propio proveedor.
Los dos refugios falsos
La reacción tÃpica tiene dos mitades y las dos están mal. La primera: «yo corro Unbound de forma local, estoy cubierto». No: Unbound es un resolver recursivo y casi todo su trabajo lo ejecuta mandando consultas en texto plano a nameservers ajenos, raÃz incluida. Correrlo en tu máquina no cifra nada; la defensa real es un forward-zone hacia un upstream que hable DNS-over-TLS. La segunda: «con DNSSEC me protejo». Tampoco: DNSSEC valida, no cifra. Comprueba que la respuesta no fue falsificada en tránsito, pero tus consultas siguen viajando legibles; si la manipulación corrompe o borra la firma, el resolver devuelve SERVFAIL y te quedas igual sin respuesta. Y solo funciona si el dominio consultado tiene la cadena bien montada: según el censo de Defaults.Exposed al 2 de noviembre de 2026, apenas 7,12% de los dominios analizados tiene una cadena DNSSEC que valida de punta a punta, 23.854.462 sobre 334.831.177. En .com no llega al 5,5%. Lo más probable es que el dominio que estés consultando ahora mismo no esté firmado.
La prueba en mi pega
Lo valioso para mà es la lección operacional. Mantengo una flota de servidores con monitoreo y crons que consultan dominios públicos a cada rato; si el tránsito miente, mis alertas no distinguen caÃda real de respuesta falsificada, y termino diagnosticando al tun-tun. Por eso el contraste de cinco minutos no me parece paranoia: es una prueba barata que te dice si puedes confiar en tu propio resolver. En Chile, donde varios ISP corren DNS transparente con fines de «optimización» o de bloqueo, el test se recomienda solo.
El arreglo es conocido: cifra el upstream con DoT o DoH, sea con dnscrypt-proxy o configurando el resolver local para reenviar por TLS, y ten claro el lÃmite honesto del trato. DoH esconde el tránsito del ISP, pero sigue confiando la respuesta a quien opere el resolver remoto: cambias de padrino, no eliminas el padrino. Y el SNI del apretón de manos TLS sigue filtrando los nombres que visitas. Cifrar el DNS mata el secuestro en el camino y la vigilancia pasiva de consultas, no la vigilancia total; para eso existen los VPN, y ahà empieza otra conversación.
Mi conclusión después de leer el caso: en cada servidor que administro, la consulta al resolver propio va a seguir, pero con verificación cruzada contra un upstream cifrado. Cinco minutos de prueba te ahoran horas de debugging fantasma.
Fuente del tema: So my ISP was hijacking my DNS, del blog de Karthikey Hegde (vÃa Lobsters).
Fuente de inspiración: So my ISP was hijacking my DNS
