DNS privé et VPN : ce que chaque couche couvre réellement

Votre téléphone a le DNS privé réglé sur un nom d’hôte de fournisseur et une application VPN en cours d’exécution en même temps. Il est raisonnable de penser que l’un des deux gère désormais les recherches de noms. Aucun ne le fait, au sens où cette phrase le suggère, et le moyen le plus rapide de voir pourquoi est de suivre une seule requête depuis le moment où vous touchez un lien.

Ces deux fonctions se situent à des points différents du même parcours. Le DNS privé chiffre la question que vous posez à un résolveur. Un VPN change la route que prend la connexion de la réponse.

Parcourez donc cela dans l’ordre, sur un appareil où les deux sont activés, et notez ce que chaque couche peut encore voir.

Étape un : la recherche quitte l’application

Vous touchez un lien. Avant que quoi que ce soit se connecte, l’application a besoin d’une adresse pour ce nom d’hôte. Sur Android, l’écran concerné est Paramètres, Réseau et Internet, DNS privé. Choisir Nom d’hôte du fournisseur de DNS privé place l’appareil en mode strict : il effectue du DNS sur TLS vers ce nom d’hôte sur le port 853, et si l’échange chiffré échoue, la recherche échoue au lieu de retomber silencieusement en clair sur le port 53.

C’est une différence notable avec Automatique, qui utilise un chiffrement opportuniste et utilisera volontiers un résolveur non chiffré lorsque le réseau s’en mêle. Si votre objectif est que les recherches ne soient jamais en clair, le mode strict avec un nom d’hôte de fournisseur est le réglage qui y correspond.

Voici la première chose que le parcours révèle : la recherche est protégée contre le réseau local, et le résolveur apprend quand même le nom. Le chiffrement couvre le saut. L’opérateur de ce résolveur voit la requête parce que c’est son travail d’y répondre.

Étape deux : la connexion emprunte une autre route

Le résolveur renvoie une adresse et l’application s’y connecte. Cette étape n’est pas affectée par la manière dont la recherche a été chiffrée. Sans tunnel, la connexion sort de votre adresse publique habituelle, et l’IP de destination et la poignée de main TLS rendent de toute façon le nom d’hôte visible pour le réseau, avec ou sans DNS chiffré.

Activez le VPN et c’est cette étape qui change. Le trafic conforme à la politique de routage du client passe par le tunnel, le réseau local voit une connexion vers le point de sortie du VPN, et le site voit généralement l’adresse de sortie. La résolution de noms peut aussi passer à l’intérieur du tunnel, selon ce que le client pousse.

Cette séparation, c’est toute la comparaison en une phrase. Le chiffrement DNS répond à la question de savoir qui peut lire la question. Un VPN répond à la question de savoir où va la conversation.

Étape trois : dans le tunnel, le DNS devient une question de politique

Maintenant, les deux fonctions interagissent, et le navigateur est la source habituelle de surprise. Un navigateur doté de son propre réglage de DNS sécurisé peut envoyer les recherches à son résolveur choisi via HTTPS au lieu de demander au système d’exploitation. Le réglage DNS privé d’Android n’entre pas dans cette décision.

Dans Firefox, l’interrupteur se trouve sous Paramètres, Vie privée et sécurité, Activer le DNS sécurisé. Dans Chrome, il est sous Paramètres, Confidentialité et sécurité, Utiliser le DNS sécurisé. Les deux peuvent être fixés à un fournisseur précis ou laissés désactivés, et lorsqu’ils sont activés, la configuration DNS du tunnel est contournée pour ces recherches, même si le trafic de la page utilise toujours le tunnel.

Si le VPN pousse son propre résolveur et que le navigateur tient au sien, vous obtenez une division : les noms se résolvent, les pages se chargent, et les recherches qui devaient passer par le tunnel sont sorties directement. Une adresse de résolveur différente du point de sortie du VPN n’est pas une preuve de fuite en soi, mais un chemin de recherche qui contredit votre intention déclarée mérite d’être corrigé.

Étape quatre : les noms internes sont là où ça casse

Connectez-vous à un VPN d’entreprise et ouvrez un hôte intranet. Si le DNS sécurisé du navigateur est activé et pointe vers un résolveur public, ce nom n’existe pas pour le navigateur. Le tunnel est monté, tout le reste fonctionne, et un nom d’hôte échoue avec une erreur qui donne l’impression que le site est hors service.

La même panne apparaît à l’inverse sur Android. Le DNS privé strict avec un fournisseur public ne résoudra pas les noms que seul le résolveur interne connaît, et le mode strict n’a pas de repli. Répartir le DNS d’un téléphone entre un résolveur public chiffré et un résolveur d’entreprise n’est pas un réglage ; c’est une question de politique de routage à laquelle doit répondre celui qui exploite le VPN.

Vérifiez cela avant d’accuser le tunnel : interrogez le nom interne, puis le même nom avec le DNS sécurisé du navigateur désactivé. S’il se résout, le choix du résolveur était le problème, pas la connexion.

Ce que le parcours vous dit de changer

Quatre écrans portent presque tout. Regardez-les dans cet ordre et notez ce que dit chacun, car la réponse est généralement visible dans la combinaison :

1. Paramètres Android, Réseau et Internet, DNS privé : Automatique ou un nom d’hôte de fournisseur, et lequel.
2. Le réglage de DNS sécurisé du navigateur : désactivé, ou fixé à un résolveur précis.
3. La politique DNS du client VPN : pousse-t-elle un résolveur, et le tunnel divisé exclut-il quelque chose qui a encore besoin de noms ?
4. Un test de nom d’hôte interne avec le tunnel monté, exécuté deux fois, une fois avec le DNS du navigateur activé et une fois désactivé.

Faites ensuite correspondre la correction à l’exigence, et non l’inverse. Si l’exigence est que les recherches sortent chiffrées et aillent vers un résolveur que vous avez choisi, réglez le DNS privé strict et faites en sorte que le navigateur s’y conforme. Si l’exigence est que le trafic sorte ailleurs, configurez le tunnel et cessez d’attendre qu’un réglage DNS déplace votre adresse.

Et gardez les limites en vue. Aucune des deux fonctions ne rend une destination hostile sûre, et aucune ne supprime une identité avec laquelle vous vous êtes connecté. Le chiffrement change qui peut lire la question ; le tunnel change où va la connexion ; rien de tout cela n’anonymise le compte.