Levantas el túnel. El intercambio de claves es limpio. Puedes hacer ping a una IP del otro lado. Luego intentas un nombre de host y todo se desmorona: los navegadores giran, las instalaciones de paquetes fallan y tu agente de monitorización empieza a chillar sobre “falla temporal en la resolución de nombres”.
Este es el clásico truco de WireGuard: la VPN está bien, tus paquetes están bien y el DNS tranquilamente se está yendo a algún otro lado. Las fallas de DNS rara vez son “un problema de DNS”. Por lo general son un problema de enrutamiento, política o integración del resolvedor disfrazado de DNS.
Guía rápida de diagnóstico
Si no haces otra cosa, haz esto. Es el camino más rápido desde “el DNS está roto” hasta “aquí está el componente exacto que me miente”.
1) Demuestra que el túnel funciona sin DNS
- Haz ping a una IP conocida a través del túnel (un router del lado VPN, la IP del servidor DNS o un VIP de servicio).
- Si la conectividad IP falla, detente. Esto ya no es un artículo sobre DNS; es enrutamiento/firewall/AllowedIPs.
2) Identifica qué resolvedor estás usando realmente
- En Linux: comprueba si estás en
systemd-resolved, NetworkManager o en el simple/etc/resolv.conf. - En Windows: comprueba si el adaptador de WireGuard tiene servidores DNS y si NRPT está en juego.
3) Observa los paquetes DNS
- Ejecuta una captura de paquetes en la interfaz de WireGuard y en la interfaz física.
- Decisión: si las consultas DNS salen por la interfaz equivocada, tienes un problema de enrutamiento/política; si salen correctamente pero no reciben respuesta, tienes un problema de firewall/ACL/NAT o un problema en el servidor.
4) Confirma que el servidor DNS del lado VPN es accesible y responde
- Consulta el servidor DNS por IP explícitamente (evita el comportamiento del resolvedor local).
- Decisión: si la consulta directa funciona pero la resolución normal no, la integración del resolvedor del SO está mal.
5) Verifica expectativas de split DNS frente a la realidad
- ¿Esperas que solo
corp.exampleresuelva vía VPN, mientras que el DNS público permanece local? - Si la respuesta es sí, necesitas enrutamiento por dominio (systemd-resolved/NetworkManager en Linux, NRPT en Windows). WireGuard por sí mismo no hace política por dominio.
Una regla seca: no cambies cinco cosas a la vez. El DNS es un mentiroso; necesitas experimentos controlados.
Modelo mental funcional: dónde falla el DNS con WireGuard
WireGuard es intencionalmente pequeño y simple (para bien). Encripta paquetes entre pares. Crea una interfaz. Tiene el concepto de “qué rangos IP deben ir por este túnel” (AllowedIPs). Eso es todo.
El DNS, mientras tanto, vive en un mundo desordenado y específico del sistema operativo:
- Las aplicaciones llaman a una biblioteca de resolvedor.
- La biblioteca del resolvedor consulta la configuración (que puede ser un archivo, un daemon, un gestor de red o los tres discutiendo).
- Las consultas se envían a los servidores DNS configurados por UDP/TCP 53 (o a veces DoT/DoH si tu sistema es elegante o maldito).
- Esos paquetes siguen tu tabla de enrutamiento y reglas de política como cualquier otro tráfico.
Así que “DNS de WireGuard no funciona” usualmente significa una de estas cosas:
- Tu sistema nunca cambió los servidores DNS cuando el túnel se levantó.
- Cambió, pero los paquetes DNS se enrutan fuera del túnel de todos modos.
- Entran al túnel, pero el servidor es inalcanzable desde esa IP de origen o está bloqueado.
- Túnel dividido más DNS corporativo: necesitas enrutamiento por dominio, pero configuraste un servidor DNS global único.
- Tu daemon resolvedor local cachea basura o se niega a enviar consultas al servidor DNS de la VPN por “DNSSEC”, “privacidad” o “yo sé mejor”.
La línea DNS= de WireGuard en wg-quick no es magia. Es un gancho de conveniencia que intenta integrarse con tu SO. Cuando falla, falla silenciosamente, como un adulto que deja de responder a una invitación.
Datos interesantes y contexto histórico (para que dejes de discutir con tu portátil)
- El DNS precede a las VPN modernas por décadas. DNS se estandarizó a principios de los años 80; la mayoría de los diseños de VPN llegaron mucho después, así que “integración DNS” está añadida, no es fundamental.
- WireGuard evita intencionalmente empujar opciones tipo DHCP. Las VPN empresariales tradicionales a menudo empujan ajustes de DNS; WireGuard no tiene un canal de control incorporado para eso.
resolv.confnunca fue pensado para la complejidad actual. Comenzó como un archivo simple; los sistemas modernos lo reemplazaron con daemons porque los portátiles se mueven y las interfaces aparecen y desaparecen.- systemd-resolved introdujo enrutamiento DNS por enlace. Eso es lo que hace que el split DNS sea sensato en Linux—cuando está configurado correctamente.
- Windows lleva tiempo con políticas DNS por dominio. NRPT (Name Resolution Policy Table) existe en gran parte porque las empresas exigieron “estos dominios van a estos servidores DNS”.
- DNS puede usar UDP o TCP. La mayoría olvida que TCP 53 existe hasta que los fragmentos UDP se pierden y de repente “solo fallan las búsquedas grandes”.
- EDNS0 hizo al DNS “más grande” y más frágil. Las respuestas más grandes significan fragmentación y problemas de PMTU aparecen como “fallos aleatorios de DNS”.
- El DNS corporativo suele bloquear la recursión desde subredes “desconocidas”. Si tu túnel te asigna un nuevo rango y la ACL del DNS no se actualiza, parecerá que el DNS está caído.
Una cita, porque encaja mejor con el trabajo operativo que cualquier póster motivacional:
“La esperanza no es una estrategia.” — atribuido a Vince Lombardi
Modos de fallo comunes: qué significa realmente “DNS no funciona”
Modo A: el DNS nunca cambia después de levantar el túnel
Síntomas típicos: puedes resolver dominios públicos pero no internos; o sigues resolviendo nombres internos a direcciones públicas (o nada).
Por qué ocurre: wg-quick no aplicó los ajustes de DNS porque tu distribución usa un gestor de resolvedor con el que wg-quick no puede hablar (o lo intentó y falló). O el sistema sobrescribió el DNS inmediatamente mediante NetworkManager/DHCP.
Modo B: el DNS cambia, pero las consultas salen por la interfaz equivocada
Síntomas típicos: el sistema muestra el servidor DNS de la VPN configurado, pero la captura de paquetes muestra consultas saliendo por la interfaz Wi‑Fi.
Por qué ocurre: tu ruta hacia la IP del servidor DNS apunta al gateway físico, no al túnel; o el enrutamiento por política envía UDP/53 fuera de la tabla por defecto.
Modo C: las consultas entran al túnel, el servidor no responde
Síntomas típicos: tcpdump muestra paquetes DNS salientes en wg0, pero no hay respuestas.
Por qué ocurre: reglas de firewall, falta de NAT en el servidor VPN, ACL del servidor DNS que no permite tu subred del túnel, o IP de origen equivocada por enrutamiento por política.
Modo D: expectativas de túnel dividido sin DNS dividido
Síntomas típicos: todo se vuelve lento o falla cuando configuras el DNS de la VPN como global; fallan los inicios de sesión en SaaS; lo interno funciona pero lo externo parece encantado.
Por qué ocurre: apuntaste todo el DNS a un resolvedor corporativo que bloquea o filtra dominios externos, o solo es accesible por el túnel y estás haciendo split-tunneling del tráfico.
Modo E: MTU/fragmentación causa fallos “aleatorios” de DNS
Síntomas típicos: consultas pequeñas funcionan, las grandes fallan; zonas internas con muchos registros fallan; DNSSEC causa dolor intermitente.
Por qué ocurre: fragmentación UDP o agujeros de PMTU en la ruta del túnel; WireGuard añade overhead; tu MTU es demasiado optimista.
Broma #1: el DNS es como el chisme de oficina—rápido, poco fiable y siempre toma la ruta más dramática posible.
Tareas prácticas (con comandos, salidas y decisiones)
Estos son chequeos reales que puedes ejecutar en producción y en portátiles. Cada tarea incluye: comando, salida representativa, qué significa y qué decides después. Ejecútalas en orden de sospecha, no por vanidad.
Task 1 (Linux): Verify WireGuard interface state and peer handshake
cr0x@server:~$ sudo wg show
interface: wg0
public key: O3bY...redacted...
private key: (hidden)
listening port: 51820
peer: q7m2...redacted...
endpoint: 203.0.113.10:51820
allowed ips: 10.50.0.0/24, 10.60.0.0/16
latest handshake: 36 seconds ago
transfer: 28.31 MiB received, 51.22 MiB sent
persistent keepalive: every 25 seconds
Qué significa: El handshake está reciente; el tráfico fluye. Los problemas de DNS ahora probablemente son resolvedor/enrutamiento, no cripto.
Decisión: Si el handshake es “never”, arregla conectividad/llaves/endpoint antes de tocar DNS.
Task 2 (Linux): Confirm you can reach the VPN DNS server by IP
cr0x@server:~$ ping -c 2 10.50.0.53
PING 10.50.0.53 (10.50.0.53) 56(84) bytes of data.
64 bytes from 10.50.0.53: icmp_seq=1 ttl=63 time=22.1 ms
64 bytes from 10.50.0.53: icmp_seq=2 ttl=63 time=21.7 ms
--- 10.50.0.53 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 21.741/21.913/22.086/0.172 ms
Qué significa: Existe ruta L3 al servidor DNS. Si el DNS aún falla, sospecha filtrado UDP/53, configuración del resolvedor o política de split DNS.
Decisión: Si el ping falla, revisa enrutamiento/AllowedIPs/firewall primero.
Task 3 (Linux): Query the DNS server directly (bypass local resolver)
cr0x@server:~$ dig @10.50.0.53 internal.service.corp A +time=2 +tries=1
; <<>> DiG 9.18.24 <<>> @10.50.0.53 internal.service.corp A +time=2 +tries=1
; (1 server found)
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22141
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
internal.service.corp. 60 IN A 10.60.12.34
;; Query time: 28 msec
;; SERVER: 10.50.0.53#53(10.50.0.53) (UDP)
;; WHEN: Sat Dec 27 10:12:11 UTC 2025
;; MSG SIZE rcvd: 74
Qué significa: El servidor DNS de la VPN funciona. Si la resolución normal falla, tu SO no lo está usando (o el enrutamiento hacia él es incorrecto para las consultas normales).
Decisión: Sube por la pila: configuración del gestor de resolvedor, DNS por enlace y comprobaciones de rutas/política.
Task 4 (Linux): See what resolver your system is using
cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Nov 12 09:01 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
Qué significa: Estás en el resolvedor stub de systemd-resolved. Tus servidores DNS reales se gestionan en otro lugar.
Decisión: Usa resolvectl para inspeccionar DNS por interfaz; no “arregles” el stub editando el archivo.
Task 5 (Linux): Inspect per-link DNS with systemd-resolved
cr0x@server:~$ resolvectl status
Global
Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 2 (eth0)
Current Scopes: DNS
Protocols: +DefaultRoute
Current DNS Server: 192.168.1.1
DNS Servers: 192.168.1.1
Link 7 (wg0)
Current Scopes: DNS
Protocols: -DefaultRoute
DNS Servers: 10.50.0.53
DNS Domain: ~corp
Qué significa: El split DNS está configurado: ~corp va a 10.50.0.53. Todo lo demás va por eth0.
Decisión: Si wg0 no tiene servidor DNS o no tiene dominio enrutado, corrige tu PostUp de wg-quick o el perfil de NetworkManager.
Task 6 (Linux): Verify routing to the DNS server IP uses wg0
cr0x@server:~$ ip route get 10.50.0.53
10.50.0.53 dev wg0 src 10.50.0.2 uid 1000
cache
Qué significa: El kernel enrutará tráfico al servidor DNS a través de la interfaz del túnel.
Decisión: Si muestra dev eth0, tienes una fuga de rutas: añade la IP del servidor DNS a AllowedIPs y/o arregla el enrutamiento por política.
Task 7 (Linux): Confirm which DNS server your libc is asking (quick smoke test)
cr0x@server:~$ getent hosts internal.service.corp
10.60.12.34 internal.service.corp
Qué significa: La ruta de resolvedor a nivel de sistema puede resolver el nombre. Esto es más cercano a “lo que harán las aplicaciones” que dig en muchos entornos.
Decisión: Si getent falla pero dig @10.50.0.53 funciona, la integración del resolvedor del SO está equivocada.
Task 8 (Linux): Capture DNS traffic on wg0 and on the physical interface
cr0x@server:~$ sudo tcpdump -ni wg0 udp 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:13:02.115693 IP 10.50.0.2.53244 > 10.50.0.53.53: 41249+ A? internal.service.corp. (39)
10:13:02.141220 IP 10.50.0.53.53 > 10.50.0.2.53244: 41249 1/0/0 A 10.60.12.34 (55)
Qué significa: Las consultas y respuestas DNS atraviesan wg0. El enrutamiento es correcto y el servidor responde.
Decisión: Si ves consultas en eth0 en su lugar, arregla rutas; si ves consultas en wg0 pero no respuestas, revisa firewall/ACL/NAT en el extremo remoto.
Task 9 (Linux): Check if wg-quick installed special routing rules (policy routing)
cr0x@server:~$ ip rule show
0: from all lookup local
32764: from all lookup main
32765: from all lookup default
Qué significa: No hay reglas de enrutamiento por política adicionales. Eso está bien para configuraciones simples “enrutar por destino”, pero el split tunneling a veces necesita más.
Decisión: Si intentas hacer enrutamiento dividido avanzado (como “solo DNS por VPN”), considera reglas explícitas o DNS por enlace vía systemd-resolved.
Task 10 (Linux): Look for MTU issues that can break larger DNS replies
cr0x@server:~$ ip link show dev wg0
7: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/none
Qué significa: MTU es 1420, un valor común y relativamente seguro. Si estás en PPPoE, LTE o nubes raras, puede que necesites menos.
Decisión: Si fallan las respuestas DNS grandes, prueba con MTU más pequeño (por ejemplo, 1380) y vuelve a comprobar.
Task 11 (Windows): Verify adapter DNS settings via PowerShell
cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -AutoSize"
InterfaceAlias ServerAddresses
-------------- ---------------
Wi-Fi {192.168.1.1}
WireGuard Tunnel {10.50.0.53}
Qué significa: El adaptador de WireGuard tiene el servidor DNS configurado. Eso es necesario, no suficiente.
Decisión: Si el adaptador WireGuard no tiene servidor DNS, corrige el perfil de WireGuard en Windows (o usa NRPT para split DNS).
Task 12 (Windows): See which DNS server Windows actually used for a query
cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName internal.service.corp -Type A -DnsOnly | Format-List"
Name : internal.service.corp
Type : A
TTL : 60
Section : Answer
IPAddress : 10.60.12.34
Server : 10.50.0.53
Qué significa: Windows consultó el servidor DNS esperado.
Decisión: Si Server muestra tu router Wi‑Fi o un DNS público, tienes problemas de métricas de interfaz/NRPT/sufijos.
Task 13 (Windows): Check interface metrics that influence DNS selection
cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object -First 6 | Format-Table -AutoSize"
ifIndex InterfaceAlias AddressFamily NlMtu(Bytes) InterfaceMetric Dhcp
------- -------------- ------------- ------------ --------------- ----
25 WireGuard Tunnel IPv4 1420 5 Disabled
12 Wi-Fi IPv4 1500 35 Enabled
Qué significa: La métrica más baja tiende a ganar. Aquí, la interfaz WireGuard es preferida, que suele ser lo que quieres para DNS de túnel completo.
Decisión: Si la métrica de WireGuard es mayor y esperas que se use el DNS de la VPN, bájala—o usa NRPT para que el enrutamiento por dominio no dependa de métricas.
Task 14 (Windows): Inspect NRPT rules (split DNS sanity)
cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientNrptRule | Select-Object Namespace,NameServers,DirectAccessDnsServers | Format-Table -AutoSize"
Namespace NameServers
--------- ----------
.corp {10.50.0.53}
Qué significa: Las consultas para *.corp se dirigen al servidor DNS de la VPN independientemente del comportamiento DNS por defecto.
Decisión: Si necesitas split DNS en Windows, NRPT es el enfoque adulto. Configúralo intencionalmente y pruébalo con Resolve-DnsName.
Configuración correcta de DNS en Linux
La configuración DNS en Linux no es un único sistema. Es un ecosistema de sugerencias corteses y daemons en disputa. Tu objetivo es elegir una autoridad y hacerla determinista.
Comprobación de realidad en Linux: elige tu camino de resolvedor
En la práctica perteneces a uno de estos campos:
- systemd-resolved (común en Ubuntu, variantes Debian, Fedora, etc.). Mejor opción para split DNS cuando se usa correctamente.
- NetworkManager gestionando DNS (a menudo se integra con resolved; a veces no).
- Openresolv/resolvconf escribiendo en
/etc/resolv.conf. Todavía común en servidores y contenedores minimalistas. - Static /etc/resolv.conf. Genial hasta que te mueves de red; entonces se vuelve una escena del crimen.
Qué hace realmente wg-quick con DNS=
wg-quick es un script de shell. Cuando pones DNS=10.50.0.53 en la configuración, intenta llamar a herramientas como resolvconf o interactuar con resolved vía resolvectl dependiendo de la distro. Si esas herramientas no están presentes, el DNS puede simplemente no cambiar.
Opinión: no confíes en una integración “quizá”. Para portátiles, intégrate con el gestor de red o resolved explícitamente. Para servidores, prefiere una configuración de resolvedor determinista que sobreviva reinicios y reinicios de servicios.
Configuraciones correctas (elige una)
Configuración 1: systemd-resolved split DNS (recomendado para dominios corporativos)
Esto es lo que quieres si tu requisito es: los dominios internos resuelven vía DNS de la VPN; todo lo demás resuelve por la red local (o un resolvedor público).
WireGuard por sí solo no puede hacer “AllowedIPs basados en dominio”. Pero resolved puede hacer selección de servidor DNS por dominio. Los combinas: enruta la IP del servidor DNS dentro del túnel y enseñas a resolved qué dominio va a ese servidor.
Ejemplo de configuración de WireGuard:
cr0x@server:~$ sudo sed -n '1,120p' /etc/wireguard/wg0.conf
[Interface]
Address = 10.50.0.2/24
PrivateKey = (hidden)
ListenPort = 51820
PostUp = resolvectl dns %i 10.50.0.53; resolvectl domain %i ~corp
PostDown = resolvectl revert %i
[Peer]
PublicKey = (redacted)
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.50.0.0/24, 10.60.0.0/16, 10.50.0.53/32
PersistentKeepalive = 25
Qué importa aquí:
AllowedIPsincluye las redes internas que realmente necesitas y la IP del servidor DNS (10.50.0.53/32) para que la ruta de la consulta sea inequívoca.resolvectl dns %iestablece DNS por enlace en la interfazwg0.resolvectl domain %i ~corplo hace “solo por enrutamiento” para ese dominio, no una ruta por defecto global.revertlimpia al bajar la interfaz. Quieres limpieza. Tu yo futuro la querrá aún más.
Prueba: después de levantar la interfaz, resolvectl status debería mostrar wg0 con DNS Domain: ~corp. Luego verifica el tráfico con tcpdump.
Configuración 2: systemd-resolved DNS por túnel completo (simple, a veces correcto)
Si quieres: “cuando la VPN está arriba, todas las consultas DNS van al DNS de la VPN”, entonces puedes configurar wg0 como ruta por defecto para DNS no usando un dominio routing-only. Aún puedes mantener túnel dividido para tráfico, pero cuidado: si tu servidor DNS solo es accesible vía VPN y tu DNS es global, acabas de convertir al DNS en una dependencia crítica para todo.
En términos de resolved: establece el servidor DNS en wg0 y permite que sea ruta DNS por defecto (o establece DNS global). El enfoque más limpio varía con la integración de la distro, pero un patrón fiable sigue siendo PostUp/Down con resolvectl, solo que sin el dominio ~corp. Puedes configurar la ruta para el dominio “.” pero eso puede ser demasiado agresivo.
Opinión: el DNS por túnel completo en portátiles suele crear fallos raros con SaaS cuando los resolvedores corporativos filtran. Usa split DNS cuando puedas.
Configuración 3: resolvconf/openresolv (común en servidores pequeños)
Si tu sistema no usa resolved, wg-quick con DNS= puede funcionar si resolvconf existe. Si no existe, verás que el DNS nunca cambia y te preguntarás por qué pagas la electricidad.
Instala y verifica herramientas:
cr0x@server:~$ command -v resolvconf || echo "resolvconf not found"
resolvconf not found
Decisión: Si quieres depender del DNS de wg-quick, instala resolvconf/openresolv. Si quieres comportamiento determinista, gestiona /etc/resolv.conf tú mismo o migra a resolved.
Ejemplo de configuración wg-quick usando DNS=:
cr0x@server:~$ sudo sed -n '1,80p' /etc/wireguard/wg0.conf
[Interface]
Address = 10.50.0.2/24
PrivateKey = (hidden)
DNS = 10.50.0.53
[Peer]
PublicKey = (redacted)
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.50.0.0/24, 10.60.0.0/16, 10.50.0.53/32
PersistentKeepalive = 25
Pecados comunes en Linux que causan “DNS no funciona”
- Confusión con el stub de resolv.conf: editar
/etc/resolv.confcuando es un enlace simbólico al stub no hará lo que crees. - NetworkManager te pelea: puede sobrescribir DNS por conexión. Decide si NM gobierna DNS; si sí, configúralo ahí.
- Resolvedores cache locales:
unboundodnsmasqpueden estar corriendo y reenviando al lugar equivocado. - DNS de la VPN solo accesible por VPN: si la ruta al servidor DNS no está en
AllowedIPs, el sistema intentará alcanzarlo localmente y fallará. - Reglas de salida del firewall: el firewall local puede bloquear UDP/53 en wg0 porque alguien pensó que eso era “endurecimiento”.
Configuración correcta de DNS en Windows
Windows es al mismo tiempo mejor y peor aquí. Mejor porque tiene controles de política de primera clase (NRPT). Peor porque “te ayudará” con métricas de interfaz, listas de sufijos DNS y comportamiento de cacheo que parece gaslighting.
Qué cambia realmente el cliente de WireGuard en Windows
La aplicación de WireGuard para Windows crea un adaptador virtual. Cuando estableces DNS en el perfil del túnel, configura los servidores DNS de ese adaptador. Si Windows usa ese DNS para una consulta depende de:
- Qué interfaz se elige para la resolución de nombres (métricas y orden de enlace).
- Si estás usando split DNS vía NRPT.
- Listas de sufijos de búsqueda y qué nombres se consideran “en dominio”.
- Si la consulta la realiza una app usando las API DNS del sistema (la mayoría lo hace) o una que trae su propio resolvedor (algunas lo hacen, y esas son una alegría especial).
Dos patrones sensatos en Windows
Patrón 1: DNS por túnel completo (simple)
Si quieres “todo el DNS va al DNS de la VPN”, haz esto:
- Configura el/los servidor(es) DNS del adaptador WireGuard en el perfil.
- Asegúrate de que la métrica del adaptador WireGuard sea baja para que sea preferido.
- Asegúrate de que la IP del servidor DNS esté enrutada por el túnel (AllowedIPs la incluye).
Esto tiene menos piezas en movimiento. También es lo más probable que moleste a los usuarios si el DNS corporativo bloquea búsquedas externas o devuelve respuestas “amigables”.
Patrón 2: Split DNS con NRPT (recomendado para dominios corporativos)
Si quieres “solo zonas corporativas usan el DNS de la VPN”, usa NRPT. NRPT puede apuntar a namespaces (dominios) y forzar resolvers específicos para esos nombres. Elimina la dependencia de métricas de interfaz y reduce el comportamiento aleatorio cuando Wi‑Fi se reconecta.
Crea una regla NRPT (ejemplo):
cr0x@server:~$ powershell -NoProfile -Command "Add-DnsClientNrptRule -Namespace '.corp' -NameServers '10.50.0.53'"
Verifícala:
cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientNrptRule | Where-Object Namespace -eq '.corp' | Format-List"
Namespace : .corp
NameServers : {10.50.0.53}
Prueba la resolución y confirma qué servidor respondió:
cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName internal.service.corp -Type A -DnsOnly | Select-Object Name,IPAddress,Server | Format-Table -AutoSize"
Name IPAddress Server
---- --------- ------
internal.service.corp 10.60.12.34 10.50.0.53
Decisión: Si esto funciona de forma fiable, mantenlo. Si los usuarios necesitan múltiples namespaces internos, añádelos explícitamente. No intentes ser listo con comodines; perderás.
Modos de fallo específicos de Windows
- Guerras de métricas de interfaz: Windows puede decidir que Wi‑Fi es “mejor” y usar su DNS para todo. Baja la métrica de WireGuard o usa NRPT.
- Resolución de nombres multi-homed: Windows puede intentar múltiples interfaces; los resultados pueden ser inconsistentes cuando un DNS devuelve NXDOMAIN y otro devuelve respuesta.
- Desajuste de listas de sufijos: Los usuarios escriben
internaly esperaninternal.corp. Sin el sufijo correcto no obtienen nada (o peor, resultados públicos). - Apps que ignoran DNS del sistema: Algunos navegadores y agentes usan DoH o su propio resolvedor. La configuración de DNS de la VPN no importará hasta que deshabilites o gestiones ese comportamiento.
Broma #2: Resolver problemas DNS en Windows es una gran jugada de carrera porque garantiza seguridad laboral—principalmente para quien herede tu máquina después del reinicio.
Errores comunes: síntomas → causa raíz → solución
Estos son los que veo una y otra vez. Hacen perder horas porque “parecen” DNS mientras en realidad son selección de resolvedor o enrutamiento.
1) “El handshake está arriba, pero los nombres internos no resuelven”
Síntoma: wg show se ve bien. ping 10.60.12.34 funciona. getent hosts internal.service.corp falla.
Causa raíz: El SO no está usando el servidor DNS de la VPN; la integración DNS de wg-quick no se aplicó.
Solución: En Linux, configura systemd-resolved vía los ganchos resolvectl dns/domain o configura NetworkManager. En Windows, establece DNS del adaptador o usa NRPT.
2) “El servidor DNS está configurado a 10.50.0.53, pero caduca”
Síntoma: El resolvedor apunta al DNS de la VPN, pero dig muestra timeouts.
Causa raíz: La ruta a la IP del servidor DNS no es vía wg0; falta AllowedIPs con la dirección del servidor DNS o la subred interna que lo contiene.
Solución: Añade 10.50.0.53/32 (o la subred del DNS) a AllowedIPs. Verifica con ip route get 10.50.0.53.
3) “Solo fallan respuestas DNS grandes (o solo algunos dominios)”
Síntoma: Búsquedas pequeñas funcionan, zonas con DNSSEC fallan o consultas TXT mueren.
Causa raíz: Problemas de MTU/fragmentación/PMTU en la ruta del túnel.
Solución: Reduce MTU de WireGuard (p.ej., 1380) y vuelve a probar. Si hace falta, fuerza DNS por TCP para diagnóstico con herramientas e inspecciona capturas de paquetes buscando fragmentos.
4) “La navegación externa falla cuando la VPN está conectada, pero lo interno funciona”
Síntoma: VPN arriba; apps corporativas funcionan; sitios públicos se quedan o resuelven a direcciones raras.
Causa raíz: Configuraste el DNS corporativo globalmente y ese resolvedor filtra o secuestra búsquedas externas; o las consultas externas ahora atraviesan la VPN y están siendo limitadas.
Solución: Usa split DNS (dominios de enrutamiento en resolved para Linux; NRPT en Windows). Mantén el DNS público local o usa un resolvedor recursivo accesible por VPN diseñado para ello.
5) “Funciona en herramientas CLI pero no en navegadores”
Síntoma: dig y getent funcionan, pero el navegador no carga hostnames internos.
Causa raíz: El navegador usa DNS-over-HTTPS o su propio resolvedor; evita la selección de DNS del SO.
Solución: Desactiva DoH en entornos corporativos o configura políticas empresariales para que los dominios internos resuelvan vía DNS del sistema.
6) “Funcionó ayer, ahora no, y el reinicio lo ‘arregla’”
Síntoma: Resolución intermitente; el reinicio lo arregla.
Causa raíz: Desajuste de estado en el resolvedor cacheado (systemd-resolved, caché DNS de Windows) o rebotes de interfaz que causan selección equivocada de servidor DNS.
Solución: Vacía caches como diagnóstico; luego arregla la selección determinista de DNS (DNS por enlace, NRPT, métricas correctas). Deja de usar reinicio como solución.
Tres mini-historias corporativas desde las trincheras
Mini-historia 1: El incidente causado por una suposición equivocada
Implementaron WireGuard para reemplazar una VPN de acceso remoto antigua. El plan de migración era limpio: el túnel se levanta, los usuarios acceden a servicios internos, listo. El equipo incluso probó conectividad con pings y un par de curl a IPs. Todo parecía verde.
Llegó el lunes y los tickets se dispararon. “VPN conectada pero nada funciona.” El on-call revisó el servidor WireGuard. Los handshakes ocurrían. Los contadores de tráfico se movían. El túnel no estaba caído; estaba indiferente.
La suposición fue la asesina: alguien creyó que añadir DNS=10.50.0.53 al config del cliente significaba que el SO cambiaría resolvers de forma fiable. En algunos portátiles Linux, wg-quick no pudo hablar con la configuración del resolvedor local. En Windows, el adaptador tenía DNS configurado, pero la resolución prefería el DNS del Wi‑Fi porque la métrica de la interfaz cambió tras una actualización del driver.
Lo arreglaron haciendo la selección de DNS explícita: configuración per-link de systemd-resolved en Linux, reglas NRPT en Windows para namespaces internos. El postmortem no fue sobre WireGuard; fue sobre “probamos conectividad pero no probamos la resolución de nombres como lo hace una aplicación”. Esa es la lección real. Las apps no se conectan a IPs que pegas en Slack; se conectan a nombres.
Mini-historia 2: La optimización que se volvió en contra
Un equipo de seguridad quiso reducir las fugas de DNS. Objetivo razonable. Decidieron: “forzar todo el DNS por la VPN.” Apuntaron a todos los clientes a un resolvedor recursivo corporativo accesible solo dentro del túnel y consideraron el trabajo hecho.
El primer problema: latencia. El personal remoto en redes lejanas ahora envió cada consulta DNS por el túnel a un resolvedor que no estaba afinado para usuarios globales. La navegación se volvió lenta porque las páginas modernas desencadenan una pequeña estampida de búsquedas DNS. El segundo problema: fiabilidad. El resolvedor filtraba ocasionalmente, y cuando estaba lento, todo estaba lento.
Luego el verdadero contragolpe: algunos flujos de autenticación SaaS fallaron intermitentemente. No porque el SaaS estuviera caído, sino porque el comportamiento de filtro y caché del resolvedor corporativo no coincidía con el DNS público. Algunos CDNs devolvían respuestas distintas y las apps se comportaban diferente. El equipo había “optimizado” para evitar fugas y creó un punto único de fallo para toda la experiencia de navegación.
La solución fue más aburrida: split DNS para zonas internas, más reglas sensatas de egress para prevención de fugas (bloquear UDP/53 directo a Internet en dispositivos gestionados cuando proceda, mientras se permiten políticas DoH para público). El resolvedor corporativo quedó en el bucle solo para los dominios que realmente poseían. Los usuarios dejaron de quejarse y el equipo de seguridad consiguió el control sin convertir al DNS en cuello de botella.
Mini-historia 3: La práctica aburrida pero correcta que salvó el día
Otra organización hizo algo poco glamuroso: escribieron un “contrato DNS de VPN” de una página. Especificaba: namespaces internos, resolvers autorizados, comportamiento de recursión, tamaños de respuesta esperados y exactamente cómo clientes Linux y Windows deberían enrutar esas consultas al conectarse. Nada de suposiciones. Nada de “debería”.
Cuando desplegaron WireGuard, no solo enviaron configs. Enviaron pruebas. Un pequeño script validaba: túnel arriba, ruta al servidor DNS vía wg, dig @dns directo funciona, el resolvedor del sistema usa el servidor correcto para dominios corp y la captura de paquetes no muestra fugas para dominios internos.
Meses después, un cambio de red introdujo una nueva zona interna con respuestas DNS más grandes. Algunos usuarios empezaron a ver fallos intermitentes de resolución solo para esa zona. Porque tenían contrato y suite de pruebas, el on-call lo reprodujo rápido y vio fragmentación. El MTU era aceptable para la mayoría del tráfico pero marginal para respuestas EDNS pesadas.
La resolución fue mecánica: ajustar MTU y, para los resolvers recursivos internos, ajustar respuestas para evitar respuestas UDP sobredimensionadas cuando fuera posible. La “práctica aburrida” no fue el ajuste de MTU—fue que pudieron detectar y localizar el fallo en minutos. Sin heroísmos. Sin llamadas generales. Solo disciplina y observabilidad.
Listas de verificación / plan paso a paso
Checklist A: DNS por túnel completo que realmente funciona (Linux + Windows)
- Elige un servidor DNS de VPN que sea accesible desde la subred del túnel y que permita recursión desde ella.
- Añade la IP del servidor DNS a
AllowedIPs(al menos como/32) para que el enrutamiento sea determinista. - Linux:
- Si usas systemd-resolved, establece DNS por enlace wg con
resolvectl dns wg0 ...y asegúrate de que pueda usarse como predeterminado. - Si no usas resolved, asegúrate de que
resolvconfexista o gestiona/etc/resolv.confexplícitamente.
- Si usas systemd-resolved, establece DNS por enlace wg con
- Windows:
- Configura el DNS del adaptador WireGuard en el perfil del túnel.
- Asegúrate de que la métrica de interfaz prefiera WireGuard si quieres que sea el predeterminado.
- Verifica con captura de paquetes que las consultas DNS entren en el túnel.
- Verifica con
Resolve-DnsName/getentque las apps ven resultados correctos.
Checklist B: Split DNS para zonas corporativas (recomendado)
- Identifica namespaces internos (
corp,internal.corp, etc.). Sé explícito. - Linux: configura domains de enrutamiento en systemd-resolved en wg0:
resolvectl dns wg0 10.50.0.53resolvectl domain wg0 ~corp(y namespaces adicionales según necesites)
- Windows: crea reglas NRPT por namespace:
Add-DnsClientNrptRule -Namespace '.corp' -NameServers '10.50.0.53'
- Mantén el DNS público en la red local o en un resolvedor público dedicado, no en el resolver interno corporativo.
- Prueba:
- El nombre interno resuelve vía DNS de la VPN.
- El nombre público resuelve sin pasar por la VPN (a menos que lo quieras así).
Checklist C: Cuando “DNS no funciona” es realmente MTU
- Reproduce con un registro “grande” (TXT, DNSSEC o un nombre interno con muchas A/AAAA).
- Captura paquetes DNS y busca respuestas faltantes o fragmentos.
- Reduce MTU en la interfaz wg (prueba 1380) y vuelve a probar.
- Si reducir MTU lo arregla, mantén la MTU menor y documenta por qué. También revisa la PMTU en la ruta upstream si puedes.
Preguntas frecuentes
1) ¿Por qué WireGuard se conecta pero falla el DNS?
Porque el túnel puede estar sano mientras tu SO sigue usando los servidores DNS antiguos, o enruta las consultas DNS fuera del túnel. WireGuard no “posee” el DNS inherentemente; solo mueve paquetes.
2) ¿Es suficiente DNS= en wg-quick?
A veces. Depende de si tu sistema tiene la herramienta de integración del resolvedor que wg-quick espera. En sistemas con systemd-resolved, los ganchos explícitos con resolvectl son más deterministas.
3) ¿Por qué dig @10.50.0.53 funciona pero las búsquedas normales fallan?
Porque dig directo evita la selección del resolvedor del SO y peculiaridades de enrutamiento. Tu resolvedor del sistema aún apunta a otro lado, o está aplicando reglas de split DNS que no esperabas.
4) ¿Necesito añadir la IP del servidor DNS a AllowedIPs?
Si el servidor DNS vive detrás del túnel, sí. Añádelo explícitamente como /32 si hace falta. De lo contrario tu sistema puede intentar alcanzarlo por la ruta por defecto y tirar timeout.
5) ¿Cuál es la forma más limpia de hacer split DNS en Linux?
Dominios de enrutamiento de systemd-resolved: establece DNS en wg0 y asigna dominios ~corp a él. Evita cambios globales de DNS y mantiene la resolución externa local.
6) ¿Cuál es la forma más limpia de hacer split DNS en Windows?
Reglas NRPT por namespace. Forzan el servidor DNS para esos dominios, independientemente de métricas de interfaz o reconexiones de Wi‑Fi.
7) ¿Por qué algunas apps aún filtran DNS aunque configuré DNS de la VPN?
Algunas apps usan DNS-over-HTTPS o resolvedores personalizados y evitan la configuración DNS del SO. Arreglar eso es gestión de políticas de apps, no configuración de WireGuard.
8) ¿Cómo sé si las consultas DNS están saliendo fuera del túnel?
Captura paquetes en ambas interfaces. Si ves UDP/53 en Wi‑Fi/eth0 en lugar de wg0, es enrutamiento/política. No adivines; observa.
9) ¿Por qué el DNS es más lento sobre la VPN incluso cuando “funciona”?
Latencia, ubicación del resolvedor y comportamiento de caché. Un resolvedor corporativo lejos del usuario convierte cada página en un impuesto de latencia. El split DNS reduce ese impuesto.
10) ¿Debería ejecutar un resolvedor cache local en el cliente?
Puede ayudar al rendimiento, pero añade otra capa que puede cachear la elección upstream equivocada. Si lo haces, configura la selección upstream cuidadosamente y prueba el comportamiento de split DNS.
Conclusión: siguientes pasos que realmente funcionan
Si estás atascado en “DNS de WireGuard no funciona”, deja de tocar perillas al azar y sigue un camino disciplinado:
- Prueba primero la conectividad L3. Handshake y alcance IP al servidor DNS son hechos base.
- Observa hacia dónde van los paquetes DNS. La captura de paquetes acabará con los debates al instante.
- Haz la selección de DNS determinista. En Linux, prefiere systemd-resolved por enlace con dominios de enrutamiento para split DNS. En Windows, usa NRPT para split DNS y métricas solo cuando realmente quieras “todo por defecto”.
- Enruta el servidor DNS por el túnel. Inclúyelo en
AllowedIPspara que no se quede haciendo hairpin por el gateway local. - Documenta el comportamiento esperado. DNS por túnel completo y split DNS son productos distintos. Elige uno y escríbelo.
Haz eso y el DNS dejará de estar “misteriosamente roto”. Pasará a ser un sistema con entradas, salidas y rastro documental. Que es el único tipo de magia que los equipos de operaciones deberían tolerar.