DNS local para usuarios VPN: Evitar filtraciones de DNS y fallos de enrutamiento dividido

El modelo mental: qué significa realmente “DNS local para usuarios VPN”

“DNS local para usuarios VPN” es una frase que la gente usa para referirse a tres cosas diferentes. Si no aclaras cuál de ellas estás implementando, entregarás un sistema que funciona en tu laboratorio y falla en el vestíbulo de un hotel.

Significado n.º 1: “Usar un resolutor interno accesible a través de la VPN”

Este es el modelo corporativo clásico: el cliente VPN debe enviar consultas DNS a un resolutor dentro de tu red (o dentro de tu VPC en la nube), no al resolutor que la Wi‑Fi del usuario le entrega. Esto es la base para DNS de horizonte dividido (los nombres internos resuelven a IPs internas), zonas solo internas y registro consistente.

Significado n.º 2: “Ejecutar un resolutor en el cliente y reenviar inteligentemente”

Ejecutas un stub resolver local en el dispositivo (o confías en el stub del SO) y configuras reenvío condicional: dominios internos van a DNS interno por la VPN; todo lo demás usa el resolutor de la red local o un resolutor público elegido (o también por la VPN, según la política). A menudo es la forma más limpia de hacer que el túnel dividido se comporte sin enviar todo el DNS de internet por la red corporativa.

Significado n.º 3: “Proveer un servicio DNS cerca del usuario para reducir latencia”

Esto está impulsado por el rendimiento: despliega resolutores regionales, accesibles a través de la VPN, para que los trabajadores remotos no tengan que hacer hairpin hasta la sede por cada consulta. También reduce el radio de impacto cuando un nodo DNS muere, porque el “más cercano” cambia.

Las tres son válidas. Mezclarlas sin intención es cómo terminas con filtraciones parciales, orden de resolutores impredecible y caches que se pelean entre sí.

Verdad operativa: El DNS “funciona” hasta que no funciona, y entonces falla como una burbuja de jabón—silenciosa, aleatoria y siempre durante una demostración en vivo.

Hechos e historia interesantes que explican el lío actual

• El DNS es anterior a las VPN modernas. La especificación DNS (RFC 1034/1035) es de 1987, diseñada para una red más amable que las Wi‑Fi hostiles y los portales cautivos de hoy.
• “Horizonte dividido” es anterior a la nube. Las empresas hacían vistas internas vs externas de DNS mucho antes de que Kubernetes hiciera que todo pareciera nuevo otra vez.
• UDP fue una ventaja, luego una desventaja. DNS sobre UDP era perfecto para consultas pequeñas, pero también fácil de suplantar, bloquear o maltratar en redes inestables.
• EDNS0 cambió los tamaños de paquete. Respuestas DNS más grandes (piensa en DNSSEC, muchos registros) aumentaron los problemas de fragmentación—exactamente lo que se complica sobre MTU de VPN.
• DNSSEC mejoró la integridad, no la privacidad. Ayuda a prevenir manipulaciones pero no evita filtraciones DNS ni que observadores vean lo que consultas.
• DoH/DoT cambió quién “posee” la resolución de nombres. Las aplicaciones pueden omitir la configuración del resolutor del SO, lo que significa que el “establecer servidor DNS” de la VPN puede ser ignorado por el navegador.
• NRPT de Windows existe por una razón. Microsoft añadió Name Resolution Policy Table para controlar qué espacios de nombres usan qué resolutores—porque “solo establecer un servidor DNS” no era suficiente.
• systemd-resolved trajo el DNS dividido al mainstream de Linux. Es potente, pero también introdujo nuevos modos de fallo cuando los administradores asumen que /etc/resolv.conf cuenta toda la historia.
• El DNS corporativo suele ser la última frontera de on-call. Muchos equipos modernizan autenticación, despliegan proxies elegantes y aún ejecutan DNS como si fuera 2009 porque “siempre ha ido bien”.

Objetivos de diseño: elige qué optimizas

Antes de tocar configuraciones, decide qué significa “correcto” para tu organización. El DNS es política disfrazada de tubería.

Objetivo A: Evitar filtraciones de DNS (privacidad + cumplimiento)

Las filtraciones ocurren cuando consultas DNS para dominios internos (o cualquier dominio, según la política) van a un resolutor fuera de tu control. Arreglar esto puede requerir forzar DNS a la interfaz VPN, bloquear el puerto 53 fuera del túnel y lidiar con DoH.

Objetivo B: Hacer que el túnel dividido funcione de verdad (fiabilidad)

El túnel dividido suele significar: aplicaciones internas por VPN, internet directo. La parte DNS debe coincidir con eso. Si zonas internas se resuelven vía resolutores públicos, las apps internas fallan. Si zonas públicas se resuelven por resolutores internos sobre un túnel congestionado, la internet “se siente lenta”.

