El DNS no resuelve cuando el kill switch de la VPN bloquea el puerto 53
Un kill switch puede bloquear el DNS a propósito. Compare la resolución solo dentro del túnel con una excepción para un resolutor local y luego averigüe qué capa falló realmente.
Cuando el kill switch deja caer el túnel, se lleva consigo la ruta del DNS, y el resolutor que queda atrás rara vez es el que usted espera. Dos diseños afrontan ese momento de forma muy distinta: bloquear todos los paquetes DNS que no vayan dentro del túnel, odejar un resolutor en pie como excepción. Ambos son defendibles. Desde una pestaña del navegador los síntomas parecen casi idénticos, así que la primera tarea es averiguar qué diseño ha desplegado realmente.
Mantengo esa distinción delante porque la corrección es opuesta en cada caso. Un diseño necesita una excepción más amplia; el otro, una más estrecha. Adivinar le cuesta o la privacidad o una tarde.
Dos diseños de DNS para la misma caída
El diseño A trata el resolutor como un servicio más detrás del túnel. Las reglas del cortafuegos permiten UDP y TCP 53 solo en la interfaz del túnel, y la dirección que recibe el cliente es un resolutor dentro del túnel. Cuando el túnel cae, las consultas se detienen, y ese es el resultado previsto, no una avería.
El diseño B mantiene un resolutor accesible en la red local, normalmente el router en 192.168.1.1 o el stub del sistema operativo en 127.0.0.53, con el razonamiento de que la resolución de nombres no debería morir con el túnel. Resulta cómodo en una LAN doméstica donde el router resuelve para toda la casa. En el Wi-Fi de un hotel o un aeropuerto la misma excepción apunta al servidor de otra persona, y cada nombre que escribe queda al descubierto aunque su tráfico web siga bloqueado.
La frontera es quién posee el resolutor. Si confía en el local, una excepción es un agujero pequeño y honesto. Si no, el diseño solo-túnel es el único que se sostiene, y el precio es que un túnel caído se lleva todos los nombres.
Por qué la consulta del propio cliente VPN sigue funcionando
El cliente tiene que resolver el nombre de host de la puerta de enlace antes de que exista un túnel, así que un bloqueo estricto no debe cubrir la ruta de arranque del cliente. La mayoría de los clientes o bien cachean la dirección del extremo o bien incluyen una excepción de arranque documentada para ese único host. Si su conjunto de reglas bloquea esa consulta, el túnel no vuelve nunca y los registros muestran un cliente que no puede alcanzar su propio servidor, lo que es un defecto de política y no de DNS.
El DNS dividido es el otro lugar donde esto aparece. El cliente empuja una zona interna a un resolutor privado y deja todo lo demás al resolutor del sistema. Tras una caída, los nombres públicos pueden seguir resolviéndose mientras los internos agotan el tiempo, porque la zona privada ya no tiene ruta. Para el usuario eso es "la VPN rompió internet"; para el registro del resolutor es una consulta que nunca llegó.
Con systemd-resolved puede ver la división directamente.resolvectl statusenumera los servidores DNS por enlace y los dominios de enrutamiento, y tras caer el túnel el dominio interno sigue apuntando a un servidor en un enlace que ya no existe. El stub en 127.0.0.53 acepta todavía la consulta, luego espera a un servidor superior que no responderá, y por eso el fallo tarda segundos en vez de volver de inmediato.
El DNS cifrado no esquiva un filtro de paquetes
DNS sobre HTTPS y DNS sobre TLS viajan por 443 y 853, así que una regla que bloquea el puerto 53 no ha dicho nada sobre ellos. Bloquear "DNS" por puerto es una política sobre un puerto, no sobre la resolución de nombres. Si su kill switch bloquea todo el tráfico fuera del túnel, DoH queda cubierto por accidente. Si ha reservado un permiso para un portal cautivo o un resolutor público, no.
Los controles del lado del cliente son la palanca más barata. Firefox abandona su resolutor DoH cuando el nombre canariouse-application-dns.netno resuelve, y por eso las redes gestionadas publican ese dominio como NXDOMAIN; la política empresarial también puede fijarlo desactivado. Android Private DNS y el DNS seguro de Chrome tienen sus propios interruptores y sus propios valores por defecto. Desactivarlos es más fiable que perseguir direcciones de resolutores, porque la lista de direcciones cambia y su conjunto de reglas no.
Hay una versión de esto que no va de fugas en absoluto. Una aplicación con un resolutor fijado sigue necesitando una ruta de red para alcanzarlo. El cifrado cambia quién puede leer la consulta, no si el paquete puede salir de la máquina, así que un bloqueo de todo el dispositivo derrota el ajuste sin tocarlo.
Empareje el síntoma con la capa
La mayoría de los informes llegan como una frase, y esa frase normalmente ya nombra la capa. La tabla de abajo es lo que repaso antes de tocar una regla; el objetivo es decidir si la consulta se bloqueó, se dirigió mal o nunca se envió.
| Symptom | Likely layer | First check |
|---|---|---|
| Every name fails at once, instantly | Resolver answering with a refusal | Query the resolver by address, not by name |
| Lookups hang for seconds, then time out | Packets dropped with no response | Watch port 53 on the physical link |
| Public names resolve, internal ones do not | Split-DNS routing domain | Per-link DNS servers on the tunnel |
| Names resolve, the page still fails | Not DNS: routing or MTU | Connect to the IP directly |
| Only one application fails | Pinned resolver or cached answer | Check that app's DNS setting |
Las dos primeras filas son las que la gente diagnostica mal. Una caída silenciosa y un rechazo se parecen ambos a "el DNS está roto" en un navegador, pero solo uno de los dos significa que su kill switch está haciendo su trabajo. Un rechazo significa que algo respondió, así que el bloqueo no está donde usted cree.
Restaure la política del resolutor y luego demuéstrela
Arregle el diseño, no el síntoma. Para resolución solo por túnel, permita 53 en la interfaz del túnel, empuje el resolutor interno con la configuración del túnel y deje el enlace físico sin ningún permiso de DNS. Con wg-quick, la líneaDNS =es la que escribe el resolutor en la configuración de la interfaz, así que un túnel que la omite deja el resolutor antiguo en su sitio y cada consulta por la ruta equivocada.El manual de wg-quickdocumenta ese comportamiento por plataforma.
Después verifique en este orden. En Linux,resolvectl statusmuestra el enlace activo,dig +short example.comprueba un nombre público,dig @10.8.0.1 internal.example.comprueba el privado, ysudo tcpdump -ni any port 53muestra qué interfaz usan los paquetes mientras ejecuta ambos. En Windows,Get-DnsClientServerAddress -AddressFamily IPv4yResolve-DnsName example.comdan los mismos dos hechos: quién está configurado y quién responde.
Termine con la prueba negativa. Desconecte el túnel, confirme que un nombre público nuevo falla, confirme que el nombre privado falla, yconfirme que ningún paquete del puerto 53 salió del adaptador físico. Un bloqueo que solo aguanta para respuestas en caché no aguanta en absoluto.
Lista de comprobación antes de cerrar el tique:
- El resolutor usado durante la caída es el que la política pretende.
- La consulta del propio extremo del cliente sigue permitida, por caché o por excepción.
- DoH y DoT quedan cubiertos por el bloqueo o desactivados por política.
- Las zonas privadas fallan cerradas, no abiertas, una vez que el túnel desaparece.