DNS sur TLS et VPN : quelle partie est protégée

DNS sur TLS chiffre l'échange entre un client et le résolveur qu'il a choisi, et le résolveur lit toujours le nom. Cette phrase règle l'essentiel de la confusion autour de DoT et d'un VPN. Le tunnel décide par quel chemin passe la requête chiffrée, tandis que le résolveur apprend toujours ce qui a été demandé. Aucun des deux mécanismes ne remplace l'autre, et aucun ne rend l'autre redondant.

Quatre vérifications déterminent si la disposition que vous avez est celle que vous croyez avoir.

Vérification 1 : ce que couvre le chiffrement

DoT enveloppe l'échange DNS dans TLS, si bien qu'un observateur sur le chemin voit une connexion vers une adresse et un port plutôt qu'un nom dans une requête. Le résolveur lui-même déchiffre et répond. Comparez avec DNS sur HTTPS : les deux chiffrent, et ils utilisent des transports différents, donc un réseau qui autorise le trafic web n'autorise pas automatiquement une connexion DoT.

Cette distinction compte quand un portail captif ou un intermédiaire de filtrage autorise le 443 et bloque le 853. L'outil qui fonctionnait là-bas ne prouve pas que l'autre fonctionnera.

Vérification 2 : quelle route prend la requête

La route est une question de politique du client. Un résolveur DoT peut être atteint par le tunnel, en dehors de lui, ou par un chemin qui change avec le réseau. Lequel se produit dépend des routes et de si le client protège sa propre socket DNS. Un tunnel qui capture tout le trafic emporte généralement la requête avec lui, quoi que dise l'adresse du résolveur.

Voir une adresse de résolveur tierce dans un test ne prouve pas un contournement, et voir du chiffrement ne prouve pas le destinataire voulu. Lisez le résolveur et le chemin séparément, puis décidez si le couple est celui que vous avez conçu.

Vérification 3 : les noms internes

Une organisation qui publie des noms internes a besoin d'un résolveur qui détient ces enregistrements. Un service DoT public ne connaît pas votre espace de noms privé, et pointer le client vers un tel service garantit que ces noms échouent. C'est la régression pratique la plus courante quand quelqu'un active le DNS chiffré sur un appareil géré.

Gardez le résolveur interne pour les suffixes internes et chiffrez ce saut si la politique l'exige, au lieu de le remplacer par un fournisseur public.

Vérification 4 : le comportement en cas d'échec

Un réglage strict du résolveur sans résolveur joignable produit un échec de résolution de noms alors que le tunnel reste actif. Regardez le mode de la plateforme et son repli documenté plutôt que de toucher aux clés ou aux certificats.

Un repli qui utilise silencieusement du DNS en clair est une décision de politique, pas une commodité. Décidez si l'échec doit être visible ou doit se dégrader vers quelque chose de plus faible, et écrivez la réponse.

Faites confiance au certificat, pas à la réponse

Utilisez le nom d'hôte du fournisseur et la configuration de vérification documentés pour le service. Désactiver les contrôles TLS pour qu'un résolveur inconnu réponde vous donne un canal chiffré vers un point de terminaison non vérifié, ce qui est pire que la requête en clair qu'il a remplacée d'une manière précise : cela paraît sûr. La spécification DNS sur TLS expose l'attente d'authentification derrière ce contrôle.

Une réponse d'un résolveur que vous ne pouvez pas authentifier est une affirmation, pas un résultat.

Ce que cela laisse inexpliqué

DoT ne cache pas le nom au résolveur, ne cache pas l'adresse de destination de la connexion au réseau et ne décide pas si la requête a voyagé par le tunnel. Ce sont trois questions distinctes avec trois réponses distinctes.

Écrivez l'identité du résolveur, le chemin de transit et la politique de noms internes sur trois lignes. La prochaine question DNS que vous recevrez sera l'une d'elles.