DNS sur TLS : confidentialité du résolveur et déploiement
Comprendre le transport DNS sur TLS, son déploiement face à DoH et les limites visibles par les proxys et résolveurs.
Vous voulez la documentation structurée pour Réseau ?
Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.
DNS sur TLS (DoT) envoie les messages DNS sur une connexion TCP protégée par TLS, généralement vers le port 853 et un résolveur choisi au lieu du chemin DNS en clair. Cela peut réduire l'exposition à un réseau local qui observe ou modifie DNS, mais ne rend pas la navigation anonyme. Le navigateur, le système, le proxy, le résolveur, le site de destination et le compte voient chacun une partie différente de la requête.
Ce que DoT change
DoT et DoH sont des choix de déploiement différents
DoT protège les messages DNS avec TLS sur TCP, généralement sur le port 853. DoH place les messages dans des requêtes HTTPS et peut utiliser l’infrastructure, le proxy et les ports du Web. Aucun des deux protocoles ne rend la navigation anonyme ni ne détermine seul l’opérateur du résolveur.
Un réseau peut autoriser HTTPS et bloquer DoT, ou appliquer une politique d’appareil qui termine ou restreint la connexion. Ces différences concernent le déploiement, pas le contournement des contrôles réseau.
Dans les deux cas, le résolveur reçoit la question pour y répondre. TLS limite ce que voient les intermédiaires qui ne terminent pas la session, mais le résolveur peut voir le nom, le moment et les métadonnées nécessaires à son service.
Le DNS traditionnel utilise souvent UDP ou TCP vers le résolveur configuré par le système ou le réseau. DoT transporte l'échange DNS dans TLS sur TCP et peut utiliser un point de terminaison choisi par le navigateur, le système, l'administrateur ou l'utilisateur. Le guide DNS de MDN décrit la résolution de noms ; DoT change le transport et la relation avec le résolveur, pas la politique du site.
La RFC 7858 décrit le transport DNS sur TLS des messages DNS. Elle n'impose pas les mêmes réglages à tous les navigateurs et n'oblige pas chaque recherche à passer par DoT. Une voie système, proxy ou de secours peut exister selon la politique et la disponibilité.
Contrôles et choix de l'utilisateur
DoT est une décision du navigateur ou du système, pas une permission de page. Un navigateur peut proposer un mode automatique, désactivé ou personnalisé ; une politique d'entreprise peut gérer le choix ; un réseau peut bloquer le point de terminaison. Une page ne peut pas modifier ce choix de manière fiable.
Les documents Firefox et Chrome montrent des contrôles propres à chaque fournisseur. Leurs valeurs par défaut évoluent. Un nom de fournisseur ne prouve pas que tout le DNS, les connexions ou la télémétrie suivent la même route. Ne demandez pas à une personne de violer une politique administrée pour accomplir une autre tâche.
Limites proxy, résolveur et destination
Un proxy transporte les requêtes d'application ; un résolveur répond aux noms. Selon la configuration, le navigateur peut résoudre par DoT avant le proxy, demander au proxy de résoudre ou utiliser le système en secours. L'ordre dépend de l'implémentation et de la politique.
Le résolveur reçoit généralement le nom demandé et les métadonnées nécessaires. Le proxy voit la connexion qu'il transporte et ses journaux. La destination voit la requête reçue, y compris les en-têtes et le contexte du compte. HTTPS protège le segment navigateur-résolveur, mais ne cache pas la destination à elle-même et n'efface pas les journaux. Une réponse DNS ne prouve ni l'identité, ni le lieu, ni l'intention.
Limites de confidentialité et erreurs
DoT peut réduire l'exposition à un observateur DNS local, mais le résolveur peut connaître les requêtes, le proxy les connexions et le site la requête reçue. Les cookies, le stockage, les comptes et la télémétrie restent séparés. N'assemblez pas des événements DNS avec d'autres signaux pour profiler.
Une résolution peut échouer à cause du point de terminaison, d'une politique, d'un certificat, d'un portail captif ou d'un réseau incompatible. Gardez la tâche utilisable, proposez une nouvelle tentative claire et ne passez pas silencieusement à un résolveur non approuvé. Un événement limité comme resolver-unavailable vaut mieux que l'enregistrement du nom demandé.
Vérification pratique
Documentez le résolveur, son responsable, sa conservation annoncée et les navigateurs testés. Vérifiez proxy et résolveur avec des domaines contrôlés par l'équipe. Testez les états administré, personnalisé, indisponible et de secours sans collecter l'historique réel.
Indiquez si un contrôle concerne le navigateur, le profil ou l'appareil géré. Une décision administrateur doit rester en lecture seule. Consultez la configuration proxy BotBrowser lorsqu'un flux utilise un proxy. La promesse doit rester précise : expliquer la route, réduire les journaux et rester utile quand la politique change.
Pour le contexte associé, consultez la prévention des fuites DNS et la cohérence proxy, DNS et WebRTC.
Choisir un résolveur de façon responsable
Le choix d'un résolveur relève aussi de la gouvernance. Comparez sa politique publiée, sa conservation et son processus d'incident. Le transport chiffré n'empêche pas le fournisseur de voir le nom demandé.
Repli et tests contrôlés
Définissez le repli avant le déploiement : une nouvelle tentative, un message clair et une alternative documentée. Testez des points de terminaison normaux, indisponibles et administrés avec des domaines contrôlés, sans historique réel.
Choisissez un résolveur adapté au profil: préférence personnelle documentée, point final approuvé pour un profil géré, domaine contrôlé pour les tests.
Ne choisissez pas un fournisseur pour le seul mot «privé». Vérifiez son opérateur, sa conservation, sa juridiction et son processus d'incident.
Séparez le fournisseur de l'identité applicative; une page ne doit pas imposer un résolveur pour se connecter sans exigence approuvée.
Un navigateur peut suivre DoT, le système ou une désactivation administrée; les portails captifs peuvent intercepter DNS.
Définissez le repli avant publication: reprise lisible pour une page publique, arrêt jusqu'au résolveur approuvé pour un flux sensible.
Ne basculez jamais silencieusement vers un point final non approuvé; documentez la décision pour l'utilisateur.
Une mise à jour, un certificat ou une politique peut changer la route. Recalculez-la au redémarrage et lors d'un changement de politique.
Le Web n'offre pas d'API portable indiquant le résolveur ou la protection DoT. La réussite et le délai d'une requête ne prouvent pas le transport.
Le support peut demander navigateur/version, état du profil, heure, erreur et nom contrôlé, mais pas l'historique complet.
Séparez les étapes proxy et résolution: une connexion peut échouer après résolution ou le proxy peut résoudre lui-même.
DoT n'est qu'un contrôle; cookies, stockage, permissions, référents, comptes, journaux et tiers révèlent encore le contexte.
Le contenu intégré peut suivre une autre route. Ne dites pas que toute la page utilise un DNS privé quand un seul réglage l'est.
Rapports, captures et liens peuvent révéler un nom. Autorisez les seuls champs utiles, masquez les noms et expirez les données.
Testez les résultats: point final normal ou indisponible, politique gérée, proxy qui résout, destination en échec.
Vérifiez message, conservation des données et action suivante sur les versions supportées.
Utilisez des domaines de l'équipe; excluez leurs noms des analyses et supprimez les résultats après le test.
Les temps d'attente ne prouvent ni un résolveur ni un acteur réseau particulier.
Questions fréquentes.
Écrivez la décision DoT: mode, équipe responsable, point final autorisé et conditions de repli.
Révisez-la lors des changements de navigateur, système, proxy ou réseau, sans promettre un comportement futur identique.
Une étiquette claire distingue «DNS sécurisé si disponible» de «ce fournisseur uniquement».
Montrez qu'un choix administré est en lecture seule et indiquez le support; un bouton sans effet est trompeur.
Limitez les reprises, préservez les formulaires et proposez un chemin manuel ou hors ligne.
La documentation doit utiliser des noms de test et des étapes masquées: DoT ne protège pas tous les signaux.
DoT cache-t-il l'IP? Non; il chiffre DNS, mais le proxy et la destination voient la connexion suivante.
Une page sait-elle si DoT est actif? Pas de manière fiable via une API Web portable.
Un proxy est-il un résolveur DoT? Non: le résolveur répond aux noms, le proxy transporte les connexions et peut résoudre pour le client.
Une application doit-elle imposer un résolveur? Seulement si une exigence documentée le justifie; respectez sinon la politique gérée.
En cas d'échec DNS, collectez l'étape, les versions, la politique autorisée et l'heure, jamais l'historique complet.
Le réglage appartient au navigateur ou au système, pas à la page; celle-ci ne peut pas l'imposer.
Résolveur, proxy et destination sont des observateurs distincts à documenter séparément.
La promesse doit couvrir seulement le trajet protégé, jamais un anonymat total.
Une réponse DNS ne prouve ni identité, ni emplacement, ni intention.
Les diagnostics doivent retenir une étape et un résultat, pas le nom demandé.
Sources
Articles Connexes
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.