DNS over TLS (DoT) : définition, fonctionnement et configuration

Le DNS a toujours souffert d’un problème de sécurité au niveau du « dernier kilomètre » : les communications entre un client DNS et le serveur DNS sont presque toujours non chiffrées, et donc sujettes à l’usurpation d’identité, à l’interception, etc. DNS over TLS est documenté dans le document IETF RFC 7858: Specification for DNS over Transport Layer Security (TLS).

Concrètement, le DoT encapsule vos requêtes DNS dans un tunnel TLS, le même que celui utilisé pour sécuriser les sites web en HTTPS. La grande différence avec le DNS over HTTPS (DoH) réside dans le port utilisé : le DoT emploie le port 853, dédié exclusivement à ce trafic chiffré.

Pas de couche HTTP supplémentaire, ce qui peut offrir un gain de performance léger selon votre réseau. Mais attention, ce choix se fait au détriment de la flexibilité qu’offre le HTTPS.

Pas étonnant, avec DoH, les requêtes DNS sont envoyées via les protocoles HTTP ou HTTP/2, ce qui les rend plus lourdes mais aussi plus difficiles à distinguer du trafic web classique. DoT, utilise une simple connexion TCP avec TLS, ce qui le rend plus léger mais aussi plus facile à identifier pour les pare-feu.

Configuration : Fonctionnement du DNS sur TLS

L’initiation de DNS over TLS est très simple. En établissant une connexion sur un port TCP 853, les clients et les serveurs s’attendent et acceptent de négocier une session TLS pour sécuriser le canal.

Ledéfinit la méthode suivante pour l’utilisation de DNS over TLS afin d’établir des sessions sécurisées : RFC 7858

Initiation de la session

Un serveur DNS qui supporte DNS over TLS écoute et accepte les connexions TCP sur le port 853, à moins qu’il n’ait un accord mutuel avec son serveur pour utiliser un port différent pour DoT. Lors de l’utilisation de DNS over TLS, toutes les connexions TCP sur le port 853 doivent être chiffrées, car le mélange de données chiffrées et non chiffrées pose d’importants problèmes de sécurité.

Contrairement à DoH qui utilise le port 443 partagé avec HTTPS, DoT nécessite une configuration explicite du port 853, ce qui simplifie la gestion réseau mais limite la flexibilité dans les environnements où ce port est bloqué.

Handshake TLS et authentification

Une fois que le client DNS s’est connecté avec succès, il procède à la négociation TLS et s’authentifie auprès du serveur DNS, si nécessaire. Une fois la négociation TLS terminée, la connexion est chiffrée. Le serveur Google Public DNS, par exemple, renvoie son certificat TLS accompagné d’une chaîne complète de certificats jusqu’à une racine de confiance.

Le résolveur local (stub resolver) vérifie alors l’identité du serveur pour s’assurer qu’il s’agit bien du serveur légitime. Cette étape d’authentification est cruciale pour empêcher les attaques de type « man-in-the-middle » où un attaquant pourrait se faire passer pour un serveur DNS légitime.

DoT vs DoH

DNS over HTTPS (DoH) est un deuxième protocole de sécurité de l’IETF qui traite de la sécurité des communications entre le client DNC et le serveur DNS.

DoH est documenté dans la RFC 8484 de l’IETF. Les protocoles DNS over TLS et DNS over HTTPS prévoient tous deux le chiffrement entre le client DNS et le serveur DNS, ce qui permet d’assurer la confidentialité et l’intégrité des données.

Après DoH utilise le même port TCP que le reste du trafic HTTP-S, le port 443. Par conséquent, il peut être difficile d’identifier DoH d’un autre trafic HTTP-S. Cette similarité avec le trafic web classique fait de DoH un outil puissant pour contourner les restrictions réseau, mais aussi un défi pour les administrateurs qui doivent le gérer.

DoH a ses limites, car certaines applications qui prennent en charge DoH peuvent ignorer délibérément la configuration du client DNS local. Le navigateur Firefox de Mozilla, par exemple, prend en charge DoH à titre expérimental dans certaines versions. Lorsqu’il est activé, Firefox ignore toute configuration DNS locale et envoie les requêtes DNS par HTTP-S directement à Cloudflare.

• Cela permet de contourner les mécanismes de sécurité locaux, tels que les zones de protection contre les intrusions, et de rendre la résolution DNS d’un utilisateur opaque pour son service informatique.
• Cela complique également la résolution des problèmes DNS, car une application (Firefox, par exemple) sur un appareil utilise désormais des serveurs DNS différents de ceux des autres applications.

DNSSEC et DoT

DNSSEC, les extensions de sécurité DNS, ajoutent l’authentification et le contrôle de l’intégrité des données au DNS, ce qui manque généralement au client DNS : le serveur DNS local effectue la validation DNSSEC et établit l’authenticité et l’intégrité des données, puis transmet le résultat au client DNS.

Cette dernière étape de la communication peut toutefois être usurpée. Effectivement DNSSEC ne chiffre pas les requêtes DNS ; il se contente de signer les réponses pour prouver leur authenticité.

Cela signifie que même avec DNSSEC, un attaquant peut toujours intercepter et lire les requêtes ce qui pose un problème de confidentialité. DoT comble cette lacune en chiffrant l’intégralité de la communication entre le client et le serveur DNS, empêchant ainsi toute écoute clandestine.

Ensemble, DNSSEC et DoT offrent une protection complète : DNSSEC garantit que les réponses DNS n’ont pas été falsifiées, tandis que DoT assure que personne ne peut espionner les requêtes. C’est pourquoi de nombreux experts recommandent de combiner les deux protocoles pour une sécurité DNS optimale.