Objetivo C: Mantener la latencia y la carga razonables (rendimiento)

Centralizar DNS detrás de un solo extremo VPN es fácil, y también la forma de enseñar a los usuarios que “la VPN es lenta”. Resolutores regionales, cacheo y manejo correcto de TTL hacen que el DNS sea lo bastante rápido para que nadie lo note—que es el mayor cumplido que puedes recibir.

Objetivo D: Mantener las operaciones aburridas (facilidad de soporte)

Depurar DNS en endpoints remotos ya es doloroso. No lo empeores con ingeniosidad que no puedes observar. Prefiere diseños donde puedas responder: ¿qué resolutor usó el cliente, por qué interfaz salió, y qué respondió?

Parafraseando una idea de John Allspaw: la fiabilidad se construye desde la capacidad de responder a lo inesperado, no desde pretender que lo inesperado no ocurrirá.

Arquitecturas de referencia que funcionan en producción

1) DNS de túnel completo: forzar todo el DNS por la VPN hacia resolutores internos

Cuándo usar: cumplimiento estricto, entornos regulados o cuando no toleras ningún DNS fuera del túnel.

Cómo funciona: la VPN empuja servidores DNS internos; el cliente enruta consultas DNS por el túnel; el firewall bloquea DNS saliente en la interfaz local; opcionalmente intercepta/redirige hacia el resolutor interno.

Contrapartidas: más carga en tu VPN y DNS; mayor latencia para búsquedas públicas a menos que tu resolutor interno haga buena selección de upstreams; hay que manejar DoH por separado.

2) DNS dividido con reenvío condicional (recomendado por defecto)

Cuándo usar: la mayoría de organizaciones con túnel dividido y espacios de nombres internos.

Cómo funciona: dominios internos (p. ej., corp.example, svc.cluster.local, zonas privadas en la nube) van a resolutores internos por la VPN; todo lo demás usa el resolutor de la red local o un resolutor público elegido.

Contrapartidas: más complejidad de configuración entre SO; requiere control cuidadoso del orden de resolutores y reglas de enrutamiento por dominio; aún hay que considerar rutas de filtración.

3) Resolutor local en el cliente + upstream cifrado (DoT) sobre VPN

Cuándo usar: quieres comportamiento consistente y menos peculiaridades del SO, y puedes gestionar un agente.

Cómo funciona: ejecuta un stub de caché local (como unbound) en el cliente; reenvía zonas internas a DNS internos; reenvía lo público a endpoints DoT ya sea por VPN o directo. Esto puede domar las carreras entre resolutores y reducir consultas repetidas en enlaces inestables.

Contrapartidas: gestión del ciclo de vida del agente; una capa más que administrar; la depuración se traslada de las herramientas del SO a los logs de tu stub.

4) Resolutores anycast accesibles por VPN (para escala)

Cuándo usar: gran fuerza laboral remota en múltiples regiones; requisitos de baja latencia; ya gestionas bien el enrutamiento global.

Cómo funciona: anuncia la misma IP de resolutor en varias regiones accesibles vía VPN; BGP u overlay routing lleva al cliente a la instancia más cercana. Funciona mejor junto con health checks y failover rápido.

Contrapartidas: requiere madurez operativa; anycast + firewalls stateful puede complicarse; depurar “qué nodo respondió” necesita buena observabilidad.

Opinión: si no estás regulado para usar DNS de túnel completo, empieza con DNS dividido y reenvío condicional. Es el mejor equilibrio entre experiencia de usuario y control—si lo implementas honestamente y pruebas en SOs reales.

Comportamiento del cliente: Windows, macOS, Linux, móvil (y sus malas costumbres)

Windows: múltiples resolutores, sufijo de búsqueda y tablas de política

Windows puede mantener diferentes servidores DNS por interfaz y tiene reglas sobre qué interfaz gana. También tiene listas de sufijos de búsqueda que pueden generar consultas sorprendentes. Para DNS dividido, NRPT puede enrutar espacios de nombres específicos a resolutores específicos. Si gestionas VPN corporativa a escala, aprende NRPT. Es la diferencia entre “funciona para TI” y “funciona para todo el mundo”.

macOS: el orden de resolutores es real, y a veces es caprichoso

macOS usa una configuración dinámica de resolutores. Puedes tener múltiples resolutores activos con enrutamiento por dominio. La interfaz gráfica y el cliente VPN pueden afirmar una cosa mientras el resolutor subyacente hace otra. Siempre inspecciona el estado real del resolutor, no solo el panel de red.

Linux: /etc/resolv.conf miente en sistemas modernos

En muchas distribuciones, /etc/resolv.conf apunta a un stub local (como 127.0.0.53) manejado por systemd-resolved, NetworkManager u otra cosa. Depurar requiere consultar al gestor de resolutores, no solo leer el archivo.

