Le VPN a-t-il changé mon DNS ? Comparez avant et après

Vous connectez le tunnel, ouvrez un tableau de bord privé, et le nom se résout en une adresse que vous n’avez jamais vue. Ou l’inverse se produit : le navigateur continue de fonctionner tandis qu’un outil en ligne de commande ne résout soudain plus rien. Les deux résultats viennent du même changement, et on l’explique généralement par une phrase sur le VPN qui « utilise son propre DNS », ce qui n’est pas assez précis pour diagnostiquer ou vérifier. Deux questions se cachent dans cette phrase : quelles requêtes ce profil est-il censé prendre en charge, et votre machine les a-t-elle réellement envoyées au résolveur qu’on lui a fourni ? Les garder séparées est toute la méthode, car un test qui les mélange produit une réponse fausse et assurée dans les deux sens.

Pourquoi un profil fournit-il un résolveur

À l’intérieur d’un tunnel, les noms situés derrière l’extrémité distante se résolvent généralement en adresses qui n’existent que dans ce réseau. Une zone privée comme corp.internal n’a pas de délégation publique, donc le résolveur qui la traite doit être joignable depuis l’intérieur du tunnel. Le même mécanisme sert un second objectif : lorsque les requêtes sortiraient autrement par votre fournisseur d’accès, un résolveur du côté distant garde la requête dans le chemin chiffré. C’est pourquoi l’adresse du serveur DNS arrive comme une partie de la politique de la connexion et non comme un réglage global choisi une fois pour la machine.

L’adresse seule ne tranche rien. Un résolveur ne peut répondre que s’il existe une route vers lui, et la panne la plus courante est un résolveur joignable seulement tant que le tunnel est actif. Quand le tunnel tombe et que la politique reste, les requêtes vont vers une adresse sans chemin, et le symptôme est un délai d’attente dépassé plutôt qu’une erreur nette. Cette différence compte quand vous lisez le résultat de test suivant, car un délai dépassé envoie les gens vers des réglages de transport qui n’ont jamais été en cause.

Comparez les deux conceptions avant de comparer les réponses

Le tunnel complet et le DNS scindé produisent des attentes opposées, et ni l’un ni l’autre n’est un dysfonctionnement. Sous un tunnel complet, chaque requête peut passer au fournisseur ou au résolveur d’entreprise, donc des noms publics qui répondent différemment après connexion sont attendus. Sous DNS scindé, seuls les domaines listés vont au résolveur privé tandis que tout le reste reste local ; sous Windows la liste de domaines vit dans la Name Resolution Policy Table, sous macOS dans les domaines correspondants des réglages DNS, et sur un hôte systemd-resolved dans les domaines de routage par lien.

C’est la comparaison à faire d’abord, car elle décide de ce qui compte comme défaut. Avec DNS scindé, un nom public qui répond depuis un nouveau résolveur est ce qui mérite une enquête, tandis qu’un nom interne qui répond correctement est le système qui fait son travail. Avec un tunnel complet, l’anomalie est un nom public qui répond encore depuis le résolveur de votre fournisseur. La documentation de Microsoft sur la résolution de noms VPN décrit l’ordre Windows de ces règles, notamment la façon dont une entrée de politique correspondante est consultée avant les serveurs propres de l’adaptateur.

Il y a un troisième résolveur dans la pièce qu’il est facile d’oublier. Le DNS sécurisé du navigateur résout les noms de son côté et peut continuer à répondre après que le tunnel a changé la politique du système d’exploitation, si bien qu’une page qui charge prouve que le résolveur du navigateur a fonctionné, non que le profil a été appliqué. Si vous ne comparez que ce que montre le navigateur, vous testez la mauvaise couche la moitié du temps.

Enregistrez une ligne de base avec une seule variable

