VPNSmith
self-host-vpnHOWTO

Fugas DNS en WireGuard: detectar, diagnosticar y eliminar (2026)

WireGuard no bloquea fugas DNS por defecto. Guía de producción: por qué ocurren, herramientas de detección, soluciones para Linux/Windows/macOS/iOS/Android 2026.

Por Eric Gerard · Fondateur · VPNSmith — Spécialiste self-host VPN & VPS GDPR11 min de lecturaFoto vía Unsplash

Aviso de afiliación — Este artículo contiene enlaces de afiliado de Contabo. Si adquieres un VPS a través de ellos, ganamos una comisión sin coste adicional para ti. Solo documentamos lo que realmente utilizamos en producción en nuestros propios VPS.

Este es el defecto oculto de WireGuard del que nadie te advierte: configuras tu túnel, todo tu tráfico IP pasa por Contabo, te sientes seguro — excepto que tus consultas DNS siguen yendo a tu ISP, al router del hotel, o al resolver del Wi-Fi corporativo. Una fuga DNS destruye la promesa de privacidad de cualquier VPN: aunque tus datos estén cifrados, tu ISP sabe que visitas github.com, tu-banco.com, o cualquier otra cosa, porque resuelve los nombres por ti.

El problema es estructural a WireGuard. A diferencia de OpenVPN, el protocolo no toma ninguna posición sobre DNS — es un túnel IP puro. La directiva DNS = ... en tu .conf es solo una indicación para wg-quick y varía según el SO. Esta guía desglosa el porqué, cómo detectarlo, y las soluciones operativas por plataforma — basadas en un año de depuración de fugas reales en nuestros propios setups Contabo + WireGuard.

Cómo ocurre realmente una fuga DNS

Tres mecanismos distintos producen una fuga DNS en un cliente WireGuard:

1. El SO mantiene activos sus resolvers originales. En Linux sin resolvectl, el archivo /etc/resolv.conf es reescrito por NetworkManager, dhclient o systemd-resolved en cada evento (renovación DHCP, wake from sleep, cambio de red). El DNS que habías configurado vía wg-quick queda sobreescrito. La aplicación hace una consulta → el sistema interroga el DNS original → ese DNS ve tus consultas fuera del túnel.

2. Los navegadores con DNS over HTTPS / DNS over TLS cortocircuitan el SO. Firefox y Chrome traen DoH activado por defecto en muchas regiones. Cuando el navegador abre una conexión DoH hacia mozilla.cloudflare-dns.com, esa conexión sí transita por el túnel WireGuard (hasta ahí bien), pero el navegador cortocircuita completamente el resolver local. Si un proveedor DoH guarda logs, tus consultas son visibles allí, de otra forma.

3. Apps con resolvers hardcodeados. Algunas apps (Spotify, ciertas apps de Microsoft, algunos juegos) hardcodean 8.8.8.8 o sus servidores propietarios. Realizan una consulta UDP/53 directamente a 8.8.8.8 — y si tu firewall no bloquea eso fuera del túnel, la consulta sale.

La conclusión es brutal: una fuga DNS no es un bug de WireGuard, es un estado estructural de los sistemas operativos. Hay que bloquear activamente las cosas para prevenirlo.

Detección fiable — las herramientas correctas

Olvida los tests cosméticos de fugas por un momento. Aquí están las tres pruebas que ejecutamos cada vez que sospechamos una fuga:

Test 1: dnsleaktest.com (extended) + ipleak.net

Ambos sitios hacen lo mismo: cargan una página que realiza consultas DNS a subdominios únicos generados aleatoriamente, luego comprueban del lado del servidor qué resolvers solicitaron esos subdominios. Si ves resolvers en tu país de origen (tu ISP, el Wi-Fi de tu empresa), es una fuga. Si solo ves resolvers de la región de tu VPS (Cloudflare DE, Hetzner DE), estás limpio.

dnsleaktest.com/extended-test | ipleak.net

Test 2: tcpdump en el servidor (el más fiable)

