DNS du VPN ou DoH du navigateur : ce qu’un test de fuite ne peut pas vous dire

La page du test de fuite dit que votre DNS est correct, le badge du navigateur dit sécurisé, et le wiki interne ne se charge toujours pas. Les trois peuvent être vrais en même temps, car l’adresse d’un résolveur n’est pas la même chose que la politique qui l’a choisi ou que le chemin emprunté par la requête. Ce que les gens appellent une fuite DNS est en réalité une seule question : quel résolveur a reçu le nom, et ce choix était-il intentionnel ? Pour y voir clair, il faut trois vérifications, et seule la dernière implique de changer un réglage.

Mythe un : le badge nomme votre résolveur

Un test de fuite résout un nom de sonde et rapporte l’adresse qui a répondu. Il ne rapporte pas la politique qui a choisi ce résolveur, et lorsque la requête est enveloppée dans DNS sur HTTPS, un intermédiaire sur le chemin ne peut pas voir le nom du tout. Deux machines très différentes produisent le même badge rassurant : l’une où le VPN a poussé 10.8.0.1 et où le navigateur l’utilise, l’autre où le navigateur a ignoré la liste système et envoyé le nom à son propre fournisseur chiffré à travers le tunnel.

La distinction compte à l’instant où un nom privé échoue. Dans la première configuration, le résolveur du VPN répond pour la zone d’entreprise ; dans la seconde, le navigateur ne lui a jamais demandé, donc le nom d’hôte court ne se résout pas et la panne ressemble à un VPN cassé. La vérification n’est pas un autre test de fuite, c’est une requête sur un nom que seul un résolveur connaît.

Mythe deux : le navigateur quitte le tunnel

Le DNS choisit une adresse, le routage transporte la connexion, et ce sont deux couches distinctes. Une requête envoyée à un fournisseur DoH public reste du TCP port 443 vers une adresse routable. Si votre table de routage envoie la route par défaut dans le tunnel, cette requête passe elle aussi par le tunnel. La marque du résolveur ne décide pas du chemin.

Ce que le DoH du navigateur change, c’est le destinataire des noms. C’est une vraie décision de confidentialité et une vraie décision de politique, mais ce n’est pas un contournement du routage. Si votre exigence est que les noms restent chez l’opérateur du VPN, une requête chiffrée vers quelqu’un d’autre échoue à cette exigence tout en utilisant encore le tunnel pour la connexion réelle.

Mythe trois : chaque VPN supplante chaque navigateur

Le DNS sécurisé d’un navigateur a des modes, pas un interrupteur : désactivé, un fournisseur par défaut avec repli, un modèle personnalisé ou une politique imposée par le système d’exploitation ou l’organisation. C’est le cas de repli qui produit des rapports intermittents. Quand le point de terminaison chiffré est injoignable, le navigateur peut se rabattre sur le résolveur système, si bien que le même portable résout correctement un nom privé le lundi et pas le mardi.

En même temps, la plupart des clients VPN définissent le résolveur système à la connexion et restaurent le précédent à la déconnexion. Un navigateur qui garde un résolveur chiffré personnalisé n’observe pas du tout cette restauration. C’est pourquoi le même profil se comporte différemment sur deux portables et pourquoi resolv.conf semble correct alors que le navigateur demande encore à quelqu’un d’autre.

resolvectl status                 # per-link DNS servers and split-DNS domains
scutil --dns | head -30           # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1   # ask the VPN resolver directly

Exécutez-les pendant que vous êtes connecté, notez quels domaines chaque résolveur revendique, et comparez avec ce que le navigateur rapporte sur son propre mode. La documentation DoH de Mozilla est une description raisonnable du fonctionnement attendu des comportements par défaut et de repli d’un navigateur.

La décision a trois entrées, pas une

Les noms privés, la confiance dans l’opérateur et l’accessibilité décident de la bonne disposition. Les noms que seul le résolveur du VPN connaît imposent un DNS scindé : le suffixe privé va au résolveur poussé, tout le reste suit la politique que vous avez choisie pour les noms publics. La confiance dans l’opérateur décide si les noms publics doivent aussi aller à ce résolveur ou à un service séparé. L’accessibilité décide si le résolveur chiffré choisi est même utilisable sur ce réseau.

Aucune de ces lignes n’est une recommandation universelle. Un résolveur exploité par le VPN concentre les observations chez cet opérateur ; un service séparé ajoute un destinataire de plus aux noms interrogés. Aucune des deux dispositions ne prouve quoi que ce soit sur la conservation, à moins de lire la politique.

Notez la décision par profil, car ces réglages dérivent. Un profil qui a poussé un résolveur le mois dernier n’en pousse peut-être aucun aujourd’hui, et le navigateur gardera volontiers un ancien point de terminaison personnalisé qui répond encore. La note doit contenir l’adresse du résolveur, les suffixes qu’il possède et le mode du navigateur, pas la marque du service.

Testez la politique que vous croyez avoir configurée

Testez par nom, pas par badge. Résolvez un nom public et un nom privé via le résolveur système, puis répétez dans le navigateur avec son propre réglage de DNS sécurisé dans le mode que vous comptez utiliser. Si le nom privé échoue uniquement dans le navigateur, vous avez trouvé le désaccord de destinataire sans toucher à un seul réglage du VPN.

Reconnectez ensuite et vérifiez la restauration, car c’est là que vivent les bogues de transfert : déconnectez, confirmez le retour du résolveur précédent, reconnectez, confirmez le retour du résolveur poussé. Enfin, testez un navigateur soumis à une politique gérée si vous en avez un, car ce mode peut refuser entièrement votre changement et garder silencieusement le résolveur précédent.

Commencez par la question de l’espace de noms et vous éviterez l’essentiel. Si la machine doit joindre des noms internes, le résolveur chiffré du navigateur est une décision qui ne porte que sur la moitié publique, et la moitié privée reste attachée à ce que le VPN a poussé.