Pourquoi une étiquette de pays DNS ne prouve pas une fuite VPN

Les adresses de résolveur à l’apparence étrangère apparaissent sans cesse dans les résultats de tests DNS, et la conclusion que l’on en tire est toujours la même : les requêtes ont dû s’échapper du tunnel. Parfois, c’est vrai. Plus souvent, le rapport décrit quel service récursif a répondu et où une base de données situe cette adresse, ce qui est une affirmation sur l’infrastructure, pas sur vos paquets. Séparer l’observation de l’inférence exige trois faits : qui a répondu, comment le nom a voyagé et quelle politique vous avez réellement configurée.

Lisez ce que le test a réellement observé

La plupart des pages de test fonctionnent de la même manière : elles demandent au client de résoudre un nom d’hôte unique, puis regardent quel résolveur l’a récupéré, ou elles renvoient simplement l’adresse de résolveur que le client signale. Cela identifie un service récursif et, si la requête portait des informations de sous-réseau client, une localisation réseau approximative. Cela ne prouve pas que la requête a quitté l’appareil hors du tunnel, et ne prouve certainement pas que le même chemin a été utilisé pour chaque nom. Une seule observation d’une recherche est généralisée en affirmation sur tout le trafic.

Un test qui affiche l’adresse du résolveur est plus utile qu’un badge de pays, car l’adresse peut être comparée à la liste de résolveurs que le client a réellement reçue.

Anycast et transfert expliquent la plupart des surprises

Les grands résolveurs publics annoncent la même adresse depuis de nombreux endroits, et le réseau achemine chaque requête vers le site le plus proche en termes de routage. Une base de géolocalisation associe ensuite cette adresse à un seul endroit, qui peut être une adresse d’enregistrement d’entreprise sur un autre continent ou un centre de données qui n’est pas celui qui répond. RFC 4786 couvre la pratique opérationnelle des services anycast et la difficulté d’associer une telle adresse à un lieu physique unique. La carte est une simplification d’une décision de routage, et elle simplifie dans la direction qui produit des résultats alarmants.

Le transfert ajoute une seconde couche. Un résolveur stub local, un routeur ou le résolveur d’un fournisseur d’accès peuvent transmettre les requêtes à un service en amont, et le nom qui apparaît dans le test reflète le dernier opérateur de cette chaîne plutôt que le premier. Les extensions de sous-réseau client peuvent rendre une réponse amont adaptée à votre réseau tout en faisant paraître l’emplacement signalé comme un endroit où vous n’avez jamais mis les pieds.

Un résolveur configuré peut donc être correct et produire malgré tout un résultat d’apparence étrangère, et un résolveur de votre propre pays peut être le mauvais parce qu’il appartient à une partie que vous n’avez pas choisie.

Qui a reçu le nom, et par quelle route

Deux questions répondent à la partie pratique : quel serveur le client utilise-t-il, et ce serveur est-il atteint par le tunnel. Comparez la liste de résolveurs avec l’adresse du résultat du test avant de tirer des conclusions sur le routage, puis vérifiez que la requête vers cette adresse sort par l’interface du tunnel. Si les deux adresses diffèrent, la découverte intéressante est que quelque chose a réécrit ou contourné le résolveur prévu, ce qui mérite un examen plus attentif que le nom du pays.

resolvectl query example.com
resolvectl status | grep -A3 'DNS Servers'
dig +short TXT whoami.akamai.net

La première commande montre quel serveur a répondu pour un nom, la seconde montre la liste configurée et sa portée, et la troisième rapporte l’adresse du résolveur telle qu’un service public la voit. Quand les trois concordent, la politique fait ce pour quoi elle a été configurée, quoi que dise l’étiquette de pays.

Comparez avec la politique que vous avez choisie

Un VPN qui impose un résolveur, un navigateur configuré pour utiliser son propre DNS chiffré et un système d’exploitation qui préfère les paramètres d’une interface peuvent être corrects séparément tout en se contredisant ensemble. Les navigateurs modernes peuvent envoyer des requêtes via un transport chiffré à un fournisseur choisi dans le navigateur, ce qui contourne délibérément la liste de résolveurs du système. Ce n’est pas une fuite au sens d’un tunnel cassé ; c’est une politique choisie ailleurs, et trouver où elle a été choisie est la véritable tâche.

Les appareils professionnels ajoutent des règles par domaine : les noms internes doivent aller au résolveur de l’organisation tandis que tout le reste suit la valeur par défaut. Remplacer cette organisation parce qu’une page de test a montré un pays inattendu, c’est ainsi que les noms internes cessent de se résoudre pour toute une équipe.

Gardez les tests étroits et sûrs

Interroger un service de test public sur un nom d’hôte interne révèle le nom à une partie qui n’a rien à en faire, et la réponse ne vous apprend rien que la lecture locale de la liste de résolveurs n’apprendrait.

Utilisez plutôt des noms qui révèlent l’infrastructure, consignez l’adresse du résolveur, la portée et l’interface utilisée, et comparez cette trace à l’intention documentée. Une étiquette de carte est un contexte pour une conversation et non un résultat réussi ou échoué, et la traiter comme un verdict produit des changements de configuration au lieu d’un diagnostic.