Móvil: portales cautivos, funciones de privacidad “útiles” y DNS por app

Los teléfonos se mueven, cambian de red y tratan agresivamente de mantener conectividad. Algunas apps usan sus propios métodos DNS, y las plataformas modernas pueden preferir DNS cifrado si está configurado. Tu historia de “empujar DNS por la VPN” puede no cubrir la configuración DoH del navegador o un agente de seguridad que haga su propia resolución.

Broma #1: El DNS es como el cotilleo de oficina—si no controlas a dónde va, absolutamente acabará en el pasillo equivocado.

De dónde vienen las filtraciones de DNS y los fallos de enrutamiento dividido

Camino de filtración 1: servidor DNS configurado, pero falta ruta

La VPN empuja una IP de servidor DNS, pero el cliente no enruta esa IP por el túnel (común con túnel dividido). Resultado: el servidor DNS está “configurado” pero inalcanzable. El SO hace failover a otro resolutor—a menudo el de la red local—causando filtraciones y roturas.

Camino de filtración 2: orden de resolutores y fallback

Los clientes pueden intentar varios resolutores. Si el resolutor interno se agota (latencia, problemas de MTU, pérdida de paquetes), el SO usa el siguiente resolutor. Ese siguiente resolutor suele ser externo. Felicidades, acabas de construir una política de privacidad probabilística.

Camino de filtración 3: DNS a nivel de aplicación (DoH/DoT)

Si navegadores o agentes usan DoH directamente a un proveedor público, la configuración DNS de la VPN puede ser omitida. A veces eso es deseado. A menudo no lo es. Decide tu política y luego aplícala con gestión de endpoints y/o controles de red.

Fallo de enrutamiento dividido: nombres internos resuelven a IPs públicas (o NXDOMAIN)

Si las zonas internas no se enrutan a resolutores internos, los usuarios recibirán NXDOMAIN o, peor, resolverán nombres internos a registros públicos con el mismo nombre. El DNS de horizonte dividido existe porque ocurre reutilización de nombres. Ignorar ese hecho es cómo te abres tickets que no mereces.

Fallo de enrutamiento dividido: nombres internos resuelven bien, pero el tráfico va directo

Aun si el DNS es correcto, el registro A/AAAA resultante debe caer en un rango de IPs enrutado vía la VPN. Si tu túnel dividido enruta solo algunos prefijos, y los servicios internos viven en otros, la resolución de nombres tiene éxito pero la conectividad falla. Los usuarios lo llaman “DNS” de todos modos. A veces tienen razón, pero no por la razón que piensan.

Tareas prácticas: comandos, salidas y qué decides a partir de ellos

Estas son las comprobaciones que ejecuto más o menos en este orden cuando alguien dice “el DNS de la VPN está roto”. Cada tarea incluye el comando, cómo suele verse la salida, qué significa y la decisión siguiente.

Tarea 1: Identificar qué servidor DNS está usando realmente el sistema (Linux con systemd-resolved)

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
 resolv.conf mode: stub
Current DNS Server: 10.20.0.53
       DNS Servers: 10.20.0.53 1.1.1.1
DNS Domain: corp.example

Link 3 (wg0)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.20.0.53
       DNS Servers: 10.20.0.53
        DNS Domain: ~corp.example

Qué significa: El DNS está dividido: wg0 tiene ~corp.example y usa 10.20.0.53. También hay un fallback global (1.1.1.1).

Decisión: Si las consultas internas siguen filtrándose, verifica que las consultas internas se enruten a wg0 y que ~corp.example esté correctamente establecido. Si falta, corrige el enrutamiento por dominio.

Tarea 2: Revisar /etc/resolv.conf sin dejarte engañar por él

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Jan  2 10:11 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Qué significa: Estás usando un stub resolver. Leer el archivo no mostrará las elecciones de upstream reales.

Decisión: Usa resolvectl (o herramientas de NetworkManager) para la verdad. Si las aplicaciones evitan el stub, tienes otro problema.

Tarea 3: Confirmar que el servidor DNS interno es accesible vía la ruta de la VPN

cr0x@server:~$ ip route get 10.20.0.53
10.20.0.53 dev wg0 src 10.20.0.10 uid 1000
    cache

Qué significa: La ruta al resolutor interno va por wg0. Bien.

Decisión: Si enruta por wlan0 u otra interfaz local, corrige las rutas del túnel dividido (AllowedIPs, rutas empujadas o enrutamiento por políticas).

Tarea 4: Probar resolución interna explícitamente contra el resolutor interno

cr0x@server:~$ dig @10.20.0.53 git.corp.example +time=2 +tries=1

; <<>> DiG 9.18.24 <<>> @10.20.0.53 git.corp.example +time=2 +tries=1
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40211
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
git.corp.example. 60 IN A 10.30.4.21

;; Query time: 21 msec
;; SERVER: 10.20.0.53#53(10.20.0.53)

