DNS con VPN sin complicaciones: cómo cerrar filtraciones, corregir la resolución y configurar la caché

Qué sucede realmente con el DNS al usar VPN: explicado sencillo y sin magia

Cambio en la ruta del tráfico al activar la VPN

Has pulsado el botón Conectar en tu cliente VPN favorito. Parece sencillo: todo el tráfico viaja por el túnel. Pero con el DNS no siempre es así. Por defecto, el sistema operativo decide a dónde enviar las consultas para resolver dominios basándose en la lista de resolutores, prioridad de interfaces y políticas de seguridad de las aplicaciones. La VPN añade una interfaz virtual con su propia ruta. Sin embargo, tu navegador o el servicio del sistema puede insistir en usar el DNS antiguo asignado por el proveedor. Ahí es donde surgen fugas y comportamientos extraños.

Imagina una autopista con un carril VIP de pago. Los vehículos grandes entraron ahí. Pero los pequeños, como las solicitudes DNS, a veces siguen recorriendo las rutas viejas. La razón está en la política del resolutor: algunos confían en el sistema, otros usan DoH integrado, y algunos no confían en el túnel. Pero la lógica es clara: si queremos privacidad y estabilidad, necesitamos una ruta única y predecible para el DNS dentro de la VPN.

En 2026, la mayoría de los clientes WireGuard, OpenVPN y agentes corporativos SASE ya establecen configuraciones DNS correctas y bloquean las «fugas» externas. Pero no existen milagros. Si hay un resolutor separado con DoH activo en el host, el navegador puede seguir comunicándose con su proveedor en la nube. Por eso las reglas deben estar coordinadas: quién manda, quién sigue y hacia dónde se envían los paquetes UDP al puerto 53, TCP 853 para DoT y tráfico HTTPS para DoH.

Por qué el DNS es un tráfico especial (y generalmente problemático)

El DNS trabaja rápido, silencioso y frecuentemente. Cada página implica decenas de peticiones. Cualquier fallo o discrepancia se nota al instante: la página no carga, el contenido cambia, la geolocalización varía inesperadamente. Sumemos el caché en diferentes niveles (navegador, SO, cliente VPN, resolutor local, proveedor) y obtenemos una compleja escalera de tiempos de espera y registros desactualizados. Con VPN activada, además luchamos por la privacidad: no queremos que el proveedor vea qué dominios consultamos. Y la filtración de DNS hace exactamente eso: filtra, muchas veces sin que te des cuenta.

Además, el DNS no es solo el puerto 53. Las variantes cifradas DoH y DoT ya son estándar de facto. Los navegadores adoran DoH. Los resolutores del sistema en Windows y Linux cada vez cifran más por defecto. iOS y Android incluyen DNS Privado. ¿Maravilloso? Sí. Pero en el contexto de VPN surge la pregunta: ¿quién está al mando, el túnel o la aplicación? Sin una arquitectura clara, es fácil caer en un laberinto de políticas contradictorias donde unas reglas anulan otras, y en la configuración final conviven tres resolutores diferentes.

Síntomas: cómo identificar que los problemas de DNS son causados por la VPN

Carga lenta, tiempos de espera extraños, a veces carga, a veces no

Todos hemos pasado por eso. La página abre pero las imágenes no cargan. O al contrario: la página principal es rapidísima, pero el carrito se queda colgado. Activas la VPN y va mejor. Al cabo de unos minutos, peor. Clásico paradoja DNS. ¿Por qué ocurre? Posiblemente, algunos dominios se resuelven con el resolutor del sistema y otros con el DNS del túnel. El caché del navegador hace que la situación sea variable. A veces ayuda pulsar Ctrl+F5, otras no. ¿Molesto? Claro que sí.

Un marcador claro es el error DNS_PROBE_FINISHED_NXDOMAIN o SERVFAIL en diagnóstico. O retrasos repetidos de 1-2 segundos antes de cargar un dominio, sobre todo en el primer acceso. Si el túnel cambia el MTU, los paquetes DNS grandes con EDNS pueden fragmentarse y perderse. Así, una consulta pequeña funciona y otra falla. Otro indicador son sitios con distribución geográfica. Si responden con contenido incorrecto, probablemente parte de las consultas no se resuelve donde crees.

