Votre VPN pousse trois serveurs DNS : lequel répond ?

Ouvrez la page des réglages après la connexion : trois adresses DNS y figurent ; la question de l’audit est de savoir laquelle a traité votre dernière requête. Le nombre seul ne répond à rien, car une poussée du client, une interface physique et une politique par domaine écrivent tous dans la même vue. Ces entrées portent des portées différentes, et c’est la portée, non la position, qui décide qui répond. Commencez par séparer les sources, puis testez celle qui possède le nom qui vous intéresse.

Pourquoi la liste est plus longue que votre profil

Un client VPN pousse des adresses de résolveur pour le lien du tunnel, et le système d’exploitation les conserve à côté de ce que l’interface physique avait déjà. Un routeur, un bail DHCP d’entreprise, un second VPN et une politique par domaine apportent chacun leur propre entrée. Trois adresses sur la page peuvent donc signifier trois portées plutôt que trois candidats pour une tâche. Lire le nombre comme la preuve d’une fuite est la première erreur de cet audit.

Au sein d’une interface, un client essaie bien ses serveurs dans l’ordre, donc une liste ordonnée n’est pas dénuée de sens. Ce qui n’est pas une file, c’est la vue fusionnée, où les entrées du profil, du lien physique et des règles par domaine voisinent sans classement unique. Cette distinction décide de ce que vous testez : l’ordre explique le comportement dans une portée, et la portée explique tout le reste.

Le DNS chiffré casse le tableau depuis l’intérieur d’une application. Un navigateur ou un client de messagerie doté de son propre résolveur DNS-over-HTTPS envoie des requêtes complètement en dehors de la liste du système d’exploitation, si bien que les adresses de la page des réglages décrivent un trafic que l’application n’a jamais produit. Vérifiez le réglage de résolveur de l’application avant d’accuser le profil pour un nom mal résolu.

Ce que dit chacun des trois contrôles

Chaque source laisse sa marque à un endroit différent, et aucune commande unique ne les montre toutes. Voici la correspondance à garder à côté de la page des réglages :

Sur un système utilisant systemd-resolved, resolvectl status fait autorité, car elle rapporte le DNS par lien avec les domaines de routage. macOS répond via scutil --dns, qui liste les résolveurs à portée dans l’ordre où ils sont essayés. Windows sépare les deux moitiés : Get-DnsClientServerAddress pour les serveurs par interface et Get-DnsClientNrptPolicy pour les règles de suffixe. Lancez la commande qui correspond au résolveur réellement utilisé, car une machine dotée d’un environnement de conteneurs et d’un résolveur de bureau peut en avoir plusieurs d’installés.

Un résolveur de secours qui ne peut pas répondre pour votre zone

Une seconde entrée existe généralement pour la disponibilité, et la disponibilité ne fonctionne que si le secours connaît les noms. Demandez à un résolveur public un nom d’hôte interne : il renvoie NXDOMAIN, ou une réponse générique issue d’un domaine de recherche sans rapport avec vous. Un basculement que personne n’a vérifié produit alors une panne au moment précis où il est nécessaire.

Le Split DNS existe pour éviter cela : les suffixes de l’entreprise vont à un résolveur qui détient la zone, et les noms publics restent sur le chemin par défaut. La conception est solide, et elle dépend de l’exhaustivité de la liste des suffixes. Microsoft documente la politique de résolveur par suffixe qui pilote cela sous Windows, et la même idée apparaît comme domaines de routage dans systemd-resolved et comme résolveurs à portée sous macOS.

Comparez les zones que le secours peut traiter avec les suffixes présents dans la politique. Cette comparaison trouve l’écart avant qu’un utilisateur signale qu’un site interne a cessé de se résoudre après un changement de tunnel.

Interrogez à travers la politique, pas à côté

Interrogez via le résolveur du système d’exploitation, car une requête directe à un serveur contourne la politique et ne rapporte que ce que ce serveur dirait. L’écart entre les deux réponses est tout l’enjeu :

resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53

Si la requête système renvoie une adresse privée tandis que la requête directe renvoie NXDOMAIN, la politique fonctionne et le secours est le point faible. Si les deux renvoient la même réponse publique, le nom est résolu hors de la portée prévue, et la liste des suffixes est l’endroit à examiner. Conservez les deux sorties, car un débat sur les résolveurs se règle plus vite avec deux lignes qu’avec une capture de la page des réglages.

Exercez ensuite le chemin de défaillance, car un secours que personne n’a testé est une supposition. Transformez le résolveur préféré en trou noir pour une requête et observez quelle adresse revient :

ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32

Supprimez cette route dès que la requête est terminée, sinon la personne suivante hérite d’un mystère. Si les noms internes se résolvent encore dans cette fenêtre, quelque chose hors de la portée prévue y a répondu. S’ils expirent au contraire, le secours manque ou il est correctement délimité, et le journal du résolveur vous dit lequel des deux c’était.

Décidez : conserver, délimiter ou supprimer

Conservez un second résolveur lorsqu’il répond à l’espace de noms dont vous avez besoin et reste joignable sous le profil. Délimitez-le lorsqu’il ne doit voir qu’un suffixe et rien d’autre, et supprimez-le lorsqu’il n’a ni portée ni objet documenté. Une entrée sans tâche est une fuite future sans bénéfice, et une valeur par défaut du fournisseur n’est pas un objet.

Consignez le résultat en quatre colonnes : suffixe, résolveur, interface et responsable. Cette ligne répond à la prochaine question d’audit plus vite que n’importe quelle capture, et elle survit à la mise à jour du client qui réordonne la liste en silence.