Qué significa: El servidor DNS responde rápido y devuelve una IP interna.

Decisión: Si esto funciona pero las apps fallan, el cliente puede no estar usando ese resolutor (problema de orden de resolutores) o el enrutamiento a 10.30.4.21 es incorrecto.

Tarea 5: Probar el mismo nombre usando la ruta por defecto del sistema (detectar filtraciones y mal enrutamiento)

cr0x@server:~$ dig git.corp.example +time=2 +tries=1

; <<>> DiG 9.18.24 <<>> git.corp.example +time=2 +tries=1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5851
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

Qué significa: La ruta por defecto del sistema no conoce la zona interna (probablemente usa DNS externo).

Decisión: Corrige el enrutamiento DNS dividido para que corp.example vaya al resolutor interno. En Linux eso es enrutamiento por link/por dominio; en Windows suele ser NRPT; en macOS son entradas por dominio del resolutor.

Tarea 6: Detectar si los paquetes DNS realmente atraviesan la interfaz VPN

cr0x@server:~$ sudo tcpdump -ni wg0 port 53 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
10:22:41.111112 IP 10.20.0.10.53321 > 10.20.0.53.53: 40211+ A? git.corp.example. (33)
10:22:41.132908 IP 10.20.0.53.53 > 10.20.0.10.53321: 40211 1/0/1 A 10.30.4.21 (49)

Qué significa: El DNS va por el túnel y las respuestas regresan. Esta es la línea base limpia.

Decisión: Si no ves nada en wg0 pero sí ves consultas en wlan0, eso es una filtración. Corrige el enrutamiento o la selección de resolutor.

Tarea 7: Capturar comportamiento de “resolutor de fallback” observando múltiples interfaces

cr0x@server:~$ sudo tcpdump -ni wlan0 port 53 -c 3
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:23:02.002201 IP 192.168.1.25.58732 > 192.168.1.1.53: 5851+ A? git.corp.example. (33)
10:23:02.004991 IP 192.168.1.1.53 > 192.168.1.25.58732: 5851 NXDomain 0/1/0 (102)

Qué significa: Tu dispositivo está filtrando consultas internas al resolutor de la red local.

Decisión: Detén el fallback implementando DNS dividido correctamente y/o bloqueando DNS fuera del túnel. Si la política lo permite, aplica “las zonas internas deben ir por VPN” a nivel de política del SO.

Tarea 8: Verificar problemas de MTU/fragmentación que parecen “timeouts DNS”

cr0x@server:~$ ping -M do -s 1472 10.20.0.53 -c 2
PING 10.20.0.53 (10.20.0.53) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420

--- 10.20.0.53 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1026ms

Qué significa: La MTU del camino es menor (1420). Respuestas UDP grandes pueden fragmentarse o perderse, causando fallos DNS intermitentes.

Decisión: Ajusta la MTU de la VPN, habilita fallback a TCP para fiabilidad o asegúrate de que las respuestas DNS se mantengan pequeñas cuando sea posible. Si usas respuestas pesadas por DNSSEC, ten especial cuidado.

Tarea 9: Verificar que el cliente no esté usando DoH de forma que evite tu plan (vista desde la red)

cr0x@server:~$ sudo tcpdump -ni wg0 'tcp port 443 and (host 1.1.1.1 or host 8.8.8.8)' -c 3
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
10:24:10.500000 IP 10.20.0.10.41220 > 1.1.1.1.443: Flags [S], seq 123456, win 64240, options [mss 1360,sackOK,TS val 1 ecr 0], length 0

Qué significa: Estás viendo tráfico HTTPS hacia un proveedor resolutor público. Eso puede ser tráfico web normal—o puede ser DoH.

Decisión: Si tu política prohíbe el bypass DoH, aplícalo vía gestión de endpoints y controles de egress; si la política lo permite, asegúrate de que los dominios internos no puedan filtrarse vía DoH (lo que a menudo significa reglas por aplicación o bloquear sufijos internos que salgan).

Tarea 10: Confirmar qué servidor DNS respondió una consulta (traza en dig)

cr0x@server:~$ dig git.corp.example +trace +time=2 +tries=1
; <<>> DiG 9.18.24 <<>> git.corp.example +trace +time=2 +tries=1
;; Received 525 bytes from 192.168.1.1#53(192.168.1.1) in 3 ms

Qué significa: La traza comenzó en tu resolutor local (192.168.1.1). Eso ya es una filtración para un nombre interno.

Decisión: Corrige la selección de resolutor y el enrutamiento por dominio. Traceroute es útil para probar “quién respondió” sin discutir con capturas de pantalla de la UI.

Tarea 11: Validar que las IPs de servicios internos estén enrutadas por la VPN (post-DNS)

cr0x@server:~$ ip route get 10.30.4.21
10.30.4.21 dev wg0 src 10.20.0.10 uid 1000
    cache

