Vous montez le tunnel. Le handshake est propre. Vous pouvez pinguer une IP côté distant. Puis vous tentez un nom d’hôte et tout s’effondre : les navigateurs tournent en rond, les installations de paquets échouent, et votre agent de supervision se met à hurler « temporary failure in name resolution ».
C’est le piège classique de WireGuard : le VPN fonctionne, vos paquets voyagent, et le DNS part discrètement ailleurs. Les échecs DNS ne sont rarement « un problème DNS ». Ce sont généralement des problèmes de routage, de politique ou d’intégration du résolveur déguisés en DNS.
Playbook de diagnostic rapide
Si vous ne faites rien d’autre, faites ceci. C’est le chemin le plus rapide de « le DNS est cassé » à « voici le composant exact qui me ment ».
1) Prouvez que le tunnel fonctionne sans DNS
- Pinguez une IP connue à travers le tunnel (un routeur côté VPN, l’IP du serveur DNS ou un VIP de service).
- Si la connectivité IP échoue, arrêtez. Ce n’est plus un article sur le DNS ; c’est du routage/pare-feu/AllowedIPs.
2) Identifiez quel résolveur vous utilisez réellement
- Sur Linux : vérifiez si vous êtes sur systemd-resolved, NetworkManager, ou simplement /etc/resolv.conf.
- Sur Windows : vérifiez si l’adaptateur WireGuard a des serveurs DNS et si NRPT est en jeu.
3) Surveillez les paquets DNS
- Lancez une capture de paquets sur l’interface WireGuard et sur l’interface physique.
- Décision : si les requêtes DNS sortent par la mauvaise interface, vous avez un problème de routage/politique ; si elles sortent correctement mais ne reçoivent pas de réponse, vous avez un problème de pare-feu/ACL/NAT ou un problème côté serveur.
4) Confirmez que le serveur DNS côté VPN est joignable et répond
- Interrogez le serveur DNS par IP explicitement (contournez le comportement du résolveur local).
- Décision : si la requête directe fonctionne mais que la résolution normale échoue, l’intégration du résolveur OS est incorrecte.
5) Vérifiez les attentes de split DNS versus la réalité
- Attendez-vous à ce que seuls corp.example résolvent via le VPN, tandis que le DNS public reste local ?
- Si oui, vous avez besoin d’un routage basé sur le domaine (systemd-resolved/NetworkManager sur Linux, NRPT sur Windows). WireGuard lui-même ne fait pas de politique basée sur le domaine.
Une règle sèche : ne changez pas cinq choses à la fois. Le DNS est un menteur ; vous avez besoin d’expériences contrôlées.
Un modèle mental fonctionnel : où le DNS casse avec WireGuard
WireGuard est volontairement petit et simple (dans le bon sens). Il chiffre les paquets entre pairs. Il crée une interface. Il a un concept de « quelles plages IP doivent aller dans ce tunnel » (AllowedIPs). C’est tout.
Le DNS, pendant ce temps, vit dans un monde désordonné et spécifique à l’OS :
- Les applications appellent une bibliothèque résolveur.
- La bibliothèque résolveur consulte la configuration (qui peut être un fichier, un démon, un gestionnaire réseau, ou les trois qui se disputent).
- Les requêtes sont envoyées aux serveurs DNS configurés sur UDP/TCP 53 (ou parfois DoT/DoH si votre système est sophistiqué ou maudit).
- Ces paquets suivent votre table de routage et vos règles de politique comme n’importe quel autre trafic.
Donc « DNS WireGuard ne fonctionne pas » signifie généralement l’un de ces cas :
- Votre système n’a jamais changé de serveurs DNS quand le tunnel est monté.
- Il a changé, mais les paquets DNS sont routés hors du tunnel de toute façon.
- Ils entrent dans le tunnel, mais le serveur est injoignable depuis cette IP source ou bloqué.
- Split tunnel + DNS d’entreprise : vous avez besoin de routage par domaine, mais vous avez configuré un serveur DNS global unique.
- Votre démon résolveur local met en cache de la mauvaise chose ou refuse d’envoyer des requêtes au serveur DNS VPN à cause de « DNSSEC », « privacy », ou « je sais mieux ».
La ligne DNS= dans wg-quick n’est pas magique. C’est un crochet de confort qui tente d’intégrer votre OS. Quand il échoue, il échoue silencieusement, comme un adulte qui snobe une invitation à une réunion.
Faits intéressants et contexte historique (pour arrêter de vous disputer avec votre laptop)
- Le DNS précède les VPN modernes de plusieurs décennies. Le DNS a été standardisé au début des années 1980 ; la plupart des designs VPN sont venus bien plus tard, donc « l’intégration DNS » est greffée, pas fondamentale.
- WireGuard évite volontairement de pousser des options de type DHCP. Les VPN d’entreprise traditionnels poussaient souvent des paramètres DNS ; WireGuard n’a pas de canal de contrôle intégré pour cela.
- /etc/resolv.conf n’a jamais été conçu pour la complexité d’aujourd’hui. Il a commencé comme un simple fichier ; les systèmes modernes l’ont remplacé par des démons parce que les portables bougent et les interfaces apparaissent/disparaissent.
- systemd-resolved a introduit le routage DNS par lien. C’est ce qui rend le split DNS sensé sur Linux — quand il est configuré correctement.
- Windows a depuis longtemps une politique DNS basée sur le domaine. NRPT (Name Resolution Policy Table) existe surtout parce que les entreprises ont exigé « ces domaines vont à ces serveurs DNS ».
- Le DNS peut utiliser UDP ou TCP. La plupart des gens oublient que TCP 53 existe jusqu’à ce que des fragments UDP soient perdus et que soudain « seules les grosses requêtes échouent ».
- EDNS0 a rendu le DNS « plus gros » et plus fragile. Des réponses plus grandes signifient fragmentation et les problèmes de PMTU apparaissent sous forme de « pannes DNS aléatoires ».
- Le DNS d’entreprise bloque souvent la récursion depuis des sous-réseaux « inconnus ». Si votre tunnel vous donne une nouvelle plage d’adresses et que l’ACL DNS n’est pas mise à jour, ça ressemble à une panne DNS.
Une citation, parce qu’elle colle mieux au travail d’opérations que les posters de motivation :
« L’espoir n’est pas une stratégie. » — attribué à Vince Lombardi
Modes de panne courants : ce que « DNS ne fonctionne pas » signifie réellement
Mode A : le DNS ne change jamais après la montée du tunnel
Symptômes typiques : vous pouvez résoudre des domaines publics mais pas des domaines internes ; ou vous continuez à résoudre des noms internes vers des adresses publiques (ou rien).
Pourquoi cela arrive : wg-quick n’a pas appliqué les paramètres DNS parce que votre distribution utilise un gestionnaire de résolveur que wg-quick ne sait pas contacter (ou il a essayé et échoué). Ou le système a réécrit le DNS via NetworkManager/DHCP.
Mode B : le DNS change, mais les requêtes sortent par la mauvaise interface
Symptômes typiques : le système montre le serveur DNS VPN configuré, mais la capture de paquets montre que les requêtes sortent par l’interface Wi‑Fi.
Pourquoi cela arrive : votre route vers l’IP du serveur DNS pointe vers la passerelle physique, pas vers le tunnel ; ou le routage politique envoie UDP/53 via la table par défaut.
Mode C : les requêtes vont dans le tunnel, le serveur ne répond pas
Symptômes typiques : tcpdump montre des paquets DNS sortants sur wg0, mais pas de réponses.
Pourquoi cela arrive : règles de pare-feu, NAT manquant sur le serveur VPN, ACL du serveur DNS qui n’autorise pas votre sous-réseau de tunnel, ou mauvaise IP source à cause du routage politique.
Mode D : attentes de split tunnel sans split DNS
Symptômes typiques : tout devient lent ou casse quand vous définissez le DNS VPN globalement ; les connexions SaaS échouent ; l’interne marche mais l’externe semble hanté.
Pourquoi cela arrive : vous avez pointé tout le DNS vers un résolveur d’entreprise qui bloque ou filtre les domaines externes, ou il n’est joignable que via le tunnel alors que vous avez du split-tunneling.
Mode E : MTU/fragmentation cause des échecs DNS « aléatoires »
Symptômes typiques : les petites requêtes fonctionnent, les grosses échouent ; les zones internes avec beaucoup d’enregistrements échouent ; DNSSEC cause des douleurs intermittentes.
Pourquoi cela arrive : fragmentation UDP ou trous PMTU sur le chemin du tunnel ; WireGuard ajoute une surcharge ; votre MTU est trop optimiste.
Blague #1 : le DNS, c’est comme le commérage de bureau — rapide, peu fiable, et il prend toujours la route la plus dramatique possible.
Tâches pratiques (avec commandes, sorties et décisions)
Voici des contrôles réels que vous pouvez exécuter en production et sur les portables. Chaque tâche inclut : commande, sortie représentative, ce que ça signifie, et la décision suivante. Exécutez-les selon votre suspicion, pas selon votre vanité.
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
Ce que ça signifie : Le handshake est récent ; le trafic passe. Les problèmes DNS sont probablement d’ordre résolveur/routage, pas crypto.
Décision : Si le handshake est « never », corrigez la connectivité/les clés/endpoint avant de toucher au 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
Ce que ça signifie : Il existe un chemin L3 vers le serveur DNS. Si le DNS échoue toujours, suspectez le filtrage UDP/53, la configuration du résolveur ou une politique de split DNS.
Décision : Si le ping échoue, vérifiez le routage/AllowedIPs/pare-feu d’abord.
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
Ce que ça signifie : Le serveur DNS VPN fonctionne. Si la résolution normale échoue, votre OS ne l’utilise pas (ou le routage vers lui est incorrect pour les requêtes normales).
Décision : Remontez la pile : configuration du gestionnaire de résolveur, DNS par lien, et vérifications de route/politique.
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
Ce que ça signifie : Vous êtes sur le stub de systemd-resolved. Vos vrais serveurs DNS sont gérés ailleurs.
Décision : Utilisez resolvectl pour inspecter le DNS par interface ; n’« écrasez » pas le fichier stub.
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
Ce que ça signifie : Le split DNS est configuré : ~corp va vers 10.50.0.53. Tout le reste passe via eth0.
Décision : Si wg0 n’a pas de serveur DNS ou de route de domaine, corrigez votre PostUp wg-quick ou votre profil 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
Ce que ça signifie : Le noyau routage le trafic vers le serveur DNS via l’interface du tunnel.
Décision : Si ça montre dev eth0, vous avez une fuite de route : ajoutez l’IP du serveur DNS à AllowedIPs et/ou corrigez le routage politique.
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
Ce que ça signifie : Le chemin résolveur au niveau système peut résoudre le nom. C’est plus proche de « ce que feront les applis » que dig dans beaucoup d’environnements.
Décision : Si getent échoue mais dig @10.50.0.53 fonctionne, l’intégration du résolveur OS est incorrecte.
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)
Ce que ça signifie : Les requêtes et réponses DNS traversent wg0. Le routage est correct et le serveur répond.
Décision : Si vous voyez des requêtes sur eth0 à la place, corrigez les routes ; si vous voyez des requêtes sur wg0 mais pas de réponses, vérifiez le pare-feu/ACL/NAT sur l’autre bout.
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
Ce que ça signifie : Aucune règle de routage politique supplémentaire n’est présente. C’est correct pour des setups simples « route par destination », mais le split tunneling demande parfois plus.
Décision : Si vous essayez de faire du routage split avancé (comme « uniquement le DNS via VPN »), envisagez des règles explicites ou le DNS par lien via 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
Ce que ça signifie : Le MTU est 1420, une valeur courante raisonnable. Si vous êtes sur PPPoE, LTE ou des clouds exotiques, vous pourriez avoir besoin d’une valeur plus basse.
Décision : Si les grosses réponses DNS échouent, testez avec un MTU plus petit (par ex. 1380) et revérifiez le comportement.
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}
Ce que ça signifie : L’adaptateur WireGuard a le serveur DNS configuré. C’est nécessaire, mais pas suffisant.
Décision : Si l’adaptateur WireGuard n’a aucun serveur DNS, corrigez le profil WireGuard Windows (ou utilisez NRPT pour le 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
Ce que ça signifie : Windows a interrogé le serveur DNS attendu.
Décision : Si Server affiche votre routeur Wi‑Fi ou un DNS public, vous avez un problème de métriques d’interface/NRPT/suffixe.
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
Ce que ça signifie : Une métrique plus basse tend à gagner. Ici, l’interface WireGuard est préférée, ce qui est souvent souhaitable pour un DNS full-tunnel.
Décision : Si la métrique WireGuard est plus élevée et que vous voulez que le DNS VPN soit utilisé, abaissez-la — ou utilisez NRPT pour que le routage par domaine ne dépende pas des métriques.
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}
Ce que ça signifie : Les requêtes pour *.corp sont dirigées vers le serveur DNS VPN indépendamment du comportement DNS par défaut.
Décision : Si vous avez besoin de split DNS sur Windows, NRPT est l’approche adulte. Configurez-le intentionnellement et testez avec Resolve-DnsName.
Configuration DNS correcte sur Linux
La configuration DNS sur Linux n’est pas un seul système. C’est un écosystème de suggestions polies et de démons rivaux. Votre objectif est de choisir une autorité et de la rendre déterministe.
Reality check Linux : choisissez votre voie résolveur
En pratique, vous êtes dans l’un de ces camps :
- systemd-resolved (courant sur Ubuntu, variantes Debian, Fedora, etc.). Meilleure option pour le split DNS quand elle est utilisée correctement.
- NetworkManager gérant le DNS (s’intègre souvent à resolved ; parfois non).
- Openresolv/resolvconf écrivant /etc/resolv.conf. Encore courant sur serveurs minimaux et conteneurs.
- /etc/resolv.conf statique. Parfait jusqu’à ce que vous changez de réseau ; ensuite, c’est une scène de crime.
Ce que wg-quick fait réellement avec DNS=
wg-quick est un script shell. Quand vous mettez DNS=10.50.0.53 dans la config, il tente d’appeler des outils comme resolvconf ou d’interagir avec resolved via resolvectl selon la distro. Si ces outils ne sont pas présents, le DNS peut simplement ne pas changer.
Opinion : ne comptez pas sur une intégration « peut-être ». Pour les portables, intégrez-vous explicitement au gestionnaire réseau de la plateforme ou à resolved. Pour les serveurs, préférez une configuration résolveur déterministe qui survit aux redémarrages et aux redémarrages de services.
Mises en place correctes (choisissez-en une)
Setup 1 : split DNS systemd-resolved (recommandé pour les domaines d’entreprise)
C’est ce que vous voulez si votre exigence est : les domaines internes résolvent via le DNS VPN ; tout le reste résout via le réseau local (ou un résolveur public).
WireGuard lui-même ne peut pas faire d’« AllowedIPs par domaine ». Mais resolved peut faire la sélection de serveur DNS par domaine. Vous combinez les deux : routez l’IP du serveur DNS dans le tunnel, et indiquez à resolved quel domaine va vers ce serveur.
Exemple de config 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
Ce qui compte ici :
- AllowedIPs inclut les réseaux internes dont vous avez réellement besoin et l’IP du serveur DNS (10.50.0.53/32) pour que le chemin de requête soit sans ambiguïté.
- resolvectl dns %i définit le DNS sur le lien wg0.
- resolvectl domain %i ~corp le rend « routing-only » pour ce domaine, pas une route DNS globale.
- revert nettoie à la descente. Vous voulez un nettoyage. Le vous du futur en veut encore plus.
Test : après avoir monté l’interface, resolvectl status devrait montrer wg0 avec DNS Domain: ~corp. Ensuite vérifiez le trafic avec tcpdump.
Setup 2 : systemd-resolved full-tunnel DNS (simple, parfois adapté)
Si vous voulez : « quand le VPN est actif, toutes les requêtes DNS vont au DNS VPN », vous pouvez définir wg0 comme route DNS par défaut en n’utilisant pas un domaine en mode routing-only. Vous pouvez garder le split tunnel pour le trafic, mais attention : si votre serveur DNS n’est joignable que via le VPN et que votre DNS est global, vous venez de faire du DNS une dépendance dure pour tout.
En termes de resolved : définissez le serveur DNS sur wg0 et autorisez-le comme route DNS par défaut (ou définissez le DNS global). L’approche la plus propre varie selon l’intégration de la distro, mais un pattern fiable reste PostUp/Down avec resolvectl, simplement sans le domaine ~corp. Vous pouvez définir une route pour le domaine « . », mais cela peut être trop agressif.
Opinion : le DNS full-tunnel sur les portables crée souvent des dysfonctionnements SaaS étranges quand les résolveurs d’entreprise filtrent. Utilisez le split DNS quand vous le pouvez.
Setup 3 : resolvconf/openresolv (commun sur petits serveurs)
Si votre système n’utilise pas resolved, wg-quick avec DNS= peut fonctionner si resolvconf existe. Sinon, vous verrez le DNS ne jamais changer et vous vous demanderez pourquoi vous payez l’électricité.
Installer et vérifier les outils :
cr0x@server:~$ command -v resolvconf || echo "resolvconf not found"
resolvconf not found
Décision : Si vous voulez compter sur wg-quick DNS, installez resolvconf/openresolv. Si vous voulez un comportement déterministe, gérez /etc/resolv.conf vous-même ou migrez vers resolved.
Exemple de config wg-quick utilisant 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
Pièges Linux qui causent « le DNS ne fonctionne pas »
- Confusion du stub resolv.conf : éditer /etc/resolv.conf quand c’est un symlink vers un stub ne fera pas ce que vous pensez.
- NetworkManager vous combat : il peut écraser le DNS par connexion. Décidez si NM gère le DNS ; si oui, configurez-le là.
- Résolveurs locaux en cache : unbound ou dnsmasq peuvent tourner et relayer vers le mauvais endroit.
- DNS VPN joignable uniquement via le tunnel : si la route vers le serveur DNS n’est pas dans AllowedIPs, le système tentera de le joindre localement et échouera.
- Règles de sortie du pare-feu : le pare-feu local peut bloquer UDP/53 sur wg0 parce que quelqu’un a cru que c’était du « durcissement ».
Configuration DNS correcte sur Windows
Windows est à la fois meilleur et pire ici. Meilleur parce qu’il a des contrôles de politique de première classe (NRPT). Pire parce qu’il va « vous aider » avec les métriques d’interface, les listes de suffixes DNS et un cache qui ressemble à du gaslighting.
Ce que le client WireGuard Windows change vraiment
L’application WireGuard Windows crée un adaptateur virtuel. Quand vous définissez DNS dans le profil du tunnel, elle configure les serveurs DNS de cet adaptateur. Que Windows utilise ce DNS pour une requête dépend de :
- Quelle interface est choisie pour la résolution de nom (métriques et ordre de binding).
- Si vous utilisez le split DNS via NRPT.
- Les listes de suffixes de recherche et quels noms sont considérés « in-domain ».
- Si la requête est faite par une appli utilisant les API DNS système (la plupart le font) ou par une appli qui embarque son propre résolveur (certaines le font, et celles-là sont une joie particulière).
Deux patrons sensés sur Windows
Pattern 1 : DNS full-tunnel (simple)
Si vous voulez « tout le DNS va au DNS VPN », faites ceci :
- Définissez les serveurs DNS de l’adaptateur WireGuard dans le profil.
- Assurez-vous que l’adaptateur WireGuard a une métrique d’interface basse afin d’être préféré.
- Assurez-vous que l’IP du serveur DNS est routée via le tunnel (AllowedIPs l’inclut).
C’est le moins de pièces en mouvement. C’est aussi le plus susceptible d’irriter les utilisateurs si le DNS d’entreprise bloque les recherches externes ou renvoie des réponses filtrées.
Pattern 2 : split DNS avec NRPT (recommandé pour les domaines d’entreprise)
Si vous voulez « seuls les domaines corp utilisent le DNS VPN », utilisez NRPT. NRPT peut cibler des namespaces (domaines) et forcer des résolveurs spécifiques pour ces noms. Il enlève la dépendance aux métriques d’interface et réduit le comportement aléatoire lors des reconnexions Wi‑Fi.
Créer une règle NRPT (exemple) :
cr0x@server:~$ powershell -NoProfile -Command "Add-DnsClientNrptRule -Namespace '.corp' -NameServers '10.50.0.53'"
Vérifiez-la :
cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientNrptRule | Where-Object Namespace -eq '.corp' | Format-List"
Namespace : .corp
NameServers : {10.50.0.53}
Testez la résolution et confirmez quel serveur a répondu :
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
Décision : Si cela fonctionne de façon fiable, conservez-le. Si les utilisateurs ont besoin de plusieurs namespaces internes, ajoutez-les explicitement. N’essayez pas d’être trop malin avec des wildcards ; vous perdrez.
Modes de panne spécifiques à Windows
- Guerres de métrique d’interface : Windows peut décider que le Wi‑Fi est « meilleur » et utiliser son DNS pour tout. Abaissez la métrique WireGuard ou utilisez NRPT.
- Résolution multi-homée : Windows peut tester plusieurs interfaces ; les résultats peuvent être incohérents quand un serveur DNS renvoie NXDOMAIN et l’autre renvoie une réponse.
- Mauvaise liste de suffixes : Les utilisateurs tapent internal et s’attendent à internal.corp. Sans le bon suffixe, ils n’obtiennent rien (ou pire, des résultats publics).
- Applications qui ignorent le DNS système : Certains navigateurs et agents utilisent DNS-over-HTTPS ou leur propre résolveur. Vos paramètres VPN DNS ne compteront pas jusqu’à ce que vous désactiviez ou gériez ce comportement.
Blague #2 : le dépannage DNS sur Windows est un bon choix de carrière parce qu’il garantit la sécurité de l’emploi — surtout pour celui qui hérite de votre machine après le reboot.
Erreurs courantes : symptômes → cause racine → fix
Ceux-ci reviennent sans cesse. Ils font perdre des heures parce qu’ils « ressemblent » à du DNS alors que ce sont en fait du routage ou de la sélection de résolveur.
1) « Le handshake est up, mais les noms internes ne résolvent pas »
Symptôme : wg show a l’air bon. ping 10.60.12.34 fonctionne. getent hosts internal.service.corp échoue.
Cause racine : L’OS n’utilise pas le serveur DNS VPN ; l’intégration wg-quick DNS n’a pas été appliquée.
Fix : Sur Linux, configurez systemd-resolved via resolvectl dns/domain ou configurez NetworkManager. Sur Windows, définissez le DNS de l’adaptateur ou utilisez NRPT.
2) « Le serveur DNS est réglé sur 10.50.0.53, mais il timeout »
Symptôme : Le résolveur pointe vers le DNS VPN, mais dig montre des timeouts.
Cause racine : La route vers l’IP du serveur DNS n’est pas via wg0 ; AllowedIPs manque l’adresse du serveur DNS ou le sous-réseau interne qui la contient.
Fix : Ajoutez 10.50.0.53/32 (ou le sous-réseau DNS) à AllowedIPs. Vérifiez avec ip route get 10.50.0.53.
3) « Seules les grosses réponses DNS échouent (ou seulement certains domaines) »
Symptôme : Les petites recherches fonctionnent, les zones à fort DNSSEC échouent, ou les requêtes TXT meurent.
Cause racine : MTU/fragmentation/PMTU sur le chemin du tunnel.
Fix : Réduisez le MTU de WireGuard (par ex. 1380) et retestez. Si nécessaire, forcez TCP pour le dépannage avec des outils, et inspectez les captures pour des fragments.
4) « La navigation externe casse quand le VPN est connecté, mais l’interne marche »
Symptôme : VPN up ; les applis d’entreprise marchent ; les sites publics stagnent ou résolvent vers des adresses étranges.
Cause racine : Vous avez défini le DNS d’entreprise globalement, et ce résolveur filtre ou détourne les recherches externes ; ou les requêtes externes repassent par le VPN et sont thottlées.
Fix : Utilisez le split DNS (résolution par domaine via resolved sur Linux ; NRPT sur Windows). Gardez le DNS public local ou utilisez un résolveur public dédié, pas le résolveur interne pour tout.
5) « Ça marche dans les outils CLI mais pas dans les navigateurs »
Symptôme : dig et getent fonctionnent, mais le navigateur ne charge pas les hostnames internes.
Cause racine : Le navigateur utilise DNS-over-HTTPS ou son propre résolveur ; il contourne la sélection DNS système.
Fix : Désactivez DoH pour les environnements d’entreprise ou configurez des politiques d’entreprise pour que les domaines internes se résolvent via le DNS système.
6) « Ça marchait hier, maintenant ça ne marche plus, et le reboot « fixe » »
Symptôme : Résolution intermittente ; le reboot la corrige.
Cause racine : État de cache du résolveur en désaccord (cache systemd-resolved, cache DNS Windows) ou rebonds d’interface causant une mauvaise sélection du serveur DNS.
Fix : Videz les caches comme diagnostic ; puis corrigez la sélection DNS déterministe (DNS par lien, NRPT, métriques appropriées). Arrêtez de traiter le reboot comme une solution.
Trois mini-histoires d’entreprise issues du terrain
Mini-histoire 1 : L’incident causé par une mauvaise hypothèse
Ils ont déployé WireGuard pour remplacer un VPN d’accès à distance vieillissant. Le plan de migration était propre : le tunnel monte, les utilisateurs accèdent aux services internes, terminé. L’équipe a même testé la connectivité avec des pings et quelques curl vers des IPs. Tout semblait vert.
Le lundi matin est arrivé et le volume de tickets a explosé. « VPN connecté mais rien ne marche. » L’astreinte a vérifié le serveur WireGuard. Les handshakes avaient lieu. Les compteurs de trafic bougeaient. Le tunnel n’était pas down ; il était indifférent.
L’hypothèse a tué : quelqu’un croyait que mettre DNS=10.50.0.53 dans la config client signifiait que l’OS changerait de résolveur de façon fiable. Sur certains portables Linux, wg-quick ne pouvait pas parler à la configuration résolveur locale. Sur Windows, l’adaptateur avait le DNS configuré, mais la résolution préférait toujours le DNS Wi‑Fi parce que la métrique d’interface avait basculé après une mise à jour de pilote.
Ils ont fixé en rendant la sélection DNS explicite : configuration per-link systemd-resolved sur Linux, règles NRPT sur Windows pour les namespaces internes. Le postmortem n’était pas à propos de WireGuard ; il portait sur « on a testé la connectivité mais pas la résolution de noms comme une application ». C’est la vraie leçon. Les applis ne se connectent pas aux IPs que vous collez dans Slack ; elles se connectent à des noms.
Mini-histoire 2 : L’optimisation qui s’est retournée contre eux
Une équipe de sécurité voulait réduire les fuites DNS. Objectif raisonnable. Ils ont décidé : « forcer tout le DNS via le VPN ». Ils ont pointé tous les clients vers un résolveur récursif d’entreprise accessible uniquement à l’intérieur du tunnel, et estimaient la tâche terminée.
Le premier problème : la latence. Le personnel distant envoyait maintenant chaque requête DNS à travers le tunnel vers un résolveur qui n’était pas adapté aux utilisateurs globaux. La navigation devenait lente, parce que les pages modernes déclenchent un petit défilé de recherches DNS. Le deuxième problème : la fiabilité. Le résolveur faisait du filtrage occasionnel, et quand il était lent, tout était lent.
Puis le vrai retour de bâton : certains flux d’authentification SaaS ont cassé de façon intermittente. Pas parce que le SaaS était down, mais parce que le filtrage et le cache du résolveur d’entreprise ne correspondaient pas au DNS public. Quelques CDN de bord renvoyaient des réponses différentes, et les applis se comportaient autrement. L’équipe avait « optimisé » pour empêcher les fuites et créé un point de défaillance unique pour toute l’expérience de navigation.
La solution fut plus ennuyeuse : split DNS pour les zones internes, plus des règles d’egress sensées pour prévenir les fuites DNS (bloquer UDP/53 direct vers Internet sur les machines gérées quand approprié, tout en autorisant des politiques DoH pour le public). Le résolveur d’entreprise est resté en boucle uniquement pour les domaines qu’il possédait réellement. Les utilisateurs ont cessé de se plaindre, et l’équipe sécurité a obtenu le contrôle souhaité — sans transformer le DNS en goulot d’étranglement.
Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
Une autre organisation a fait quelque chose d’inespéré : elle a écrit un « contrat DNS VPN » d’une page. Il spécifiait : namespaces internes, résolveurs autoritatifs, comportement de récursion, tailles de réponse attendues, et exactement comment les clients Linux et Windows devaient router ces requêtes quand connectés. Pas de vagues. Pas de « devrait ».
Lors du déploiement de WireGuard, ils n’ont pas seulement livré des configs. Ils ont livré des tests. Un petit script validait : tunnel up, route vers le serveur DNS via wg, dig @dns direct fonctionne, le résolveur système utilise le bon serveur pour les domaines corp, et la capture montre aucune fuite pour les domaines internes.
Des mois plus tard, un changement réseau a introduit une nouvelle zone interne avec des réponses DNS plus volumineuses. Certains utilisateurs ont commencé à voir des échecs intermittents pour cette zone seulement. Parce qu’ils avaient un contrat et une suite de tests, l’astreinte a rapidement reproduit et localisé le problème : fragmentation. Le MTU était acceptable pour la plupart du trafic mais limite pour les réponses EDNS volumineuses.
La résolution fut mécanique : ajuster le MTU et, pour les résolveurs internes, affiner le comportement de réponse pour éviter des réponses UDP surdimensionnées quand possible. La « pratique ennuyeuse » n’était pas le tweak MTU — c’était le fait qu’ils pouvaient détecter et localiser la panne en minutes. Pas d’héroïsme. Pas d’alerte générale. Juste du comportement disciplinaire et observable.
Checklists / plan pas à pas
Checklist A: Full-tunnel DNS qui fonctionne réellement (Linux + Windows)
- Choisissez un serveur DNS VPN joignable depuis le sous-réseau du tunnel et qui autorise la récursion depuis celui-ci.
- Ajoutez l’IP du serveur DNS à AllowedIPs (au moins en /32) pour que le routage soit déterministe.
- Linux :
- Si vous utilisez systemd-resolved, définissez le DNS du lien wg via resolvectl dns wg0 … et assurez-vous qu’il peut être utilisé comme défaut.
- Si vous n’utilisez pas resolved, assurez-vous que resolvconf existe ou gérez /etc/resolv.conf explicitement.
- Windows :
- Définissez le DNS de l’adaptateur WireGuard dans le profil du tunnel.
- Assurez-vous que la métrique d’interface préfère WireGuard si vous voulez qu’il soit le défaut.
- Vérifiez par capture que les requêtes DNS entrent dans le tunnel.
- Vérifiez avec Resolve-DnsName / getent que les applis voient les bons résultats.
Checklist B: Split DNS pour les zones d’entreprise (recommandé)
- Identifiez les namespaces internes (corp, internal.corp, etc.). Soyez explicite.
- Linux : configurez les domaines de routage systemd-resolved sur wg0 :
- resolvectl dns wg0 10.50.0.53
- resolvectl domain wg0 ~corp (et namespaces additionnels selon besoin)
- Windows : créez des règles NRPT par namespace :
- Add-DnsClientNrptRule -Namespace ‘.corp’ -NameServers ‘10.50.0.53’
- Gardez le DNS public sur le réseau local ou un résolveur public dédié, pas sur le résolveur interne d’entreprise.
- Test :
- Le nom interne se résout via le DNS VPN.
- Le nom public se résout sans passer par le VPN (à moins que vous ne vouliez l’inverse).
Checklist C: Quand « DNS ne fonctionne pas » est en fait MTU
- Reproduisez avec un enregistrement « gros » (TXT, DNSSEC, ou un nom interne avec beaucoup d’enregistrements A/AAAA).
- Capturez les paquets DNS et cherchez des réponses manquantes ou des fragments.
- Réduisez le MTU sur l’interface wg (essayez 1380) et retestez.
- Si la réduction du MTU règle le problème, conservez la valeur inférieure et documentez la raison. Vérifiez aussi le chemin MTU en amont si possible.
FAQ
1) Pourquoi WireGuard se connecte mais le DNS échoue ?
Parce que le tunnel peut être sain alors que votre OS continue d’utiliser les anciens serveurs DNS, ou route les requêtes DNS hors du tunnel. WireGuard n’« hérite » pas du DNS ; il ne fait que déplacer des paquets.
2) Est-ce que DNS= dans wg-quick suffit ?
Parfois. Ça dépend si votre système dispose des outils d’intégration du résolveur que wg-quick attend. Sur les systèmes systemd-resolved, des hooks resolvectl explicites sont plus déterministes.
3) Pourquoi dig @10.50.0.53 marche mais les résolutions normales échouent ?
Parce que dig @IP contourne la sélection du résolveur OS et les bizarreries de routage. Votre résolveur système pointe toujours ailleurs, ou applique des règles de split DNS que vous n’aviez pas prévues.
4) Dois-je ajouter l’IP du serveur DNS à AllowedIPs ?
Si le serveur DNS se trouve derrière le tunnel, oui. Ajoutez-le explicitement en /32 si nécessaire. Autrement, votre système peut tenter de l’atteindre via la route par défaut et timeouter.
5) Quelle est la manière la plus propre de faire du split DNS sur Linux ?
Les domaines de routage systemd-resolved : définissez le DNS sur wg0 et assignez les domaines ~corp à celui-ci. Cela évite les changements DNS globaux et garde la résolution externe locale.
6) Quelle est la manière la plus propre de faire du split DNS sur Windows ?
Les règles NRPT par namespace. Elles forcent le serveur DNS pour ces domaines, indépendamment des métriques d’interface ou des reconnexions Wi‑Fi.
7) Pourquoi certaines applis fuient-elles encore le DNS même si j’ai configuré le DNS VPN ?
Certaines applis utilisent DNS-over-HTTPS ou des résolveurs personnalisés et contournent les réglages DNS du système. Corriger cela relève de la gestion des politiques applicatives, pas de la configuration WireGuard.
8) Comment savoir si les requêtes DNS sortent en dehors du tunnel ?
Capturez les paquets sur les deux interfaces. Si vous voyez UDP/53 sur Wi‑Fi/eth0 au lieu de wg0, c’est du routage/politique. N’improvisez pas ; observez.
9) Pourquoi le DNS est-il plus lent sur le VPN même quand il « marche » ?
Latence, emplacement du résolveur et comportement de cache. Un résolveur d’entreprise loin des utilisateurs transforme chaque page web en taxe de latence. Le split DNS réduit cette taxe.
10) Dois-je exécuter un résolveur cache local sur le client ?
Ça peut aider la performance, mais ajoute une couche qui peut mettre en cache un mauvais choix upstream. Si vous le faites, configurez soigneusement la sélection upstream et testez le comportement du split DNS.
Conclusion : prochaines étapes qui tiennent
Si vous êtes coincé dans « DNS WireGuard ne fonctionne pas », arrêtez de tripoter des boutons au hasard et suivez un chemin discipliné :
- Prouvez d’abord la connectivité L3. Handshake et joignabilité IP vers le serveur DNS sont vos faits de base.
- Observez où les paquets DNS vont. La capture mettra fin aux débats instantanément.
- Rendez la sélection DNS déterministe. Sur Linux, préférez systemd-resolved per-link DNS avec domaines de routage pour le split DNS. Sur Windows, utilisez NRPT pour le split DNS et les métriques uniquement si vous voulez vraiment « tout par défaut ».
- Routez le serveur DNS via le tunnel. Incluez-le dans AllowedIPs pour éviter qu’il ne rebondisse par la gateway locale par accident.
- Documentez le comportement attendu. Full-tunnel DNS et split DNS sont des produits différents. Choisissez-en un et écrivez-le.
Faites cela, et le DNS cessera d’être « mystérieusement cassé ». Il deviendra un système avec des entrées, des sorties et une trace papier. Ce genre de magie est la seule tolérable pour les équipes d’opérations.