Split DNS WireGuard sur macOS : domaines de recherche et résolveurs

Pourquoi ton Mac envoie chaque nom au tunnel WireGuard, ce qui distingue domaines de recherche et résolveurs par domaine, et comment vérifier ce que fait macOS.

Sur un Mac, une configuration WireGuard dont la ligne DNS = nomme un serveur envoie en général chaque résolution de nom à ce serveur tant que le tunnel est actif : les noms du réseau distant, et tout le reste. Le split DNS est l’alternative. Un résolveur est choisi pour certains domaines, et tous les autres noms gardent le DNS que tu utilises d’habitude. Les domaines de recherche sont un troisième mécanisme, distinct : ils complètent les noms courts, et ils ne choisissent pas de résolveur. Distinguer les trois explique la plupart des symptômes que l’on rencontre.

Ce guide couvre macOS et les réseaux IPv4.

État de l’app officielle au 7 octobre 2026 : l’app WireGuard pour macOS publiée est la version 1.0.16, et elle n’a aucun réglage DNS par domaine. Un correctif ajoutant un split DNS sur option (opt-in) a été proposé en amont, mais notre vérification n’a trouvé ni fusion en amont ni version publiée qui le contienne. Voir le code source de l’app officielle et sa fiche sur l’App Store pour macOS.

Le problème : un seul résolveur pour toute la machine

Les exemples ci-dessous utilisent des noms et des adresses fictifs. Un réseau distant a un serveur DNS en 10.20.0.53, le seul serveur qui connaisse server.corp.example.com. Ton propre réseau, 192.168.50.0/24, a des noms que seul le DNS de ton routeur connaît : une imprimante, un NAS.

Avec un seul résolveur pour tous les noms, l’un de ces deux ensembles échoue. Pointe tout vers 10.20.0.53 et tes noms locaux cessent de se résoudre, tandis que toutes les autres requêtes font un détour par le réseau distant. Garde le DNS de ton routeur et server.corp.example.com ne se résout jamais, alors même que 10.20.0.20, l’adresse derrière ce nom, est parfaitement joignable.

Dans l’app WireGuard officielle

Une configuration comme celle-ci est courante :

[Interface]
DNS = 10.20.0.53, corp.example.com

Les réglages réseau de l’app la lisent ainsi :

10.20.0.53, une adresse, devient le serveur DNS du tunnel.
corp.example.com, ou toute autre entrée qui n’est pas une adresse, devient l’un des domaines de recherche du tunnel.
Dès qu’au moins un serveur est indiqué, l’app définit la liste des domaines de correspondance (match domains) du tunnel comme une seule entrée vide. Selon le commentaire du code source, toutes les requêtes DNS doivent d’abord passer par le DNS du tunnel.

L’app publiée n’a aucun réglage pour n’envoyer que certains domaines au DNS du tunnel. Le domaine de recherche ne restreint rien : il complète les noms, tandis que chaque requête part toujours d’abord vers 10.20.0.53.

Avec wg-quick sur macOS

wg-quick, de wireguard-tools, sépare la même ligne en adresses de serveurs et en domaines de recherche. Son script pour macOS agit ensuite sur toute la machine, et non sur une interface de tunnel :

Si au moins une adresse de serveur est indiquée, il applique ces serveurs et ces domaines de recherche à chaque service réseau listé par networksetup, en remplaçant leurs valeurs existantes. Si la ligne n’a aucun domaine de recherche, il efface ceux des services.
Tant que le tunnel est actif, il réapplique ces réglages quand la table de routage change.
Quand le tunnel s’arrête, il restaure les valeurs qu’il avait relevées avant de les modifier.
Une ligne DNS = avec des domaines de recherche mais sans adresse de serveur ne modifie aucun réglage DNS.

C’est une modification DNS de toute la machine, pas du split DNS.

Un domaine de recherche ne sélectionne pas le résolveur

Ce que fait un domaine de recherche

Un domaine de recherche permet d’essayer un nom court avec un suffixe : server peut être cherché sous la forme server.corp.example.com. Il aide à compléter et à rechercher des noms. Il ne décide pas quel serveur DNS répond pour corp.example.com.