Qué significa: El tráfico al servicio interno irá por VPN. El DNS puede no ser realmente tu problema.

Decisión: Si esto se enruta fuera del túnel, corrige los prefijos de túnel dividido. El DNS está bien; el enrutamiento no.

Tarea 12: Comprobar si el resolutor interno puede alcanzar upstreams (lado resolutor)

cr0x@server:~$ dig @127.0.0.1 example.com +time=2 +tries=1

; <<>> DiG 9.18.24 <<>> @127.0.0.1 example.com +time=2 +tries=1
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 30001
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; Query time: 2000 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)

Qué significa: El resolutor local (en un servidor DNS) falla al resolver nombres públicos. Upstreams bloqueados, rotos o con timeout.

Decisión: Arregla el egress del resolutor, la configuración de upstream o reglas de firewall. Si no, los usuarios VPN culparán al “DNS de la VPN” aunque el problema sea la ruta upstream del resolutor.

Tarea 13: Revisar contadores de firewall por DNS bloqueado (sanidad del servidor)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iifname "wg0" udp dport 53 accept
    iifname "wg0" tcp dport 53 accept
    counter packets 1203 bytes 90211 drop
  }
}

Qué significa: El DNS desde la interfaz VPN está permitido; todo lo demás se descarta por defecto.

Decisión: Si los clientes VPN todavía no pueden resolver, no es porque el servidor DNS los bloquee (al menos no en la cadena input). Pasa a salud del servicio, enrutamiento o comprobaciones MTU.

Tarea 14: Comprobar rendimiento del resolutor y tasa de aciertos de caché (ejemplo Unbound)

cr0x@server:~$ sudo unbound-control stats_noreset | egrep 'total.num.queries|total.num.cachehits|total.num.cachemiss|avg'
total.num.queries=145233
total.num.cachehits=109887
total.num.cachemiss=35346
total.requestlist.avg=8.132

Qué significa: La ratio de aciertos de caché es decente; el promedio de la lista de peticiones sugiere algo de concurrencia pero no necesariamente sobrecarga.

Decisión: Si los aciertos de caché son bajos y la latencia alta, añade más caché cerca de los usuarios, ajusta prefetching o incrementa capacidad del resolutor. Si la tasa de misses sube durante incidentes, podrías estar experimentando inestabilidad upstream.

Broma #2: El DNS dividido es como la política de “trabajar desde casa”—todos están de acuerdo en principio y luego los casos límite se instalan gratis.

Guía de diagnóstico rápido

Este es el orden “deja de adivinar”. Ejecútalo como una lista de verificación, no como un debate.

Primero: confirma qué resolutor está usando el cliente

• En Linux: resolvectl status (no confíes solo en /etc/resolv.conf).
• En macOS: inspecciona la configuración del resolutor (quieres enrutamiento por dominio, no solo “servidores DNS” en la UI).
• En Windows: revisa DNS por interfaz más reglas NRPT si las usas.

Decisión: Si el cliente no está configurado para usar DNS interno para dominios internos, para. Arregla la configuración antes de perseguir “problemas de red”.

Segundo: confirma que la ruta al servidor DNS interno va por la VPN

• Ejecuta ip route get <dns_ip> (Linux) o herramientas equivalentes.
• Si enruta fuera del túnel, tienes un fallo en la política de túnel dividido.

Decisión: Arregla rutas (AllowedIPs, rutas empujadas, enrutamiento por política) antes de tocar servidores DNS.

Tercero: prueba resolución de nombre interno directamente contra DNS interno

• dig @internal-dns internalhost.corp.example
• Mide latencia, códigos de respuesta y IPs devueltas.

Decisión: Si consultas directas fallan, el resolutor está degradado o inalcanzable. Si funcionan, el orden de resolutores del cliente o el enrutamiento por dominio está mal.

Cuarto: haz sniffing para confirmar a dónde van los paquetes DNS

• tcpdump en la interfaz VPN y en la interfaz local para el puerto 53.
• Busca zonas internas filtrándose a resolutores locales.

Decisión: Si ves filtraciones, aplica DNS dividido o bloquea DNS fuera del túnel. Si ves timeouts, investiga MTU y pérdida de paquetes.

Quinto: maneja la realidad del “bypass DoH”

• Decide si permites DNS cifrado a nivel de app fuera de tu resolutor.
• Si no, haz cumplir la política mediante gestión de endpoints y controles de egress; si sí, documenta el comportamiento y su impacto en zonas internas.

Errores comunes (síntomas → causa raíz → solución)

1) “VPN conectada, sitios internos no se resuelven”

Síntoma: nombres internos devuelven NXDOMAIN o resuelven a IPs públicas.

Causa raíz: el cliente sigue usando DNS de la red local; no hay enrutamiento condicional para sufijos internos; faltan reglas NRPT/entradas de resolutor.