Esta es la prueba realmente estanca. En tu VPS que aloja WireGuard:

tcpdump -i wg0 -n udp port 53

Déjalo corriendo. En tu cliente (laptop, móvil) conectado al túnel, escribe curl https://example.com. Debes ver una consulta DNS en el tcpdump en wg0. Si no ves nada, tu cliente resolvió el DNS sin pasar por el túnel = fuga.

Alternativa en el propio cliente, aún más limpia:

sudo tcpdump -i any -n udp port 53 and not net 10.66.0.0/16

Donde 10.66.0.0/16 es tu subred del túnel WireGuard. Si aparece algo aquí, es una fuga — tráfico DNS que fluye fuera del túnel.

Test 3: resolvectl status (solo Linux)

resolvectl status

Para cada interfaz, ves los servidores DNS en uso. La interfaz wg0 debe listar tu DNS de túnel, e idealmente la interfaz eth0 no debe tener servidores DNS (o estar ignorada). Si eth0 mantiene activos los resolvers de tu ISP, las aplicaciones los usarán cuando la resolución DNS falle en wg0 (comportamiento fallback).

Soluciones operativas por plataforma

Linux desktop — la solución más robusta

Recomendación: systemd-resolved + DNS por interfaz + bloqueo nftables.

En tu .conf de WireGuard, el bloque [Interface]:

[Interface]
PrivateKey = ...
Address = 10.66.0.2/24
DNS = 10.66.0.1
PostUp = resolvectl dns %i 10.66.0.1; resolvectl domain %i '~.'
PreDown = resolvectl revert %i

El dominio ~. le dice a systemd-resolved "todas las consultas DNS van por esta interfaz". El PreDown revierte al desconectar.

Luego el bloqueo nftables — bloquear todo tráfico DNS que NO vaya a tu VPS:

nft add table inet vpn_lock
nft add chain inet vpn_lock output { type filter hook output priority 0 \; }
nft add rule inet vpn_lock output udp dport 53 ip daddr != 10.66.0.1 drop
nft add rule inet vpn_lock output tcp dport 53 ip daddr != 10.66.0.1 drop

Persiste esto en /etc/nftables.conf para sobrevivir reboots. Esta regla bloquea cualquier paquete UDP/TCP 53 que no vaya a tu resolver del VPS. Brutal pero efectivo — cualquier fuga queda físicamente bloqueada.

Windows 10/11

El cliente WireGuard nativo respeta correctamente DNS = ... a través del driver Wintun. El problema: el split DNS no es ideal por defecto, y el DoH en Edge/Chrome puede cortocircuitar.

Pasos:

  1. En tu .conf, DNS = 10.66.0.1 (tu resolver del VPS).
  2. Deshabilitar DoH en el navegador: en Chrome chrome://settings/security → desmarcar "Usar DNS seguro"; en Edge la misma configuración.
  3. Hardening del firewall: Firewall de Windows Defender Seguridad avanzada → regla de salida bloqueando UDP/53 excepto a la IP de tu VPS. Comando PowerShell:
New-NetFirewallRule -DisplayName "Block DNS Leak" `
  -Direction Outbound -Protocol UDP -LocalPort 53 `
  -RemoteAddress "!10.66.0.1" -Action Block

El ! inicial significa "cualquier cosa excepto". Ajusta 10.66.0.1 a la IP de tu resolver del VPS.

macOS Sonoma/Sequoia

El cliente WireGuard de macOS (App Store) respeta el DNS correctamente. Pero la caché de mDNSResponder y la proximidad con .local pueden dar sorpresas.

Pasos:

  1. Config WireGuard: DNS = 10.66.0.1.
  2. Tras conectar, vacía la caché DNS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder.
  3. Deshabilitar DoH en el navegador (igual que en Windows).
  4. Verificar con scutil --dns que solo aparece tu DNS de túnel en el bloque "resolver #1".

iOS — el cliente WireGuard es honesto