Cela concorde avec les témoignages de domaines de recherche qui « ne font que compléter les noms » : compléter le nom est tout le travail d’un domaine de recherche. Le résolveur qui a reçu le nom complété devait de toute façon le connaître.

Ce que fait le split DNS

Le split DNS choisit un résolveur pour un domaine. Les requêtes pour les noms sous corp.example.com vont à 10.20.0.53 ; tous les autres noms restent sur le résolveur que tu utilises d’habitude. Le domaine qui sélectionne le résolveur est souvent appelé domaine de correspondance (match domain).

Un client peut tirer ses domaines de correspondance et ses domaines de recherche de la même liste, mais ce sont toujours deux mécanismes. L’un réécrit un nom court ; l’autre choisit le serveur qui répond pour un domaine. Une configuration peut avoir l’un sans l’autre.

Ce n’est pas la même chose que le tunnel partiel

Le tunnel partiel (split tunneling) décide quelles adresses passent par le tunnel : c’est AllowedIPs. Le split DNS décide quel résolveur répond à un nom. Il te faut souvent les deux, et ils dépendent l’un de l’autre : le serveur DNS distant doit lui-même être routé par le tunnel. Dans l’exemple, AllowedIPs doit couvrir 10.20.0.53 aussi bien que 10.20.0.20. Voir DNS, routage et tunnel partiel pour la moitié routage.

Tes options sur macOS

Approche	Ce qu’elle change	Ce qu’elle ne fait pas
Garder le comportement de l’app officielle	Pendant la connexion, chaque requête va d’abord au serveur DNS du tunnel	Les noms que seul le DNS de ton propre réseau connaît peuvent cesser de se résoudre
Cocher « Exclure les IPs privées » dans l’app officielle	Le routage : les plages IPv4 privées sortent d’un tunnel complet	Elle ne choisit pas de résolveur par domaine ; les réglages DNS restent les mêmes
Ajouter un fichier de résolveur dans `/etc/resolver`	Une configuration de résolveur pour un domaine, qui nomme le serveur que tu choisis	Il n’est pas lié au tunnel, et son interaction avec l’app officielle pendant la connexion n’est pas établie
Utiliser `wg-quick`	Le DNS de toute la machine tant que le tunnel est actif, restauré ensuite	Aucun résolveur par domaine ; des scripts peuvent en ajouter un, et leur nettoyage est alors à ta charge
Utiliser un client qui sélectionne les résolveurs par domaine	Seuls les domaines déclarés utilisent le résolveur distant	Vérifie comment il traite les domaines de recherche, et ce que deviennent les noms quand le tunnel s’arrête

Résolveurs par domaine avec /etc/resolver

La page de manuel de ton Mac, man 5 resolver, décrit des fichiers de configuration de résolveur propres à un domaine, lus dans /etc/resolver. Pour un fichier de ce répertoire, le nom du fichier sert de nom de domaine, et le mot-clé nameserver donne l’adresse d’un serveur de noms que le résolveur doit interroger. La page décrit des requêtes acheminées vers la configuration dont le domaine correspond le mieux au nom. Pour l’exemple, un fichier nommé /etc/resolver/corp.example.com contiendrait :

nameserver 10.20.0.53

La même page documente port et les autres mots-clés. Elle indique aussi que des configurations de résolveur peuvent provenir d’autres sources, comme la base System Configuration, et que les utilisateurs ne doivent faire aucune supposition sur l’origine de la configuration.

Connais ses limites avant de t’y fier :

Créer le fichier demande des droits d’administrateur.
Le fichier reste en place, que le tunnel soit actif ou non. Rien ne le retire quand le tunnel s’arrête : il nomme toujours 10.20.0.53 pour ce domaine, un serveur qui n’est peut-être joignable que par le tunnel.
C’est un mécanisme de macOS, pas un réglage WireGuard. Son interaction avec l’app WireGuard officielle pendant que celle-ci est connectée n’a pas été établie ici : l’app envoie d’abord chaque requête au DNS du tunnel. Ne suppose pas que l’un l’emporte sur l’autre ; vérifie le résultat avec scutil --dns et une vraie résolution, comme décrit plus bas.