Solución: implementa DNS dividido: enruta corp.example al DNS interno vía VPN; verifica con dig y captura de paquetes que las consultas vayan por el túnel.

2) “Funciona por Ethernet, falla por Wi‑Fi/hotel”

Síntoma: timeouts intermitentes, especialmente para respuestas más grandes; a veces solo fallan ciertos registros.

Causa raíz: desajuste de MTU causando pérdida por fragmentación; truncamiento de respuestas UDP mal manejado.

Solución: ajusta la MTU de la VPN; asegura fallback a TCP en resolutores; considera limitar el tamaño EDNS si es necesario.

3) “Solo algunos usuarios filtran DNS”

Síntoma: filtraciones inconsistentes; usuarios con la misma configuración VPN se comportan diferente.

Causa raíz: diferencias de SO (systemd-resolved vs resolvconf legado), múltiples interfaces activas, comportamiento de fallback de resolutor.

Solución: estandariza la herramienta de gestión DNS del cliente; prueba en cada build de SO que soportas; configura explícitamente enrutamiento por dominio y prioridades de resolutor.

4) “La resolución interna funciona, pero las apps aún no se conectan”

Síntoma: DNS devuelve IPs internas correctas; conexiones TCP fallan.

Causa raíz: rutas del túnel dividido no incluyen los rangos IP del servicio; grupos de seguridad/firewalls bloquean; enrutamiento asimétrico.

Solución: arregla la publicidad de rutas y la política de seguridad; valida con ip route get y traceroutes sobre el túnel.

5) “El DNS público se siente lento cuando la VPN está activada”

Síntoma: demoras al navegar; mucho “esperando DNS” en las herramientas de desarrollo.

Causa raíz: forzaste todo el DNS a resolutores internos en una región; la latencia y la congestión se suman; los misses de caché amplifican el dolor.

Solución: usa DNS dividido para búsquedas públicas o despliega resolutores regionales accesibles vía VPN; asegura buenas prácticas de cacheo y selección de upstreams.

6) “Bloqueamos el puerto 53, pero las filtraciones siguen ocurriendo”

Síntoma: consultas a dominios internos siguen siendo visibles externamente.

Causa raíz: DoH/DoT como bypass; DNS embebido en apps; resolutores usando puertos no estándar.

Solución: maneja la política de DNS cifrado explícitamente: configuraciones de endpoint, proxy DNS o puntos DoH controlados. No supongas que el puerto 53 lo es todo.

7) “Todo se rompe después de habilitar validación DNSSEC”

Síntoma: SERVFAIL en muchos dominios; éxito intermitente.

Causa raíz: MTU del camino/fragmentación, middleboxes rotos o desincronización de tiempo que afecta cadenas de validación.

Solución: valida MTU, permite TCP/53, asegura sincronización horaria adecuada y considera un despliegue por fases. DNSSEC no es un interruptor; es un compromiso.

Tres microhistorias del mundo corporativo (anonimizadas)

Microhistoria 1: Un incidente causado por una suposición errónea

Una empresa SaaS mediana desplegó VPN de túnel dividido para reducir costes de ancho de banda. La VPN empujaba servidores DNS internos y el equipo asintió creyendo que eso significaba “el DNS está resuelto”. Pasó una prueba básica: conectarse desde la Wi‑Fi de casa, resolver Git interno, desplegar el cambio.

Luego llegó el lunes. Usuarios en espacios de coworking reportaron fallos en apps internas, pero solo a veces. El helpdesk escaló a “VPN inestable”. El equipo de red comprobó la salud del túnel: bien. Autenticación: bien. CPU en gateways VPN: bien. Mientras tanto, alguien notó que consultas internas aparecían en los registros de un proveedor DNS público—porque un subconjunto de clientes hacía fallback cuando el resolutor interno se agotaba.

La suposición errónea fue sutil: “Si se configura un servidor DNS, las consultas irán allí”. En realidad, si la ruta a ese resolutor no está garantizada por la VPN, los clientes lo intentan, fallan y luego usan silenciosamente el siguiente resolutor. El túnel dividido tenía rutas para subnets de aplicación, pero no para la subred del servidor DNS. Así que la IP del resolutor estaba configurada, pero inalcanzable desde muchas redes.

La solución fue aburrida: asegurar que las IPs de resolutor siempre tengan ruta por el túnel y aplicar enrutamiento condicional para dominios internos. También añadieron capturas de paquetes al runbook para probar si las consultas salían del túnel. El incidente terminó no con un parche heroico, sino con un cambio en la tabla de rutas y una decisión de política para dejar de depender del “fallback”.

Microhistoria 2: Una optimización que salió mal