No ignores los problemas parciales. Si todo falla a la vez, se nota. Pero peor es cuando falla a ratos. Es como si el volante tuviera juego: el coche se mantiene, te acostumbras, y de repente te sales de la carretera. El DNS con VPN funciona igual.

Contenido y geolocalización «bailan»: los servicios piensan que estás en otro país

Activás VPN saliendo, por ejemplo, en Países Bajos, pero el servicio de vídeo muestra la biblioteca para Rusia, Turquía o incluso una mezcla. ¿Cómo puede ser? Filtraciones de DNS. El sitio determina la geo no solo por la IP, sino por dónde se resuelve el nombre CDN. Si la petición va al DNS del proveedor fuera del túnel, el CDN entrega las direcciones más cercanas a ese proveedor. El tráfico va por la ruta larga, el contenido es «incorrecto» y la velocidad varía.

Una forma simple de comprobarlo: desde la línea de comandos pregunta con dig o nslookup el encabezado de la sección Servidor. Si muestra la dirección del proveedor y no la del resolutor VPN o del servidor DoH/DoT elegido, tienes una fuga. Puede pasar al revés: parece que todo se cifra, pero el navegador usa su DoH con DDR (Discovery of Designated Resolvers). Entonces la consulta va al «proveedor correcto» vía HTTPS, pero salta el túnel VPN y la geo queda con una mezcla extraña.

En 2026, los esquemas híbridos son cada vez más comunes: las aplicaciones eligen DNS cifrado e incluso lo pasan a QUIC. Es cómodo, pero genera nuevos escenarios de fugas para VPN. Por eso es clave gestionar prioridades: quién está al mando en cadena y en qué nivel aseguramos cifrado y enrutamiento.

Filtración DNS: cómo detectarla y bloquearla sin chamanismo

Detectando fugas: comandos manuales, utilidades y dominios de control

Empecemos por lo simple. Activa la VPN y ejecuta nslookup example.com o dig example.com. Observa qué servidor aparece en la línea Server o sección SERVER. ¿Es tu resolutor objetivo? Por ejemplo, 10.14.0.1 para DNS corporativo detrás del túnel o un público tipo 1.1.1.1/9.9.9.9/8.8.8.8, pero a través del túnel. Si ves la dirección del proveedor, hay fuga. Si ves un DNS DoH desde el navegador que va directo a internet sin pasar por VPN, también es fuga, aunque cifrada.

Prueba con distintos dominios: comunes, con subdominios, largos (para activar EDNS y respuestas grandes). Compara respuestas con y sin VPN. Si hay diferencias significativas, probablemente algunas peticiones no van por donde deberían. Puedes usar direcciones de prueba como resolver-test o zonas internas inexistentes que indican qué resolutor actúa (muchos proveedores VPN ofrecen estos dominios internos, consulta la documentación de tu servicio o servidor).

Un truco útil: activa el registro en el resolutor local (por ejemplo, systemd-resolved o dnsmasq) y mira qué dominios pasan por él. Si el registro está vacío pero se resuelven consultas, significa que se están yendo por fuera. En Windows te sirve pktmon o trazas en PowerShell; en Linux, tcpdump con filtro udp puerto 53 o 853/443 para DoT/DoH.

Cómo bloquear fugas: políticas del cliente, reglas del SO y configuraciones de apps

El núcleo del combate es una política unificada. Para OpenVPN en Windows, activa las opciones block-outside-dns y register-dns en el cliente. En el servidor usa push «dhcp-option DNS X.X.X.X». Para WireGuard, especifica DNS = 10.14.0.1 (o la dirección necesaria) en el perfil cliente y asegúrate que AllowedIPs cubren tráfico hacia ese resolutor. Si usas split tunneling, incluye el resolutor en la lista de redes que pasan por el túnel. Y sí, revisa IPv6: las fugas suelen venir por ahí cuando IPv4 está bien cerrado.

Luego están las aplicaciones. Un navegador con DoH activado puede ignorar el resolutor del sistema. En ese caso, asigna un resolutor DoH accesible vía VPN (como DoH corporativo al puerto 443 dentro del túnel) o desactiva DoH integrado si tu modelo de privacidad depende del túnel. A nivel SO, en Windows usa DoH del sistema vinculado a la dirección del resolutor y activa DNS cifrado solo para ese servidor accesible por VPN. En Linux con systemd-resolved, pon DNS y Domains para la interfaz wg0 o tun0, activa DNSSEC y limita registros fallback si hace falta.