Ce que change « Exclure les IPs privées »

Dans l’app officielle pour macOS, cette case (« Exclude private IPs » dans l’app en anglais) apparaît dans l’éditeur de tunnel quand la configuration a un seul pair dont AllowedIPs couvre toutes les adresses IPv4 (0.0.0.0/0).

La cocher réécrit AllowedIPs :

0.0.0.0/0 est remplacé par une liste fixe que le code source décrit comme toutes les adresses IPv4 non privées. Elle laisse de côté les plages privées 10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16.
Les adresses des serveurs DNS de la configuration sont ajoutées, pour qu’elles restent dans le tunnel.
Toute autre entrée IPv4 de cet AllowedIPs est remplacée elle aussi.

Les adresses privées passent alors par ta connexion normale. Ton réseau local devient joignable hors du tunnel. Les réseaux privés distants sortent aussi du tunnel : à part les adresses des serveurs DNS ajoutées, ils ne sont plus atteints par lui.

L’option ne change que les routes. Les réglages DNS restent tels qu’ils étaient, et les requêtes vont toujours d’abord au serveur DNS du tunnel. Elle ne sélectionne pas de résolveur par domaine.

Vérifier ce que macOS utilise vraiment

Trois commandes répondent à trois questions différentes. Remplace les noms et les adresses fictifs par les tiens. Elles lisent la configuration ou effectuent des résolutions ; elles ne modifient aucun réglage.

Lire la configuration des résolveurs

scutil --dns

Cette commande répond à la question : quels résolveurs macOS a-t-il reçus, et pour quels domaines ? Cherche le serveur DNS du tunnel, le domaine rattaché à chaque résolveur, les domaines de recherche, et l’interface à laquelle chaque résolveur est limité (scoped). Un résolveur sans domaine et un résolveur pour corp.example.com jouent des rôles différents. Le premier résolveur listé n’est pas forcément celui utilisé pour chaque requête.

scutil --dns montre la configuration, pas le résultat d’une résolution.

Résoudre par le système

dscacheutil -q host -a name server.corp.example.com

Cette commande répond à la question : que renvoie macOS quand on lui demande ce nom par ses appels de résolution standard ? Sa page de manuel, man dscacheutil, indique qu’il lance une requête à l’aide des appels standard, et que le résultat peut venir d’un cache. La commande montre l’adresse que renvoie le système, pas le serveur DNS qui l’a fournie. Utilise le nom complet (FQDN), et compare l’adresse renvoyée à celle que tu attends.

Interroger directement un serveur

dig @10.20.0.53 server.corp.example.com

Cette commande répond à la question : ce serveur connaît-il le nom, et peux-tu le joindre ? dig @server envoie la requête directement au serveur que tu nommes et contourne la sélection du résolveur par le système. Une réponse correcte prouve que le serveur fonctionne et qu’il est joignable. Elle ne prouve pas que macOS choisira ce serveur pour ce nom.

Tester avec la vraie application

Ouvre le service par son nom complet, par exemple https://server.corp.example.com/. Cela vérifie aussi le certificat HTTPS, qui n’est valide que sur le vrai nom d’hôte. Une application qui utilise son propre mécanisme DNS peut se comporter autrement que le résolveur système. Des réponses en cache peuvent masquer un changement : après avoir modifié un réglage, teste à nouveau avec des noms dont tu connais la réponse attendue.

Pièges courants

Symptôme	Ce qu’il faut vérifier
Seul le nom court échoue	Le domaine de recherche : absent, ou non appliqué par ton client. Teste le nom complet
Le nom complet échoue, l’adresse répond	Les résolveurs et leurs domaines dans `scutil --dns` ; ce que le système renvoie avec `dscacheutil`
Tous les noms passent par le tunnel	Le DNS universel (catch-all) de l’app officielle, ou les réglages de `wg-quick` pour toute la machine
Les noms locaux ne se résolvent plus une fois connecté	Un résolveur distant qui répond pour tout ; voir les options ci-dessus
`dig @10.20.0.53` répond, le navigateur non	`dig` a contourné la sélection du résolveur par le système ; lis `scutil --dns`, et compare avec ce que renvoie `dscacheutil`
Aucune réponse du serveur DNS distant	Son adresse dans `AllowedIPs` ; voir DNS, routage et tunnel partiel
Les noms échouent après l’arrêt du tunnel	Des réglages non restaurés, ou un fichier resté dans `/etc/resolver`
Un nom en `.local` ne se résout pas par le DNS	Le DNS multicast de Bonjour utilise ce suffixe, et Apple a documenté des échecs de résolution pour les noms DNS unicast qui se terminent par `.local`