Una gran empresa quería “DNS rápido en todas partes”, así que desplegaron resolutores internos regionales y se pusieron creativos con reglas de reenvío. Las búsquedas públicas se reenviaban a resolutores ISP locales (¡baja latencia!) mientras que búsquedas internas iban por VPN a servidores autoritativos internos. En el papel, era un split limpio.

En la práctica, creó un problema de coherencia de caché y una pesadilla de resolución de problemas. Algunos clientes tenían capas de caché propias; otros usaban un agente corporativo; otros usaban stubs del SO. Los TTLs diferían entre cadenas. Un cambio de registro para un servicio interno se propagó de forma desigual y una porción de usuarios seguía alcanzando IPs antiguas incluso después del movimiento.

Luego lo peor: en algunas regiones, los resolutores ISP hacían filtrado agresivo y a veces respondían de forma extraña a tipos de registro poco comunes. Eso no importó para “navegación normal” pero rompió algunos productos de seguridad y flujos de trabajo de desarrolladores que dependían de comportamiento DNS específico. De repente la “optimización DNS” se convirtió en “los desarrolladores no pueden construir” y el equipo de red fue arrastrado al debugging de peculiaridades de resolutores terceros.

La solución final fue dejar de externalizar la mitad pública del comportamiento DNS a resolutores ISP aleatorios. Mantuvieron resolutores internos regionales, pero reenviaron las consultas públicas a un conjunto upstream controlado y consistente (aún regional) con comportamiento predecible y observabilidad. El rendimiento siguió siendo bueno. La carga de pager bajó. La optimización sobrevivió, pero se eliminó la variable fuera de control.

Microhistoria 3: Una práctica aburrida pero correcta que salvó el día

Una fintech más pequeña ejecutaba dos resolutores recursivos internos por región, accesibles por VPN, y trataban el DNS como cualquier otra capa: monitorización, alertas, control de cambios y planificación de capacidad. Nada exótico. Solo disciplina.

Un día, un proveedor de nube tuvo un evento de red parcial que causó pérdida de paquetes intermitente entre el ingreso VPN y uno de los nodos resolutor. Los usuarios finales vieron “algunos nombres internos fallan”. Olía a problemas de aplicación, luego a problemas de VPN, luego a “quizás DNS”. Clásico whodunit.

La razón por la que no se hundieron fue: tenían métricas de latencia por resolutor y contadores de fallo de consulta, y registraban qué resolutor respondía cada consulta (al menos para los forwarders corporativos). El on-call pudo ver que los timeouts de un resolutor aumentaron mientras el otro estaba normal. Sacaron el nodo malo del servicio y vieron cómo las tasas de error colapsaban.

Sin magia. Solo resolutores con health checks, redundancia y observabilidad. El informe del incidente fue corto, que es la verdadera señal de madurez.

Listas de verificación / plan paso a paso

Paso 1: Decide tu política DNS (ponla por escrito)

• ¿Las consultas a dominios internos pueden salir del dispositivo fuera del túnel? (Usualmente: no.)
• ¿Las consultas a dominios públicos pueden usar DNS de la red local? (Depende: rendimiento vs cumplimiento.)
• ¿Permites DoH/DoT directamente desde clientes? Si sí, ¿para qué apps y qué endpoints?
• ¿Requieres registro de consultas DNS? Si sí, ¿dónde y por cuánto tiempo?

Paso 2: Define namespaces y límites de enrutamiento

• Lista zonas DNS internas: corp.example, internal.example, zonas privadas en la nube, clusters de Kubernetes.
• Lista IPs de resolutores y asegúrate de que sean alcanzables vía rutas VPN.
• Lista CIDRs de servicios internos que deben enrutar por VPN (no solo la subred DNS).

Paso 3: Implementa DNS dividido explícitamente

• Linux: configura dominios por enlace (p. ej., ~corp.example) y servidores DNS en el enlace VPN.
• Windows: usa NRPT para namespaces internos si tienes una flota gestionada.
• macOS: asegúrate de que existan entradas por dominio en el resolutor para zonas internas.

Paso 4: Detén las rutas de filtración que realmente tienes

• Bloquea UDP/TCP 53 fuera del túnel si la política requiere que no haya DNS externo.
• Maneja DoH/DoT con política y aplicación; no confíes en deseos.
• Evita que resolutores fallback capturen sufijos internos.

Paso 5: Haz el DNS resiliente y observable

• Al menos dos resolutores por región o por POP VPN.
• Health checks que reflejen resolución real, no solo “puerto 53 abierto”.
• Logs o métricas: tasa de consultas, SERVFAIL, tasa de NXDOMAIN, distribución de latencia, ratio de aciertos de caché.

Paso 6: Prueba desde redes hostiles

• Wi‑Fi de hotel, cafetería, hotspot móvil, portales cautivos.
• Escenarios IPv6 activado/desactivado (algunas filtraciones ocurren por rutas IPv6 que olvidaste).
• Clientes con múltiples interfaces activas (Wi‑Fi + Ethernet + adaptadores virtuales).