No olvides bloquear el UDP exterior en puerto 53 mientras trabaja la VPN. Es una medida brusca, pero efectiva. Que ni una consulta no autorizada pueda salir. Igual con DoT y DoH, si quieres que todo pase por el resolutor interno. Configuración fina, pero sin sorpresas.

Errores de resolución: cuando los dominios no resuelven o lo hacen intermitentemente

Causas locales: caché, MTU, firewall, prioridad de interfaces

Las fallas más comunes son locales. La caché almacena un registro A o AAAA antiguo, pero la realidad cambió. Terminas viendo NXDOMAIN mientras otro equipo abre la página bien. La solución es simple: limpia caché del navegador y caché DNS del sistema. En Windows: ipconfig /flushdns; en macOS: dscacheutil -flushcache y killall mDNSResponder; en Linux con systemd: resolvectl flush-caches. Si usas un resolutor local (dnsmasq, Unbound), reinícialo. No te dé pereza: tomarás dos minutos que a menudo ahorran horas de frustración.

MTU y fragmentación también complican. En túneles VPN el MTU suele ser menor que en la red física. Respuestas DNS grandes con EDNS (por ejemplo, con DNSSEC) pueden no pasar sin fragmentación y perderse en un router que corta fragmentos. Ves tiempos de espera o SERVFAIL. Prueba reducir MTU del túnel (por ejemplo, a 1280-1380 para WireGuard) o desactivar ajuste EDNS temporalmente para diagnóstico. Parece básico pero funciona, tanto en redes caseras como sucursales.

La prioridad de interfaces define qué resolutor DNS se usa primero. Si la métrica de la interfaz VPN virtual no es la más alta, el sistema puede seguir usando la interfaz Wi-Fi con el DNS antiguo. Revisa lista de adaptadores, métricas y órdenes. En Windows, en opciones avanzadas o PowerShell; en Linux, con tabla de enrutamiento y ajustes resolved. ¿Firewall? A veces reglas locales bloquean UDP 53 para interfaces nuevas. Entra y revisa explícitamente.

Causas de red y protocolo: DoH, DoT, IPv6, DNSSEC y EDNS

La parte de protocolo es más delicada. Si forzas DoT a un resolutor externo, pero el túnel VPN bloquea TCP 853 o requiere proxy interno, las peticiones no pasan. DoH similar: HTTPS a resolutor en la nube puede saltar el túnel si la app no hereda rutas. En 2026 muchos clientes ya asocian DoH al interfaz VPN correctamente, pero no todos. Compruébalo en la práctica: activa solo el túnel, desactiva salida externa y confirma que DoH sigue respondiendo.

IPv6 es otro tema aparte. Piensas en IPv4, pero el sistema silenciosamente resuelve y conecta por v6. Si la VPN no enruta IPv6 o no da dirección v6 del resolutor, partes de las consultas fallan. Hay dos opciones: o desactivar IPv6 temporalmente para diagnosticar, o configurar IPv6 completo en túnel, incluidos resolutor y prefijos. Considera DNSSEC: con fragmentos mal gestionados en túnel y MTU inadecuado, la validación falla. Con EDNS a veces hay que reducir bufsize o usar mecanismos antifragmentación para que las respuestas lleguen sin pérdidas.

También existe ECH: cifrado ClientHello en TLS que oculta SNI. No afecta directamente el DNS, pero junto con DoH y políticas de intercepción puede cambiar la ruta de solicitudes HTTPS del resolutor. Conclusión: revisa todo camino — desde resolutor sistema hasta interfaz túnel. Así habrá menos sorpresas.

Caché DNS: dónde está la trampa y cómo controlarla

Dónde vive la caché: navegador, SO, resolutor local, cliente VPN