El cliente oficial de WireGuard para iOS respeta DNS = ... correctamente. Normalmente no tienes que hacer nada más. Ojo con:

  • Safari puede usar iCloud Private Relay si está activo, lo que añade una capa extra (Cloudflare/Akamai) — no es una fuga, pero cambia el routing.
  • Las apps que usan puertos no estándar (algunas VoIP) pueden saltárselo — raro pero existe.

Test real: activa el túnel, ve a dnsleaktest.com en Safari, deberías ver solo resolvers de la región de tu VPS.

Android — el caso más complicado

El cliente oficial de WireGuard para Android gestiona el DNS parcialmente. El problema clásico: getprop net.dns1 de Android mantiene el DNS original activo, y algunas apps de Android consultan esa propiedad directamente, saltándose el túnel.

Mitigaciones por orden de preferencia:

  1. DNS privado de Android (Ajustes → Red → DNS privado) con un servidor DoT que controles: dns.adguard.com o tu propio servidor con Unbound + soporte DoT. DoT funciona incluso sin VPN, así que es una capa base de protección.
  2. AdGuard Home o NextDNS como proveedor de DNS privado: mismo setup, pero controlas totalmente el resolver.
  3. AFWall+ (requiere root): bloquea todo tráfico DNS salvo hacia tu VPS. Opción más agresiva, requiere root.

Veredicto honesto: Android WireGuard + DNS privado apuntando a tu propio VPS es el setup más robusto que hemos probado. Cero fugas en 6 meses de uso intensivo con el móvil.

Setup robusto en el VPS — Unbound en Contabo

La otra mitad de la ecuación es quién responde el DNS en tu VPS. Por defecto, si tu cliente WireGuard apunta a 10.66.0.1, ese es tu VPS — y el VPS mismo necesita un resolver real. Dos opciones viables:

Opción A: Unbound (purista, recursivo completo)

Unbound consulta directamente las raíces DNS. Cero logs de terceros. El setup de privacidad más limpio. Instalación en un VPS Contabo S (Debian 12):

apt install unbound unbound-anchor

Config mínima en /etc/unbound/unbound.conf.d/vpn.conf:

server:
  interface: 10.66.0.1
  access-control: 10.66.0.0/24 allow
  hide-identity: yes
  hide-version: yes
  qname-minimisation: yes
  use-caps-for-id: yes
  prefetch: yes
  cache-min-ttl: 300
  cache-max-ttl: 86400
  num-threads: 2
  msg-cache-size: 50m
  rrset-cache-size: 100m

Reinicia: systemctl restart unbound. Test desde un cliente: dig @10.66.0.1 example.com — deberías obtener una respuesta con ANSWER SECTION.

Opción B: AdGuard Home (filtrado + UI)

Si quieres bloqueo de publicidad y trackers a nivel DNS, AdGuard Home es la opción fácil. Web UI, listas de filtros (EasyList, EasyPrivacy, OISD, …), estadísticas por cliente. Instalación:

curl -s -S -L https://raw.githubusercontent.com/AdguardTeam/AdGuardHome/master/scripts/install.sh | sh -s -- -v

Setup web en el puerto 3000 → configurar escucha en 10.66.0.1:53. Upstream: dejar el stack DoT/DoH por defecto (o encadenar a Unbound en 127.0.0.1 para el modo purista completo).

Nosotros ejecutamos AdGuard Home → Unbound en nuestro propio Contabo. Lo mejor de ambos mundos: filtrado + cero logs.

Montar cualquiera de las dos opciones lleva 15 minutos en un VPS Contabo S recién provisionado a 4,99 €/mes (setup completo: tutorial Contabo paso a paso). El coste total se mantiene en 60 €/año para un VPS que gestiona WireGuard + tu resolver DNS de una sola vez.

Hardening DNS en el lado del VPS

Tres ajustes adicionales en el hub WireGuard que hacen las fugas DNS mucho más difíciles:

1. Forzar el DNS del túnel via iptables/nftables. En el VPS, interceptar cualquier tráfico UDP/53 que provenga de la subred WireGuard y redirigirlo a tu resolver local:

nft add rule ip nat prerouting iif wg0 udp dport 53 dnat to 10.66.0.1

Incluso si un cliente intenta consultar 8.8.8.8 directamente, el VPS intercepta y responde vía Unbound. Brutal pero a prueba de balas.

2. Bloquear fugas IPv6 en el servidor. Si tu VPS no deshabilita IPv6 en la interfaz wg0, algunos clientes fugarán DNS por IPv6 fuera del túnel. Deshabilita IPv6 completamente en el VPS (net.ipv6.conf.all.disable_ipv6=1 en /etc/sysctl.conf), o añade una ruta IPv6 ::/0 a través de wg0 en el AllowedIPs de los clientes.

3. Monitorización saliente de DNS inusual. Configura un cron diario en el VPS que audite los logs de Unbound buscando consultas de IPs externas (no pertenecientes a 10.66.0.0/24). Si llegan consultas desde fuera, tu túnel tiene fugas o está abierto. Consulta nuestro monitoreo WireGuard VPS con Prometheus + Grafana para un setup listo para dashboard.

Falsos positivos comunes — sin pánico

Dos situaciones que parecen fugas pero no lo son:

1. iCloud Private Relay (macOS/iOS). Si tienes Private Relay activo, las consultas DNS son retransmitidas doblemente por Apple + Cloudflare/Akamai. dnsleaktest.com a veces muestra "Cloudflare US" en lugar de tu DNS de túnel — eso es comportamiento esperado, no una fuga. Deshabilita Private Relay si quieres ver únicamente tu DNS de túnel.

2. Browser DoH (Firefox, Chrome). Con DoH activo, tu navegador bypasea el resolver del SO y consulta un servidor DoH (cloudflare-dns.com por defecto en Firefox). Técnicamente no es una fuga — la conexión va por el túnel WireGuard — pero sí significa que un tercero (Cloudflare) ve tus consultas. Deshabilita el DoH del navegador si quieres que todas las consultas pasen por tu resolver del VPS.

Veredicto final — la checklist anti-fugas en 5 minutos

Por orden de prioridad, lo que hay que implementar para eliminar las fugas DNS en un WireGuard self-host:

  1. DNS = 10.66.0.1 en tu .conf + PostUp = resolvectl dns %i 10.66.0.1; resolvectl domain %i '~.' en Linux.
  2. Firewall nftables/iptables que bloquee UDP/TCP 53 fuera del túnel en el cliente.
  3. Resolver en el VPS: Unbound o AdGuard Home en 10.66.0.1.
  4. DNAT en el VPS para UDP/53 desde wg0 hacia 10.66.0.1.
  5. Deshabilitar DoH en el navegador (o aceptar que Cloudflare vea tus consultas).
  6. Verificar con tcpdump -i any -n udp port 53 en el cliente — cero tráfico fuera de wg0 es el objetivo.

Un setup limpio de WireGuard en Contabo con este stack: cero fugas en 12 meses de uso intensivo. No hay magia — el protocolo es sólido, los sistemas operativos son problemáticos, y el bloqueo es estructural, no opcional.

Para profundizar

Fuentes y referencias:

Publicado el 2026-06-08. Tests y soluciones validados en Debian 12, Ubuntu 24.04, Windows 11 23H2, macOS Sonoma 14.5, iOS 17.5, Android 14 — con un VPS Contabo S Núremberg ejecutando WireGuard 1.0.20210914 + AdGuard Home + Unbound. El comportamiento puede diferir en otras distribuciones o versiones de SO — verifica siempre tu propio setup con tcpdump antes de considerarlo a prueba de fugas.

Aviso: WireGuard y el self-hosting de resolvers DNS son perfectamente legales en la UE, EE.UU., Canadá y la mayoría de países democráticos. VPNSmith publica este contenido con fines educativos.

★ Datacenter Nuremberg GDPR · ✓ IPv4 dédiée incluse · 200+ Mbps garantis

Probar Contabo30 jours satisfait ou remboursé→
Artículos relacionados

Para profundizar