Paso 7: Publica un runbook que refleje la realidad

• Incluye los comandos de la sección “Tareas prácticas”.
• Incluye una definición de “filtración DNS” para tu organización (solo interna o todos los dominios).
• Incluye límites de escalado: equipo de endpoints vs equipo de red vs equipo de DNS.

Preguntas frecuentes

1) ¿Qué cuenta exactamente como una filtración DNS?

Una filtración DNS es cualquier consulta DNS que vaya a un resolutor fuera de tu límite de confianza previsto. Para muchas organizaciones, las filtraciones son específicamente espacios de nombres internos (como corp.example) que van a resolutores públicos o locales. En entornos más estrictos, cualquier DNS fuera del túnel es una filtración.

2) ¿Por qué el túnel dividido hace que el DNS sea más difícil?

Porque el DNS debe coincidir con la intención del tráfico. Si la VPN enruta solo ciertos subnets, pero el DNS está configurado para usar un resolutor interno, ese resolutor debe ser alcanzable por el túnel. Si no, los clientes hacen failover a otros resolutores, a menudo fuera de la VPN.

3) Si empujo servidores DNS a través de la VPN, ¿no es suficiente?

No. Debes asegurar la ruta a esos servidores DNS por la VPN y controlar las reglas de selección de resolutor para que las zonas internas no las conteste un resolutor fallback. Configurar no es lo mismo que hacer cumplir.

4) ¿Deberíamos ejecutar nuestros propios resolutores recursivos o simplemente reenviar a DNS público?

Si te importa comportamiento consistente, observabilidad y zonas internas, ejecuta tus propios resolutores recursivos (o usa un resolutor gestionado que controles) y reenvía upstreams de forma predecible. Reenviar a resolutores locales aleatorios es una apuesta de fiabilidad disfrazada de ahorro.

5) ¿Qué hay del DNS cifrado (DoH/DoT)?

DoH/DoT protege la privacidad del DNS en la red, pero puede omitir el enrutamiento DNS de tu VPN. Decide la política: permitirlo con guardrails, o bloquearlo/redirigirlo con enforcement en endpoints y red. Fingir que no existe es cómo las filtraciones sobreviven al “bloqueo de DNS”.

6) ¿Cómo manejamos el DNS interno cuando los usuarios están en redes IPv6?

Asegúrate de que tu VPN y plan DNS cubran IPv6 explícitamente: alcance del resolutor, rutas y respuestas de registros (AAAA). Si solo manejas IPv4, algunos clientes aún resolverán y conectarán por IPv6 fuera del túnel y perseguirás fantasmas.

7) ¿Por qué algunas búsquedas internas funcionan y otras hacen timeout?

Causas comunes: problemas de MTU que descartan respuestas grandes, pérdida de paquetes en el camino VPN, resolutores sobrecargados o comportamiento de fallback. Valida con tcpdump, pruebas MTU y dig directo al resolutor interno.

8) ¿Podemos “simplemente bloquear el puerto 53” para detener filtraciones?

Bloquear el 53 ayuda, pero no es suficiente. Las apps pueden usar DoH sobre 443, algunos entornos usan DNS en puertos no estándar y bloquear 53 sin proveer un resolutor on-tunnel funcional convierte “prevención de filtraciones” en “corte de internet”.

9) ¿Cuál es el enfoque más simple y seguro para una flota con SO mixtos?

Usa DNS dividido con reenvío condicional, más rutas garantizadas a resolutores internos. Estandariza la configuración del cliente vía MDM/GPO donde sea posible. Añade monitorización en resolutores. Luego prueba desde redes hostiles.

10) ¿Cómo demostramos que arreglamos la filtración?

Captura paquetes en el cliente: verifica que consultas de zonas internas aparezcan en la interfaz VPN y no en la interfaz local. También registra consultas en resolutores internos y corólalas. La prueba vence a las capturas de pantalla.

Siguientes pasos prácticos

1. Elige una política. Decide qué significa “filtración” para ti y si el DNS público debe ir por la VPN.
2. Haz no negociable la alcanzabilidad del resolutor. Asegura que las IPs del servidor DNS tengan ruta por la VPN incluso en modo túnel dividido.
3. Implementa DNS dividido deliberadamente. Enrutamiento condicional para namespaces internos, no solo “poner servidor DNS”.
4. Obsérvalo. Añade health checks de resolutor, métricas de latencia y suficiente logging para responder “qué resolutor respondió”.
5. Prueba en el mundo real. Hoteles, portales cautivos, redes IPv6 y dispositivos con múltiples interfaces—porque tus usuarios viven ahí.

Si haces estas cinco cosas, el DNS deja de ser un misterio semanal y se convierte en lo que debe haber sido siempre: infraestructura aburrida que hace su trabajo en silencio.