La caché es multinivel. El navegador guarda registros aparte. El SO mantiene su caché. Un resolutor local (dnsmasq, Unbound, systemd-resolved) añade otra capa. Y el cliente VPN a veces cachea respuestas, especialmente agentes corporativos Zero Trust. Resulta que limpias una caché y la respuesta «incorrecta» sigue en otra. Divertido y frustrante a la vez. Por eso conviene un enfoque sistemático: limpiar en orden y verificar el tiempo TTL.

Atento al TTL. Si el resolutor entrega un TTL enorme, un registro obsoleto puede vivir horas. En 2026 aparecen políticas con caché agresivo para ahorrar tráfico, sobre todo en móviles. En esos casos es útil un resolutor local que permita temporalmente ignorar TTL para dominios problemáticos (por ejemplo, reduciéndolo durante la depuración). Esto ayuda en migraciones de CDN.

Otro punto: DNS dividido. Algunos dominios internos se resuelven hacia un lado, otros externos hacia afuera. La caché local debe conocer sufijos y no mezclar respuestas. Si no, una IP externa de ayer puede reemplazar el servicio interno. Ajusta bien search domains y rutas en tu perfil VPN.

Cómo limpiar caché correctamente sin romper todo lo demás

Un proceso rápido. Primero el navegador: limpia caché DNS en configuración o reinícialo si es más rápido. Luego el sistema. Windows: ipconfig /flushdns, a veces netsh winsock reset para pilas saturadas. macOS: dscacheutil -flushcache y killall mDNSResponder (sí, clásico revitalizado). Linux: resolvectl flush-caches o reinicia resolutor local. Si tienes dnsmasq, haz service dnsmasq restart. Si usas AdGuard Home o Pi-hole, limpia caché desde su interfaz o comando.

Tras limpiar, repite pruebas con dig y nslookup para ver cambios en direcciones y velocidad. Y no olvides la caché en el cliente VPN: agentes corporativos a veces requieren reinicio manual vía consola integrada. Poco común, pero ocurre. Lo principal: no limpiar a lo loco. Un enfoque paso a paso ahorra tiempo: limpieza capa por capa, comprobación, registro de observaciones.

Arquitectura DNS correcta con VPN en 2026: de casa a oficina

Split DNS y Split Tunneling: cómo hacer que funcione sin romperse

Split Tunneling ahorra tráfico y reduce latencias. Pero en DNS se vuelve un campo minado sin reglas claras. Regla uno: sufijos de dominios internos deben resolverse solo por resolutor en el túnel. Configura en perfil VPN domains o search domains y route-only para subredes necesarias. Regla dos: para dominios públicos, decide dónde resolver — dentro o fuera del túnel — y fíjalo. La opción simple: solo un resolutor sistemático siempre accesible vía túnel. Así hay menos fugas.

Para WireGuard: en configuración cliente indica DNS y añade AllowedIPs para la dirección del resolutor. Para OpenVPN: usa push «dhcp-option DOMAIN-SEARCH corp.local» y push «dhcp-option DNS 10.14.0.1». En Windows activa block-outside-dns para evitar que nadie altere las prioridades. En soluciones corporativas SASE y Zero Trust, asigna políticas por grupos y dispositivos, definiendo qué dominios resolver dónde. Añade monitoreo; sin eso, esquemas split se convierten en lotería.

Y piensa en fallback. Si el resolutor principal falla, el sistema suele cambiar silenciosamente a uno secundario. Esto genera fugas ocultas. Mejor rechazo explícito que ruta «modificada» silenciosa. En 2026 muchos clientes ya soportan modo «estricto», donde sin disponibilidad del DNS del túnel la consulta no sale.

Cifrado por defecto: DoH, DoT, ECH, ODoH y DDR sin sorpresas

El cifrado DNS dejó de ser exótico hace tiempo. DoH (DNS over HTTPS) y DoT (DNS over TLS) están en los paneles estándar de Windows, Android y navegadores modernos. DDR (Discovery of Designated Resolvers) automatiza enlazar resolutor cifrado con el conocido sin cifrar. Suena genial, pero en VPN hay que controlar: ¿qué decide el resolutor, la app o la política del túnel?