Si rien ne répond, même par adresse, le problème vient du tunnel lui-même : voir Quand le tunnel ne se connecte pas.

Pourquoi cela compte dès que plusieurs réseaux sont connectés

Avec deux réseaux distants qui ont chacun leur propre serveur DNS, un seul résolveur a tort pour l’un d’eux : aucun des deux serveurs ne connaît les noms de l’autre réseau. Plusieurs clients VPN qui modifient chacun les réglages DNS de la machine peuvent aussi se gêner mutuellement, en particulier quand l’un d’eux s’arrête. Pour deux tunnels WireGuard à la fois, routes et DNS ensemble, voir Plusieurs tunnels WireGuard sur macOS.

Utiliser Paart pour le split DNS

Paart Client est l’un des clients WireGuard qui sélectionnent un résolveur par domaine. Son split DNS fonctionne avec des noms internes que tu déclares pour chaque connexion.

Ce que font les noms internes

Rien n’est séparé tant que tu n’as pas dit quels noms appartiennent au réseau distant. Dans le détail de la connexion, ouvre Names et choisis Add an internal name : int.example.com, par exemple. Ces noms, et eux seuls, sont résolus par le tunnel. Tous les autres gardent le DNS de cet appareil :

int.example.com passe par le tunnel jusqu’au résolveur distant, 10.0.99.10 ;
google.com va au DNS du Wi-Fi sur lequel tu es.

Sauf si tu choisis un résolveur de remplacement dans Settings › Resolvers : c’est alors ce résolveur qui répond à tous les autres noms.

La rangée Look up with, en tête de Names, dit où les noms internes sont cherchés. Laissée vide, c’est le DNS de la configuration. Sans aucun nom interne, rien n’est séparé : le résolveur choisi sous DNS répond à chaque nom. Sur macOS, Paart rattache les noms internes au résolveur choisi en tant que domaines de correspondance (match domains).

Les noms internes sélectionnent un résolveur ; ce ne sont pas des domaines de recherche. Paart n’applique pas les domaines de recherche de la ligne DNS = d’une configuration : ils sont écartés à l’import, et l’import le signale. Utilise des noms complets, comme server.int.example.com.

Les noms internes sont disponibles sur Mac, iPhone et iPad. Ils font partie du réseau avancé : en gratuit, ils fonctionnent sur ta connexion gratuite, et sur les autres ils viennent avec Paart Pro.

Sources techniques

Analyseur de configuration de wireguard-apple — comment le client officiel sépare DNS = en serveurs et en domaines de recherche.
Réglages réseau de wireguard-apple — serveurs DNS, domaines de recherche et domaine de correspondance universel dans le client officiel.
Modèle de tunnel de wireguard-apple — ce que fait « Exclure les IPs privées » à AllowedIPs.
Référence de wg-quick et source pour Darwin — comment wg-quick règle et restaure le DNS sur macOS. La source pour Darwin est la référence propre à la plateforme.
man 5 resolver et man dscacheutil, sur ton Mac — fichiers de résolveur par domaine dans /etc/resolver, et résolutions par les appels standard du système.
Assistance Apple : domaines qui se terminent par .local — l’usage du suffixe par Bonjour, et les noms DNS unicast qui peuvent ne pas se résoudre. Apple a archivé cet article.
Historique de wireguard-apple et proposition de correctif incluant un split DNS sur option — distinguer une proposition, une fusion en amont et une app publiée.

Revue des sources : 7 octobre 2026. L’app officielle et wg-quick sont décrits d’après leur code source en amont, et non d’après un test de chaque version de macOS.