Test de fuite DNS : un nom de résolveur n'est pas la route

Trois dispositions comptent comme un DNS correct pour un utilisateur de VPN : des requêtes vers le résolveur de l'opérateur, des requêtes vers un résolveur chiffré que vous avez choisi, et un DNS divisé qui envoie les noms de travail vers l'organisation. Un test de fuite signale un résolveur, et cette unique étiquette ne peut pas vous dire quelle disposition vous avez réellement. Décidez d'abord la politique visée, puis testez par rapport à elle. Sinon, vous comparez un nombre à une impression.

Décidez ce que vous vouliez avant de lire le résultat

Nommez la politique en une phrase : tous les noms vers le résolveur du VPN, tous les noms vers un résolveur chiffré choisi, ou un DNS divisé avec les noms internes allant vers l'organisation. Chacune se défend pour un utilisateur différent, et chacune produit une réponse attendue différente. Sans cette phrase, tout résultat qui diffère d'une capture d'écran dans un message de forum paraît alarmant. Écrivez la politique avant le premier test.

Un test effectué avant que la politique soit définie ne mesure rien. Il produit un nom de résolveur sans aucun point de référence.

Un nom de résolveur ne prouve ni le chemin ni le destinataire

Deux questions comptent : qui a reçu la requête, et quelle route l'a portée. Un résolveur tiers peut être joignable par le tunnel alors qu'un écran de réglages affiche l'adresse du fournisseur. L'étiquette d'une page de test de fuite décrit le point de vue de l'observateur, pas votre table de routage.

Un navigateur peut utiliser son propre DNS chiffré pendant que le trafic du site passe par le tunnel, et des réponses en cache peuvent permettre le chargement d'une page sans nouvelle requête. C'est pourquoi un résultat d'IP publique ne dit rien du DNS. DoH et DoT protègent la requête sur le trajet vers le résolveur, et ce résolveur voit toujours les noms.

resolvectl status
resolvectl query example.com
dig +short example.com

Le DNS divisé rend plusieurs résolveurs corrects

Une organisation peut envoyer les noms internes vers son propre DNS et tout le reste ailleurs. Un test qui liste plusieurs résolveurs peut donc décrire la politique visée plutôt qu'une panne. Comparez l'ensemble observé aux règles de DNS divisé documentées avant de désactiver quoi que ce soit. Éteindre le résolveur interne pour qu'une page de test paraisse plus propre casse les noms privés.

Le tunneling divisé et le DNS divisé sont des choix différents : l'un route des paquets, l'autre route des questions. Changer une route de tunnel ne déplace pas une recherche de nom, et changer le résolveur ne répare pas le chemin d'un site web. IPv6 est une troisième question, car une connexion IPv6 non voulue n'est pas automatiquement une fuite DNS.

Transformez le résultat en enquête

Notez la politique visée et le réglage de DNS sécurisé du navigateur avant de tester. Lancez le test avec le tunnel actif, notez chaque résolveur qu'il cite et comparez l'ensemble à la politique plutôt qu'à une seule adresse attendue.

Répétez après une reconnexion si c'est là que le symptôme apparaît, car une politique appliquée à la connexion peut se perdre ensuite. Utilisez la documentation du client pour les exceptions DNS internes au lieu de deviner les réglages.

Corrigez l'écart que vous avez trouvé : un choix de navigateur, un réglage DNS du VPN ou une règle de DNS divisé. Si les requêtes doivent cesser quand le tunnel tombe, le kill switch est un réglage distinct, et la configuration DNS seule ne le fournira pas. La spécification RFC 8484 est utile quand il faut expliquer ce qu'un résolveur chiffré masque et ce qu'il ne masque pas.