La configuración ideal: fuente única de verdad. Si usas un resolutor corporativo con DoH en dirección interna, especifícalo en clientes y bloquea DoH/DoT externos mientras funcione la VPN. Si eres usuario privado, elige resolutor confiable (ej. 1.1.1.1, 9.9.9.9, 8.8.8.8 o NextDNS) y asegúrate que la ruta pasa por el túnel. Para ECH solo importa que el tráfico HTTPS del resolutor sea estable. ODoH (Oblivious DoH) ofrece privacidad al separar petición y transporte, pero añade latencia — úsalo según necesidad.

Resultado simple: cifra el DNS, pero no multipliques fuentes de verdad. Un resolutor, una política, rutas claras. Así la VPN será aliada, no enemiga. Por cierto, en 2026 los clientes estándar ya registran bien estado DoH/DoT. Revisa si tienes activados esos logs; a menudo ahí está la pista de por qué «ayer funcionaba».

Configuraciones paso a paso: Windows, macOS, Linux, iOS y Android

Windows 11/10: resolutor sistema, OpenVPN y WireGuard

Empezamos por Windows. Paso 1: revisa lista de interfaces y métricas. Prioriza adaptador VPN. Paso 2: si usas OpenVPN, agrega en perfil client options block-outside-dns y register-dns. En servidor configura push «dhcp-option DNS 10.14.0.1» y si hace falta push «redirect-gateway def1». Paso 3: para WireGuard en configuración cliente añade DNS = 10.14.0.1 y verifica que AllowedIPs tengan ruta al resolutor. Si usas split, incluye dominios necesarios en búsqueda.

Paso 4: activa DNS cifrado del sistema para resolutor seleccionado solo si es accesible vía túnel. Configura plantilla DoH y revisa estado en ajustes de red. Paso 5: limpia caché — ipconfig /flushdns. Si había problemas con Winsock, netsh winsock reset y reinicio. Paso 6: prueba filtraciones con nslookup example.com y confirma que el servidor es del túnel. Si hace falta, bloquea UDP 53 saliente en firewall mientras la VPN está activa.

Extra: en Windows 11 comprueba que el navegador no tenga DoH propio que esquive al sistema. Si la política es «todo por túnel», sincroniza ajustes navegador con resolutor sistema o indica en navegador un DoH accesible vía VPN. No olvides IPv6: configúralo por túnel o desactívalo para diagnóstico.

macOS e iOS: perfiles, Resolver y mDNSResponder

En macOS mucho depende de perfiles y orden de servicios. Paso 1: asegúrate que el servicio VPN tiene mayor prioridad en lista de redes. Paso 2: si usas perfiles corporativos, añade servidores DNS y sufijos de dominio dentro del perfil VPN. Paso 3: ante problemas de resolución, limpia caché con dscacheutil -flushcache y reinicia mDNSResponder con killall mDNSResponder. Funciona rápido y fiable.

En iOS clave son perfiles y política de la app. Muchos clientes asignan resolutor interno al conectar y bloquean salidas DNS. Revisa opción para evitar saltos de DNS fuera del túnel en app VPN. Si usas Private Relay junto con VPN, pueden chocar rutas y registros DoH en navegador. Para diagnóstico, desactiva Private Relay y deja solo VPN y DNS sistema.

En todos casos verifica resolución de dominios de control y compara con lo esperado. En macOS utilízate scutil --dns para ver qué resolutor y para qué dominios se usa. Si tienes DNS dividido, configura Domains para la interfaz VPN para evitar fugas de zonas internas.

Linux y Android: systemd-resolved, dnsmasq y DNS Privado

En Linux 2026, systemd-resolved es a menudo el «director» DNS. Paso 1: vincula interfaz de túnel (wg0/tun0) con resolutor necesario: pon DNS y Domains para esa interfaz. Paso 2: revisa resolvectl status y confirma prioridades y orden de búsqueda. Paso 3: si tienes dnsmasq o Unbound, configura forwarding y split DNS para que zonas internas no intenten resolver afuera. Paso 4: revisa rutas IPv6 y MTU; si es necesario baja MTU en túnel.

En Android abre ajustes Red e Internet y activa DNS Privado con resolutor elegido si tu política exige cifrado en dispositivo. Pero un detalle importante: ese tráfico también debe pasar por VPN. Si la app VPN no intercepta tráfico DoH/DoT, tendrás fugas parciales. Muchos clientes ya ofrecen modo interceptar DNS. Actívalo, revisa y prueba con varios dominios.

