VPNSmith
self-host-vpnHOWTO

Fuites DNS WireGuard : détecter, diagnostiquer, éliminer (2026)

WireGuard ne protège pas des fuites DNS par défaut. Guide production : comment les fuites se produisent réellement, vrais outils de détection, fixes opérationnels Linux/Windows/macOS/iOS/Android et hardening côté VPS Contabo en 2026.

Par Eric Gerard · Fondateur · VPNSmith — Spécialiste self-host VPN & VPS GDPR11 min de lecturePhoto via Unsplash

Divulgation d'affiliation — Cet article contient des liens d'affiliation Contabo. Si tu prends un VPS via ces liens, nous touchons une commission sans surcoût pour toi. Nous ne documentons que ce que nous opérons réellement en production sur nos propres VPS.

C'est le défaut caché de WireGuard dont personne ne te parle : tu mets en place ton tunnel, tout ton trafic IP passe par Contabo, tu te sens à l'abri — sauf que tes requêtes DNS continuent à partir vers ton FAI, ton routeur d'hôtel, ou le resolver de ton Wi-Fi corporate. Une fuite DNS détruit la promesse de confidentialité de n'importe quel VPN : même si tes données sont chiffrées, ton FAI sait que tu visites github.com, ta-banque.com, ou n'importe quoi d'autre, parce qu'il résout les noms pour toi.

Le problème est structurel à WireGuard. Contrairement à OpenVPN, le protocole ne prend aucune position sur le DNS — c'est un tunnel IP pur. La directive DNS = ... dans ton .conf n'est qu'un hint à wg-quick et varie selon l'OS. Ce guide déballe le pourquoi, le comment de la détection, et les fixes opérationnels par plateforme — basé sur un an de debug de vraies fuites sur nos propres setups Contabo + WireGuard.

Comment une fuite DNS se produit réellement

Trois mécanismes distincts produisent une fuite DNS sur un client WireGuard :

1. L'OS conserve ses resolvers d'origine actifs. Sous Linux sans resolvectl, le fichier /etc/resolv.conf est réécrit par NetworkManager, dhclient ou systemd-resolved à chaque événement (renouvellement DHCP, wake from sleep, changement de réseau). Le DNS que tu as poussé via wg-quick est écrasé. L'application fait une requête → le système interroge le DNS d'origine → ce DNS voit tes requêtes en dehors du tunnel.

2. Les browsers DNS over HTTPS / DNS over TLS court-circuitent l'OS. Firefox et Chrome embarquent DoH activé par défaut dans plusieurs régions. Quand le browser ouvre une connexion DoH vers mozilla.cloudflare-dns.com, cette connexion passe dans le tunnel WireGuard (jusque-là OK), mais le browser court-circuite complètement le resolver local. Si un provider DoH conserve des logs, tes requêtes sont visibles là, autrement.

3. Apps utilisant des resolvers hardcodés. Certaines apps (Spotify, certaines apps Microsoft, certains jeux) hardcodent 8.8.8.8 ou leurs serveurs propriétaires. Elles font une requête UDP/53 directement vers 8.8.8.8 — et si ton firewall ne bloque pas ça en dehors du tunnel, la requête sort.

Conclusion brutale : une fuite DNS n'est pas un bug de WireGuard, c'est un état structurel des OS. Il faut activement verrouiller les choses pour l'empêcher.

Détection fiable — les bons outils

Oublie les tests de fuite cosmétiques une minute. Voici les trois tests qu'on lance à chaque suspicion :

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

Les deux sites font la même chose : ils chargent une page qui fait des requêtes DNS vers des sous-domaines uniques générés aléatoirement, puis vont voir côté serveur quels resolvers ont demandé ces sous-domaines. Si tu vois des resolvers de ton pays d'origine (ton FAI, le Wi-Fi de ton entreprise), c'est une fuite. Si tu ne vois que des resolvers de la région de ton VPS (Cloudflare DE, Hetzner DE), tu es clean.

dnsleaktest.com/extended-test | ipleak.net

Test 2 : tcpdump côté serveur (le plus fiable)

C'est le test vraiment étanche. Sur ton VPS qui héberge WireGuard :

tcpdump -i wg0 -n udp port 53

Laisse tourner. Sur ton client (laptop, smartphone) connecté au tunnel, tape curl https://example.com. Tu dois voir une requête DNS dans le tcpdump sur wg0. Si tu ne vois rien, ton client a résolu le DNS sans passer par le tunnel = fuite.

Alternative côté client lui-même, encore plus propre :

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

Où 10.66.0.0/16 est le subnet de ton tunnel WireGuard. Si quoi que ce soit apparaît ici, c'est une fuite — trafic DNS qui sort en dehors du tunnel.

Test 3 : resolvectl status (Linux uniquement)

resolvectl status