Recommandations de mise en œuvre

Il est souvent recommandé aux entreprises de bloquer le trafic DNS direct (y compris DoT) entre les adresses IP internes et les serveurs DNS sur Internet, y compris ceux de Cloudflare. Cela empêche certains types de logiciels malveillants, dont DNSChanger, de fonctionner et oblige les hôtes internes à utiliser l’infrastructure DNS gérée par le service informatique.

Cette infrastructure DNS interne peut appliquer une politique de résolution des noms à l’aide de mécanismes de sécurité tels que les zones de politique de réponse (RPZ).

Le blocage du trafic DNS standard et DoT entre les adresses IP internes est simple. Des règles de pare-feu comme celles qui suivent devraient suffire :

• Autoriser tcp/udp in/out sur le port 53
• Refuser l’entrée/sortie de tcp/udp vers toutes les adresses IP sur le port 53
• Refuser l’entrée/sortie de tcp/udp à toutes les adresses IP sur le port 853

Contourner l’infrastructure DNS interne semble être une mauvaise idée, mais il est utile de résoudre le problème du « dernier kilomètre » du DNS. Pour les utilisateurs avancés, une alternative consiste à configurer un résolveur DNS local (comme Unbound) qui supporte DoT et DNSSEC. Cela permet de bénéficier du chiffrement DoT tout en gardant le contrôle sur les politiques de résolution.

Et puis, la modélisation des menaces montre que DoT est particulièrement efficace contre les attaques de type « man-in-the-middle » sur le réseau local, mais qu’il ne protège pas contre les serveurs DNS malveillants eux-mêmes. C’est pourquoi il est crucial de choisir des résolveurs de confiance comme ceux de Cloudflare (1.1.1.1), Quad9 (9.9.9.9) ou Google Public DNS.

Pourquoi ça vaut le coup

1. La portée de DNS-over-TLS est limitée par rapport à l’authentification de bout en bout fournie par DNSSEC, mais elle est beaucoup plus facile à déployer progressivement et offre des avantages en matière de protection de la vie privée que DNSSEC n’offre pas.
2. Du point de vue de la sécurité, le DNS-over-TLS empêche les FAI d’injecter de fausses informations dans les réponses DNS, par exemple pour vous envoyer sur une page de recherche contenant des publicités pour des domaines mal saisis. Pour de telles attaques de type « man-in-the-middle » , la barre est placée à un certificat TLS/SSL falsifié, ce qui est probablement à la portée des gouvernements, mais de peu d’autres.
3. Du point de vue de la protection de la vie privée, le DNS sur TLS dissimule votre trafic DNS aux FAI et aux sites de surveillance de masse entre votre routeur et le résolveur public. Ceci dit la connexion à l’adresse IP récupérée via DNS donne aux fouineurs de fils beaucoup d’informations, même si le DNS est chiffré.

Le DoT est souvent préféré au DoH par les administrateurs réseau parce qu’il permet de surveiller et de bloquer les requêtes DNS au niveau du réseau. vous pouvez identifier et stopper un trafic potentiellement malveillant, ce qui en fait un atout pour la sécurité d’entreprise.

Mais attention : si vous avez déjà configuré le DoT sur votre routeur (comme sur une Fritz!box par exemple), inutile de le refaire sur chaque PC. La configuration au niveau du routeur suffit. Et si jamais vous voulez vérifier que tout fonctionne, une commande netsh dns show encryption vous affichera l’état de chaque serveur.

Pour activer le DoT sous Windows 11, il faut passer par la ligne de commande, une opération réservée aux utilisateurs avancés. Vous devez d’abord configurer vos serveurs DNS dans les paramètres réseau en sélectionnant l’option manuelle.

Ensuite, via Windows Terminal en mode administrateur, vous exécutez des commandes netsh. La première, netsh dns add global dot=yes, active le DoT globalement.

La seconde, netsh dns add encryption server= suivi de l’adresse du serveur, associe chaque serveur à son hôte DoT. Un détail important : le champ dothost mis à « : » signifie que le port par défaut (853) est utilisé et que le nom de domaine du certificat TLS n’est pas vérifié.

Pour une validation plus stricte, fournissez le nom de domaine attendu du serveur DoT. Par exemple, pour Cloudflare, utilisez netsh dns add encryption server=1.1.1.1 dothost=cloudflare-dns.com.

Pour renforcer votre confidentialité en ligne, associer le DoT à un VPN est une solution robuste. Le VPN chiffre tout votre trafic, tandis que le DoT protège spécifiquement vos requêtes DNS. Cette double couche de protection est utile sur les réseaux Wi-Fi publics où les attaques sont fréquentes.
ProtonVPN

Performances

Le DNS est sensible à la latence (il se trouve souvent dans le chemin critique de la navigation sur le web), ajustez donc vos performances.

Optimisation de la latence

Pour minimiser l’impact du DoT, choisissez un résolveur proche de votre localisation géographique. Des serveurs comme Cloudflare (1.1.1.1) ou Quad9 (9.9.9.9) offrent d’excellentes performances et supportent le DoT.

Testez plusieurs serveurs avec des outils comme namebench pour trouver le plus rapide. En bonus, comme DoT utilise une connexion TCP persistante, la latence initiale de la négociation TLS est rapidement compensée par les échanges suivants.

Pour les utilisateurs avancés, il est possible d’ajuster les paramètres de timeout et de keepalive de la session TLS pour réduire encore la latence. Enfin, notez que DoT est généralement plus performant que DoH dans les environnements à faible latence, car il évite la surcharge de l’encapsulation HTTP.

Après dans les réseaux où le port 853 est filtré, DoH peut être la seule option viable malgré sa latence légèrement supérieure.

Mon avis