Votre VPN chiffre-t-il le DNS, ou seulement le saut suivant ?

Activer le DNS chiffré sur le serveur VPN est souvent décrit comme la fermeture d'une fuite, et cette description masque quelle connexion a changé. Le saut du client vers le résolveur et le saut du résolveur vers l'amont sont des connexions distinctes avec des propriétaires distincts. Chiffrer l'une laisse l'autre exactement comme elle était.

Notez qui reçoit la requête à chaque étape avant de toucher à un fichier de configuration.

Deux dispositions se ressemblent sur une page de réglages

Dans la première disposition, l'appareil exécute lui-même DNS over TLS, et le tunnel ne fait que transporter cette connexion vers un résolveur que vous avez choisi. La session TLS se termine au résolveur, ce qui signifie que le résolveur voit la requête et que la sortie du VPN voit un texte chiffré qu'elle ne peut pas lire. Dans la seconde disposition, l'appareil envoie du DNS ordinaire par le tunnel vers un redirecteur sur l'hôte VPN, et ce redirecteur ouvre sa propre connexion chiffrée vers un résolveur amont. Les deux apparaissent comme "DNS chiffré avec un VPN" dans une liste de fonctionnalités, et elles placent la requête lisible dans des bâtiments différents.

La différence est mesurable plutôt que philosophique. Cherchez la session TLS sur le client, ou sur le serveur, et vous saurez quelle disposition vous avez réellement.

Cartographiez la chaîne de résolveurs avant de la modifier

Comptez les résolveurs sur le chemin et nommez le rôle de chacun. Un composant de redirection remet une requête à un autre résolveur, tandis qu'un résolveur récursif fait le travail de trouver une réponse et peut parler directement aux serveurs autoritaires. Ces rôles sont définis séparément précisément pour cette raison, et les définitions de résolveur du RFC 9076 méritent d'être lues avant de supposer qu'il existe une destination amont unique. Un hôte qui exécute son propre résolveur récursif n'a pas d'"amont" unique à chiffrer, ce qui invalide tout le plan.

Demandez ensuite quel composant le client est configuré pour utiliser. Une adresse DNS poussée par le profil VPN vous dit où vont les requêtes, pas quel processus y répond.

Notez aussi le comportement en cas d'échec. Si l'amont chiffré devient injoignable, le redirecteur échoue-t-il fermé, retombe-t-il sur du texte en clair ou sur un autre résolveur ? Cette décision doit figurer au dossier, car elle change la garantie de confidentialité au moment où le tunnel est le moins sain.

Vérifiez quel saut est chiffré

Commencez par le client et confirmez s'il détient une session TLS vers le port 853. Une requête qui se résout correctement par le port 53 ne prouve rien sur le chiffrement.

resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A

Passez ensuite à l'hôte VPN et cherchez la connexion chiffrée sortante que le redirecteur a ouverte. La table des sockets vous dit si une session TLS amont existe et quel processus la possède :

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

Si le client montre une session TLS et le serveur aucune, vous êtes dans la première disposition et le serveur ne peut pas lire les requêtes qu'il redirige au niveau IP. Si le serveur montre la session TLS et le client un trafic ordinaire sur le port 53 à l'intérieur du tunnel, vous êtes dans la seconde disposition : le saut suivant est protégé, et le redirecteur lit encore chaque nom que l'appareil demande. Ce second résultat n'est pas un échec, mais l'appeler chiffrement de bout en bout est faux.

Consignez le propriétaire et le comportement en cas d'échec

La propriété décide de ce que vous êtes autorisé à promettre. Le propriétaire de l'appareil contrôle une connexion chiffrée côté client, tandis que l'administrateur du VPN contrôle la connexion suivante que crée son redirecteur. Qui n'exploite ni l'une ni l'autre ne peut que décrire le chemin.

Avant d'activer quoi que ce soit, vérifiez le nommage interne. Envoyer des noms d'organisation à un résolveur public n'est pas une conception équivalente, et une zone split-horizon qui n'existe qu'à l'intérieur du réseau ne se résoudra pas du tout en amont. Testez un nom interne et un nom public après le changement, et conservez le résultat avec la modification de configuration. Si le chemin chiffré casse la résolution des hôtes internes, le correctif est une règle de résolveur à portée limitée, pas un tunnel plus large.

Terminez en écrivant une phrase par saut : quel composant a reçu la requête, si ce saut était chiffré, et qui peut lire le nom. Lorsque la phrase concernant l'hôte VPN dit encore qu'il peut lire les requêtes, la documentation devrait le dire, car un schéma qui affirme le contraire sera cru par quelqu'un qui n'a jamais exécuté les commandes.