Changez le tunnel. Ne changez pas aussi le nom, l’outil ou le suffixe de recherche dans la même étape. Choisissez un nom que vous êtes autorisé à interroger, notez quelle application vous avez utilisée, et écrivez soit l’adresse revenue soit l’erreur exacte. Sous Windows, Get-DnsClientServerAddress -AddressFamily IPv4 affiche les serveurs par adaptateur et Get-DnsClientNrptPolicy affiche les entrées de politique ; sous Linux avec systemd-resolved, resolvectl status montre les serveurs DNS et les domaines de routage par lien ; sous macOS, scutil --dns affiche l’ordre des résolveurs que le système suivra réellement.

Connectez-vous ensuite par les contrôles habituels du client et répétez exactement les mêmes commandes. Conservez la première sortie plutôt qu’un souvenir de celle-ci, car la comparaison est tout l’enjeu et une seconde lecture prise après un vidage du cache est déjà une autre mesure. Si la ligne de base a été prise avec le navigateur au premier plan et que l’exécution après connexion se fait dans un terminal, vous comparez deux résolveurs, pas deux états d’un même résolveur.

Une requête explicite et une recherche d’application sont des tests différents

Interroger un serveur précis, avec nslookup name 10.20.0.1 ou dig @10.20.0.1 name, prouve une seule chose : que le serveur nommé répond quand vous pouvez l’atteindre. Cela contourne entièrement la logique de sélection, donc cela ne peut pas vous dire si le système aurait choisi ce serveur pour ce nom. Servez-vous-en pour vérifier que le résolveur attribué est joignable, et ne l’utilisez pas pour vérifier la politique.

Une recherche via le résolveur local exerce réellement la sélection. resolvectl query name parcourt les mêmes règles de domaines de routage et indique quel protocole a répondu, Resolve-DnsName sous Windows passe par la table de politique et le cache du client, et scutil --dns montre l’ordre qu’une recherche suivrait. Exécutez les deux types et gardez-les dans des colonnes séparées de vos notes. Une requête explicite réussie à côté d’une recherche d’application en échec est un problème de routage ou de sélection, pas un résolveur qui refuse de fonctionner.

Le cache se place entre vous et la réponse. Le système d’exploitation, le résolveur stub local, le navigateur et le cache négatif conservent tous des résultats, si bien qu’une recherche peut réussir sans qu’un seul paquet quitte la machine. Enregistrez le résultat avant de vider quoi que ce soit : ipconfig /flushdns, resolvectl flush-caches ou sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder sous macOS. Évitez la réinitialisation réseau large à ce stade, car elle détruit les preuves que vous collectez encore.

Ce que signifie la différence

Comparez les deux lignes enregistrées et classez le changement avant de toucher au moindre réglage.

Une ligne mérite d’être soulignée. Un nom qui se résout n’est pas un service qui fonctionne, et le succès DNS dit seulement qu’une adresse a été trouvée. Il ne dit rien du transfert, des règles de pare-feu ni de la possibilité que votre compte utilise le service, alors terminez en testant l’application réelle au lieu de supposer que la panne s’est retirée d’elle-même.

Restaurez la ligne de base et vérifiez-la

Déconnectez-vous par les contrôles propres au client au lieu de tuer le processus, puis relisez les trois mêmes commandes. Les serveurs par lien, les entrées de politique et la réponse pour votre nom de test devraient revenir à la ligne de base que vous aviez notée. Une entrée de politique qui subsiste après une déconnexion propre est un vrai défaut qu’il vaut la peine d’enregistrer, et c’est aussi pourquoi les modifications manuelles d’un fichier de résolveur généré sont une mauvaise habitude : le fichier est réécrit et la modification disparaît, ou la modification survit et fige un résolveur qui n’a plus de route.

Parcourez cette liste une fois, dans l’ordre. Décidez quelle conception le profil met en œuvre avant de juger un résultat. Gardez le nom, l’outil et le suffixe fixes sur les deux exécutions. Séparez la requête explicite de la recherche d’application. Lisez la politique effective, pas seulement la réponse. Videz les caches en dernier, une fois la comparaison écrite. Vérifiez avec l’application réelle, puis redémarrez une fois et confirmez que l’état déconnecté reste propre.