Tanto Linux como Android cachéan mucho. No olvides usar resolvectl flush-caches en Linux y reiniciar la app en Android al cambiar perfiles. En casos complejos ayuda un resolutor local en el router (por ejemplo, dnsmasq en OpenWrt) para pasar todo por el túnel. Esta estructura suele ser más estable y predecible.

Depuración y monitoreo: herramientas y escenarios que realmente ayudan

dig, nslookup, resolvectl, pktmon, tcpdump: qué, dónde y cuándo

No hay botón mágico, pero sí preguntas adecuadas. ¿Quién responde a DNS? ¿A dónde van los paquetes? ¿Se ven tiempos de espera? En Windows comienza con nslookup y pktmon. Con pktmon start --etw -p puedes capturar una traza básica y luego ver si paquetes salen por interfaz inesperada. En Linux, tcpdump -i wg0 udp port 53 muestra si ves tráfico DNS dentro del túnel. Si silencio y resolución funciona, alguien resuelve fuera o por DoH.

dig es útil por sus opciones. Prueba dig +tcp para revisar escenarios DoT y respuestas grandes. Mira secciones SERVER y AUTHORITY. Compara respuestas con distintos MTU. En systemd-resolved resolvectl query dominio indica qué servidor respondió y tiempo. En macOS scutil --dns visualiza orden de resolutores y dominios. No olvides firewall: a veces corta UDP 53 o TCP 853 para interfaz túnel sin avisar.

Para apps con DoH, activa logs detallados. Navegadores y agentes corporativos en 2026 permiten por fin ver a qué resolutor va el DoH incorporado, por qué interfaz y con qué errores. Es oro para depuración: detectas diferencias en rutas o problemas en resolutor.

Logs, métricas y alertas: casa y oficina sin sorpresas

En casa bastan métricas simples: tiempo para primera resolución, porcentaje NXDOMAIN/SERVFAIL, tamaño caché, TTL. Puede hacerlo tu resolutor local o router. Haz un panel sencillo: si errores suben al activar VPN, actúa rápido. En oficina añade comprobaciones sintéticas: un robot cada 60 segundos resuelve lista de dominios clave con y sin VPN. Cualquier diferencia es señal.

No dudes en activar alertas por MTU y fragmentación si el equipamiento lo permite. Revisa semestralmente: quién es resolutor principal, dónde forwarding, estado políticas DoH/DoT, posibles fallback. Pequeñas correcciones trimestrales mantienen mejor estabilidad que un gran «arreglo mayor» cada tres años. Y una obviedad final: documenta todo. Cuando al año preguntes por qué MTU es 1280 y no 1420, un changelog bien hecho te salva del caos.

Casos prácticos: situaciones reales y soluciones efectivas

Caso 1: fuga DoH desde navegador con VPN corporativa

Contexto: empleado reporta que algunos servicios lo ven «como en casa» y otros «como en oficina». VPN conectada, acceso a sistemas internos. Diagnóstico: tcpdump en túnel no muestra DNS, pero resolución ocurre. Logs navegador indican DoH hacia resolutor en nube. Está cifrado pero evade el túnel. Solución: en política VPN activaron captura DoH y asignaron DoH interno accesible por túnel en puerto 443. Navegador desactivó auto-DDR temporalmente. Resultado: geo estable y sin fugas.

Conclusión: cifrado sin enrutamiento no garantiza privacidad. Lo importante es por dónde va el tráfico, no solo cómo se cifra.

Caso 2: resolución inestable por MTU y EDNS

Contexto: sitios abren pero a veces fallan con SERVFAIL, especialmente con DNSSEC. Reintentos funcionan. Con VPN peor, sin VPN mejor. Diagnóstico: respuestas grandes se fragmentan y pierden. MTU en túnel 1420, en ruta hay equipo que corta fragmentos. Solución: bajaron MTU a 1280 en túnel, limitaron bufsize EDNS en resolutor local. Resultado: más estabilidad, sin tiempos de espera.

Conclusión: EDNS es genial, hasta que la red es poco amigable. Adáptate.

Caso 3: DNS dividido y cachés «atorados»