Pour chaque interface, tu vois les serveurs DNS utilisés. L'interface wg0 doit lister ton DNS de tunnel, et idéalement l'interface eth0 ne doit pas avoir de serveurs DNS (ou être ignorée). Si eth0 conserve les resolvers de ton FAI actifs, les applications peuvent les utiliser quand la résolution DNS échoue sur wg0 (comportement fallback).

Fixes opérationnels par plateforme

Linux desktop — la solution la plus robuste

Recommandation : systemd-resolved + DNS par interface + lockdown nftables.

Dans ton .conf WireGuard, le bloc [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

Le domaine ~. dit à systemd-resolved "toutes les requêtes DNS passent par cette interface". Le PreDown annule à la déconnexion.

Puis lockdown nftables — bloquer tout trafic DNS qui ne va PAS vers ton 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

Persister dans /etc/nftables.conf pour survie au reboot. Cette règle tue tout paquet UDP/TCP 53 qui ne va pas vers ton VPS resolver. Brutal mais efficace — toute fuite est physiquement bloquée.

Windows 10/11

Le client WireGuard natif honore correctement DNS = ... via le driver Wintun. Le souci : le split DNS n'est pas terrible par défaut, et le DoH dans Edge/Chrome peut court-circuiter.

Étapes :

  1. Dans ton .conf, DNS = 10.66.0.1 (ton resolver VPS).
  2. Désactiver le DoH dans le browser : Chrome chrome://settings/security → décocher "Utiliser un DNS sécurisé" ; même chose dans Edge.
  3. Lockdown firewall : Pare-feu Windows Defender Sécurité avancée → règle sortante bloquant UDP/53 sauf vers l'IP de ton VPS. Commande PowerShell :
New-NetFirewallRule -DisplayName "Block DNS Leak" `
  -Direction Outbound -Protocol UDP -LocalPort 53 `
  -RemoteAddress "!10.66.0.1" -Action Block

La syntaxe ! en début veut dire "tout sauf". Ajuste 10.66.0.1 à l'IP de ton VPS resolver.

macOS Sonoma/Sequoia

Le client WireGuard macOS (App Store) honore le DNS correctement. Mais le cache mDNSResponder et la proximité avec .local peuvent réserver des surprises.

Étapes :

  1. Config WireGuard : DNS = 10.66.0.1.
  2. Après connexion, flush le cache DNS : sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder.
  3. Désactiver le DoH browser (idem Windows).
  4. Vérifier avec scutil --dns que seul ton DNS de tunnel apparaît dans le bloc "resolver #1".

iOS — le client WireGuard est honnête

Le client WireGuard officiel iOS honore le DNS = ... proprement. Tu n'as généralement rien à faire en plus. Attention toutefois :

  • Safari peut utiliser iCloud Private Relay si actif, qui ajoute une couche supplémentaire (Cloudflare/Akamai) — pas une fuite, mais ça modifie le routing.
  • Les apps utilisant des ports non standard (certaines apps VoIP) peuvent contourner — rare mais existe.

Test concret : active le tunnel, va sur dnsleaktest.com sur Safari, tu dois voir uniquement des resolvers de la région de ton VPS.

Android — le cas le plus chiant

Le client WireGuard Android officiel gère le DNS partiellement. Le problème classique : Android getprop net.dns1 conserve le DNS d'origine actif, et certaines apps Android interrogent cette prop directement, court-circuitant le tunnel.

Mitigations en ordre de préférence :

  1. NetGuard ou AFWall+ en couplage avec WireGuard : NetGuard crée un VPN local qui verrouille tout le trafic DNS sur ton tunnel. Gratuit, open-source sur F-Droid.
  2. DNS privé Android (Paramètres → Réseau → DNS privé) avec un serveur DoT que tu maîtrises : dns.adguard.com ou ton propre serveur avec Unbound + support DoT. DoT fonctionne même sans VPN, donc c'est une couche de base.
  3. AdGuard Home ou NextDNS comme provider DNS privé : même setup, mais tu maîtrises totalement le resolver.

Verdict honnête : Android WireGuard + DNS privé pointant vers ton VPS est le setup le plus robuste qu'on ait testé. Aucune fuite sur 6 mois d'utilisation smartphone intensive.

Setup robuste côté VPS — Unbound sur Contabo

L'autre moitié de l'équation est quel resolver répond sur ton VPS. Par défaut, si ton client WireGuard pointe vers 10.66.0.1, c'est ton VPS — et le VPS lui-même a besoin d'un vrai resolver. Deux options viables :

Option A : Unbound (puriste, recursive full)

Unbound interroge directement les racines DNS. Zéro log tiers. La solution privacy la plus propre. Installation sur VPS Contabo S (Debian 12) :

apt install unbound unbound-anchor

Config minimale dans /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

Restart : systemctl restart unbound. Test depuis un client : dig @10.66.0.1 example.com — tu dois recevoir une réponse avec ANSWER SECTION.

Option B : AdGuard Home (filtering + UI)

Si tu veux du blocage de pub/trackers au niveau DNS, AdGuard Home est le choix facile. Web UI, listes de filtres (EasyList, EasyPrivacy, OISD, …), stats par client. Installation :

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

Setup web sur port 3000 → mettre en écoute sur 10.66.0.1:53. Upstream : laisser le stack DoT/DoH par défaut (ou chaîner sur Unbound en 127.0.0.1 pour purist mode complet).

On fait tourner AdGuard Home → Unbound sur notre propre Contabo. Best of both worlds : filtering + zéro log.

La mise en place de l'une ou l'autre option prend 15 minutes sur un VPS Contabo S fraîchement provisionné à 4,99 €/mois (setup complet : tutoriel Contabo pas-à-pas). Le coût total reste de 60 €/an pour un VPS qui héberge WireGuard + ton resolver DNS d'un coup.

Hardening DNS leak côté VPS

Trois tweaks supplémentaires côté hub WireGuard qui rendent les fuites DNS beaucoup plus difficiles :

1. Forcer le DNS de tunnel via iptables/nftables. Sur le VPS, intercepter tout trafic UDP/53 qui provient du subnet WireGuard et le rediriger vers ton resolver local :

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

Même si un client essaie d'interroger 8.8.8.8 directement, le VPS intercepte et répond via Unbound. Brutal mais bulletproof.

2. Bloquer la fuite IPv6 côté serveur. Si ton VPS n'a pas désactivé IPv6 sur l'interface wg0, certains clients vont laisser fuir du DNS via IPv6 en dehors du tunnel. Soit tu désactives IPv6 complètement sur le VPS (net.ipv6.conf.all.disable_ipv6=1 dans /etc/sysctl.conf), soit tu pushes une route IPv6 ::/0 à travers wg0 dans le AllowedIPs des clients.

3. Monitoring outbound des DNS inhabituels. Mettre en place un cron quotidien sur le VPS qui audite les logs Unbound pour des requêtes venant d'IPs externes (pas 10.66.0.0/24). Si des requêtes arrivent de l'extérieur, ton tunnel est troué ou ouvert. Voir notre monitoring WireGuard VPS avec Prometheus + Grafana pour un setup dashboard prêt.

Faux positifs courants — pas de panique

Deux situations ressemblent à des fuites mais n'en sont pas :

1. iCloud Private Relay (macOS/iOS). Si tu as Private Relay activé, tes requêtes DNS sont doublement relayées par Apple + Cloudflare/Akamai. dnsleaktest.com affiche parfois "Cloudflare US" au lieu de ton DNS de tunnel — c'est attendu, pas une fuite. Désactive Private Relay si tu veux voir uniquement ton DNS de tunnel.

2. Browser DoH (Firefox, Chrome). Avec DoH activé, ton browser court-circuite le resolver de l'OS et interroge un serveur DoH (cloudflare-dns.com par défaut dans Firefox). Techniquement ce n'est pas une fuite — la connexion passe par le tunnel WireGuard — mais ça veut dire qu'un tiers (Cloudflare) voit tes requêtes. Désactive le DoH du browser si tu veux que toutes les requêtes passent par ton resolver VPS.

Verdict final — la checklist anti-fuite en 5 minutes

Par ordre de priorité, ce qu'il faut mettre en place pour éliminer les fuites DNS sur un WireGuard self-host :

  1. DNS = 10.66.0.1 dans ton .conf + PostUp = resolvectl dns %i 10.66.0.1; resolvectl domain %i '~.' sous Linux.
  2. Firewall nftables/iptables qui bloque UDP/TCP 53 en dehors du tunnel côté client.
  3. Resolver côté VPS : Unbound ou AdGuard Home sur 10.66.0.1.
  4. DNAT côté VPS pour UDP/53 depuis wg0 vers 10.66.0.1.
  5. Désactiver le DoH du browser (ou accepter que Cloudflare voie tes requêtes).
  6. Vérifier avec tcpdump -i any -n udp port 53 côté client — zéro trafic en dehors de wg0 est l'objectif.

Un setup propre WireGuard sur Contabo avec ce stack : aucune fuite sur 12 mois d'usage intensif. Pas de magie — le protocole est solide, les OS sont chiants, et le lockdown est structurel, pas optionnel.

Pour aller plus loin

Sources et références :

Publié le 2026-06-05. Tests et fixes validés sur Debian 12, Ubuntu 24.04, Windows 11 23H2, macOS Sonoma 14.5, iOS 17.5, Android 14 — avec un VPS Contabo S Nuremberg faisant tourner WireGuard 1.0.20210914 + AdGuard Home + Unbound. Le comportement peut différer sur d'autres distros ou versions d'OS — toujours vérifier ton propre setup avec tcpdump avant de le considérer leak-proof.

Rappel : WireGuard et le self-hosting de resolvers DNS sont parfaitement légaux dans l'UE, aux US, au Canada et dans la plupart des pays démocratiques. VPNSmith publie ce contenu à des fins éducatives.

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

Voir l'offre Contabo30 jours satisfait ou remboursé→
Articles liés

Pour aller plus loin