Contexto: dominio interno a veces se resuelve a IP externa, servicio inaccesible. Tras 10 minutos se arregla solo. Diagnóstico: resolutor local cachea respuesta externa porque pasó sufijo interno en configuración split. Navegador también lo cachea encima. Solución: configuraron Domains en interfaz túnel, añadieron regla estricta para corp.local, limpiaron cachés en conjunto — navegador, SO, resolutor. Resultado: sin más repeticiones.

Conclusión: DNS dividido exige precisión. Un sufijo mal y horas de depuración perdidas.

Checklist diario: breve y al grano

Acciones mínimas, máximo impacto

- Comprueba quién resuelve: nslookup o dig, mira SERVER. - Asegura que resolutor VPN está en ruta y priorizado. - Limpia cachés por capas: navegador, SO, resolutor local. - Bloquea UDP 53 externo y, si hace falta, DoH/DoT externos. - Alinea política de cifrado: un resolutor, una verdad. - Prueba IPv6 por separado: configúralo o apágalo temporalmente. - Revisa MTU, EDNS y DNSSEC en respuestas grandes.

Este listado es simple pero efectivo. La constancia te ahorra estrés y gana clientes.

Qué hacer si «ya hiciste todo y sigue el problema»

Divide y vencerás. 1) ¿El dominio resuelve desde túnel y resolutor local al indicarlo manualmente? 2) ¿La respuesta llega a tiempo esperado? 3) ¿Mejora al desactivar DoH integrado en app? 4) ¿Cambia si bajas MTU a 1280? 5) ¿Qué muestra tcpdump en interfaz túnel? Si en cada paso hay sí/no, identificarás la raíz rápido.

No temas simplificar temporalmente a un esquema básico y fiable: un túnel, un resolutor, toda ruta por el túnel, sin split ni DoH externo. Si así es estable, ve agregando capas hasta encontrar el punto problemático.

FAQ: lo esencial en breve

Respuestas rápidas

¿Por qué con VPN los sitios a veces cargan más lento la primera vez?

Porque la consulta DNS fresca puede ir por ruta nueva y el caché aún no existe. Además, si el navegador usa DoH propio, establece conexión TLS aparte con el resolutor. Todo eso añade 100-300 ms extra. Al calentar caché y sesión, la demora casi desaparece. Si persiste la lentitud, revisa MTU y tiempos de espera inusuales en respuestas grandes.

¿Qué tan malo es una fuga DNS si el tráfico está cifrado por VPN?

La fuga DNS revela qué dominios visitas. Aunque el contenido esté cifrado, el hecho de la consulta es visible para el proveedor o terceros si se sale fuera del túnel. Además, la geolocalización puede fallar y las rutas extenderse. Resultado: menos privacidad, más problemas con acceso y velocidad.

¿Siempre hay que activar DoH o DoT junto con VPN?

No es obligatorio, pero recomendable si el resolutor cifrado está accesible vía túnel y su política te conviene. La clave es una fuente única de verdad. Si activas DoH en navegador y la VPN dirige el DNS oficial distinto, habrá conflicto. Elige un modelo y fija rutas para evitar discrepancias.

Casos complejos

Con VPN solo desaparecen algunos dominios con DNSSEC. ¿Qué hacer?

Revisa MTU y fragmentación. Respuestas grandes DNSSEC a menudo no llegan si el túnel corta fragmentos. Baja MTU a 1280-1380, ajusta bufsize EDNS en resolutor local y vuelve a probar. Si mejora, has dado con la causa.

¿Se puede combinar split tunneling y DoH cifrado del sistema sin fugas?

Sí, si ruteas el tráfico DoH estrictamente por el túnel y bloqueas vías de escape. Configura en sistema un resolutor DoH accesible solo por la IP dentro del VPN, y bloquea DoH/DoT externamente mientras la VPN esté activa. Así los dominios públicos se cifran y pasan por camino predecible, y los internos viajan por split DNS a resolutor corporativo.

¿Conviene desactivar IPv6 para simplificar?

Temporalmente sí, como medida diagnóstica si sospechas fugas o rutas inestables. Permanente, no recomendable. En 2026 más servicios y resolutores usan v6. Mejor configura IPv6 en túnel correctamente que vivir con soluciones parcheadas. Pero para chequeos rápidos, apagar IPv6 acelera hallazgo de problemas.