DNS over TLS (DoT) : chiffrer la résolution de noms

Le DNS over TLS (DoT), normalisé par le RFC 7858, désigne l’encapsulation des échanges DNS (Domain Name System, système de noms de domaine) dans un tunnel chiffré établi avec le protocole TLS (Transport Layer Security, sécurité de la couche transport). La résolution de noms traditionnelle circule en clair sur le réseau, ce qui expose les requêtes à l’espionnage, à la manipulation des réponses et à l’usurpation de résolveur. En protégeant à la fois la confidentialité et l’intégrité des messages DNS, DoT comble une lacune historique du protocole originel, spécifié à la fin des années 1980, à une époque où le chiffrement du trafic n’était ni courant ni jugé nécessaire. Aujourd’hui, chaque nom résolu révèle une intention — un site visité, un service consulté, une application ouverte — et cette métadonnée a une valeur commerciale et opérationnelle qui justifie sa protection.

→ Lire l’explication complète de la marmotte

TortueTech Débutant · Intermédiaire

Pourquoi chiffrer les échanges DNS

Une requête DNS classique voyage en UDP (User Datagram Protocol, protocole de datagramme utilisateur) ou en TCP (Transmission Control Protocol, protocole de contrôle de transmission) sur le port 53, sans aucune protection cryptographique. Tout intermédiaire situé sur le chemin réseau — fournisseur d’accès, opérateur d’un point d’accès Wi-Fi public, attaquant en position d’interception — peut lire les noms de domaine résolus et déduire les services consultés. Il peut également altérer une réponse pour rediriger le trafic vers un serveur malveillant, une technique connue sous le nom d’empoisonnement de cache ou de détournement DNS.

Le problème est aggravé par le fait que le DNS précède presque toute autre communication : avant même qu’une connexion chiffrée en HTTPS (HyperText Transfer Protocol Secure) ne s’établisse vers un site, la résolution de son nom a déjà fuité en clair. Même si le contenu de la page est ensuite parfaitement protégé, un observateur sait déjà quel domaine a été contacté. Le chiffrement du transport applicatif ne suffit donc pas : la résolution de noms constitue un maillon exposé qu’il faut traiter séparément.

DoT répond à deux menaces distinctes. La confidentialité est assurée en chiffrant le contenu des requêtes et des réponses, ce qui empêche l’observation passive des noms résolus par un tiers sur le chemin. L’intégrité et l’authentification du résolveur reposent sur le certificat présenté à l’ouverture du tunnel TLS, qui permet au client de vérifier l’identité du serveur avant de lui confier ses requêtes. Ces deux propriétés se combinent : chiffrer sans authentifier laisserait la porte ouverte à un intermédiaire qui se ferait passer pour le résolveur légitime.

Comment fonctionne le protocole DoT

DoT est normalisé par l’IETF (Internet Engineering Task Force, groupe de travail d’ingénierie de l’Internet) dans le RFC 7858. Le client, appelé résolveur stub (résolveur minimal embarqué dans le système d’exploitation), ouvre une connexion TCP vers le résolveur récursif sur le port dédié 853, puis négocie une session TLS. Une fois le tunnel établi, les messages DNS habituels transitent à l’intérieur du canal chiffré, précédés de leur préfixe de longueur sur deux octets, exactement comme en DNS sur TCP.

Le déroulement de la négociation suit quatre étapes. La connexion TCP est d’abord établie sur le port 853. La poignée de main TLS s’enchaîne ensuite, avec l’échange du certificat serveur et la négociation des paramètres cryptographiques (versions, suites de chiffrement, courbes). Le client valide alors le certificat selon la politique choisie. Enfin, les requêtes DNS sont transmises dans le tunnel, et la connexion est réutilisée pour plusieurs requêtes successives afin d’amortir le coût initial.

Cette réutilisation de connexion est un point clé de performance. La poignée de main TLS reste l’opération la plus onéreuse : elle ajoute au moins un aller-retour réseau complet en TLS 1.3, et deux en TLS 1.2. Maintenir une session persistante répartit cette latence unique sur des dizaines ou des centaines de requêtes ultérieures, ramenant le surcoût par requête à une valeur négligeable. La reprise de session (session resumption) et, en TLS 1.3, le mode 0-RTT (zéro aller-retour) réduisent encore le coût lors des reconnexions, au prix de compromis de sécurité qu’il faut évaluer.

Il existe une variante sur UDP, DNS over DTLS (Datagram Transport Layer Security), normalisée par le RFC 8094 et employant elle aussi le port 853. Restée expérimentale et très peu déployée, elle n’a pas d’usage significatif : en pratique, « port 853 » désigne presque toujours DoT sur TCP.

Comment garantir l’intégrité et authentifier le résolveur

L’intégrité des données en transit est assurée par un chiffrement authentifié, l’AEAD (Authenticated Encryption with Associated Data, chiffrement authentifié avec données associées) en TLS 1.3, ou par un code d’authentification de message, le MAC (Message Authentication Code) dans les versions antérieures — et non par des signatures cryptographiques, qui n’interviennent que pendant la poignée de main pour authentifier le serveur. Concrètement, chaque bloc de données transporté est accompagné d’une étiquette qui détecte toute altération : un octet modifié en transit fait échouer le déchiffrement et rompt la connexion.

Le RFC 8310 définit deux profils de validation qui déterminent le niveau de confiance accordé au résolveur. Le profil opportuniste tente d’établir TLS mais accepte de continuer sans vérification stricte, voire en clair, si la négociation échoue. Ce mode protège contre l’observation passive mais non contre un attaquant actif : un intermédiaire qui bloque le port 853 peut forcer un repli non chiffré et lire ensuite le trafic. Le profil strict, ou authentification par nom, exige au contraire un tunnel TLS valide et vérifie que le certificat correspond au nom de domaine attendu du résolveur ; toute anomalie interrompt la résolution. Seul ce mode protège réellement contre l’interception active.

L’authentification ne passe pas nécessairement par une autorité de certification (AC) publique. Pour un résolveur interne dont le certificat n’est pas émis par une AC publique, l’épinglage de clé publique — le SPKI (Subject Public Key Info, informations sur la clé publique du sujet) pinset défini par le RFC 7858 — authentifie le serveur en fixant l’empreinte de sa clé, sans dépendre d’une chaîne de confiance externe. Cette approche est particulièrement utile en environnement fermé, où déployer une AC complète serait disproportionné, mais elle impose de mettre à jour l’empreinte à chaque rotation de clé, sous peine d’interruption de service.

Configurer un stub resolver avec DoT

L’outil systemd-resolved, présent sur de nombreuses distributions Linux, prend en charge DoT. La configuration suivante active la validation stricte et déclare un résolveur avec son adresse et son nom d’authentification :

[Resolve]
# Adresse du résolveur suivie du nom attendu dans son certificat
DNS=9.9.9.9#dns.quad9.net
# yes = strict, interdit tout repli en clair ; opportunistic = tolérant
DNSOverTLS=yes

La valeur DNSOverTLS=yes interdit tout repli en clair : la résolution échoue si le tunnel TLS ne peut être établi. La vérification de l’identité du résolveur provient du suffixe #dns.quad9.net, qui indique le nom attendu dans le certificat. Après modification, le service redémarre :

# Applique la nouvelle configuration
sudo systemctl restart systemd-resolved
# Vérifie que +DNSOverTLS apparaît sur l'interface concernée
resolvectl status

La commande resolvectl status confirme que le champ +DNSOverTLS est actif sur l’interface. Une vérification directe du tunnel peut s’effectuer avec kdig, fourni par le paquet knot-dnsutils :

# +tls-ca valide le certificat contre les AC du système
# +tls-host fixe le nom attendu dans le certificat
kdig -d @9.9.9.9 +tls-ca +tls-host=dns.quad9.net example.com

L’outil dig, fourni par BIND (Berkeley Internet Name Domain), a également reçu une option +tls à partir de la version 9.17 ; selon la version installée, elle peut être absente. À défaut, openssl s_client -connect 9.9.9.9:853 permet de vérifier que le port répond bien en TLS et d’inspecter le certificat présenté. En cas d’échec silencieux, il faut d’abord contrôler que le port 853 sortant n’est pas filtré par un pare-feu intermédiaire, cause la plus fréquente des dysfonctionnements.

DoT dans l’écosystème DNS sécurisé

DoT ne se substitue pas aux autres mécanismes de protection : il les complète, chacun agissant à un niveau distinct. DNSSEC (Domain Name System Security Extensions, extensions de sécurité du DNS) signe cryptographiquement les enregistrements pour garantir leur authenticité de bout en bout, indépendamment du canal de transport. La distinction est essentielle : DoT protège le trajet entre le client et le résolveur récursif, tandis que DNSSEC protège les données elles-mêmes depuis la zone d’origine jusqu’au résolveur. Un attaquant qui compromettrait le résolveur lui-même ne serait arrêté que par DNSSEC ; un observateur sur le réseau local ne serait arrêté que par DoT.

DoH (DNS over HTTPS, DNS sur HTTPS) encapsule les requêtes dans HTTPS, ce qui les fond dans le trafic web ordinaire et complique leur identification, sans toutefois la rendre toujours impossible. DoH offre une confidentialité comparable à DoT mais opère sur le port 443, alors que DoT utilise le port dédié 853, plus facile à identifier et à filtrer sur un réseau administré. Ce choix de port résume l’arbitrage : DoT privilégie la lisibilité pour les administrateurs, DoH privilégie l’invisibilité pour l’utilisateur. Enfin, DoQ (DNS over QUIC, DNS sur QUIC) transporte le DNS sur QUIC (Quick UDP Internet Connections), un protocole combinant chiffrement et multiplexage, qui réduit la latence d’établissement et évite le blocage en tête de ligne propre à TCP.

La combinaison de DNSSEC pour l’intégrité des données et de DoT pour la protection du transport constitue une défense cohérente. Le protocole TLS employé s’appuie sur les mêmes fondations que celles décrites dans TLS expliqué, et la validation des certificats de résolveur relève des principes de l’infrastructure à clés publiques. Le rôle du DNS dans l’architecture réseau plus large, aux côtés du DHCP (Dynamic Host Configuration Protocol, protocole de configuration dynamique des hôtes) et du NTP (Network Time Protocol, protocole de temps réseau), est traité dans DNS, DHCP et NTP.

Points de vigilance opérationnels

Le choix du profil est déterminant : le mode opportuniste ne protège pas contre un attaquant actif, et seul le profil strict avec vérification du nom offre une garantie robuste. Beaucoup de configurations par défaut restent en mode opportuniste pour préserver la disponibilité, ce qui donne une fausse impression de sécurité.

La latence de la poignée de main affecte la première requête, qui subit le coût de la négociation TLS ; le maintien de connexions persistantes et la reprise de session atténuent cet effet, à condition que le résolveur les supporte. Le filtrage réseau est un risque récurrent : le port 853 est aisément bloqué par un pare-feu restrictif, ce qui peut provoquer un repli en clair si le client l’autorise. Interdire tout repli non chiffré préserve la confidentialité au prix d’une éventuelle panne de résolution.

La centralisation constitue un enjeu de gouvernance souvent sous-estimé : orienter toutes les requêtes vers un résolveur DoT public déplace la confiance vers cet opérateur, qui voit alors l’intégralité des noms résolus. On chiffre le trajet, mais on concentre la visibilité chez un acteur unique. Enfin, les certificats du résolveur doivent être surveillés : une expiration ou une mauvaise configuration côté serveur interrompt la résolution en mode strict, avec un impact direct sur la disponibilité de tout le réseau qui en dépend.

FAQ

Quelle différence entre DoT et DNS over HTTPS ?

Les deux chiffrent les requêtes DNS avec TLS. DoT utilise un port dédié, le 853, ce qui rend le trafic identifiable et administrable sur un réseau d’entreprise. DoH circule sur le port 443 mêlé au trafic web, ce qui maximise la confidentialité vis-à-vis d’observateurs réseau mais complique la supervision et le filtrage par les administrateurs. Le choix dépend donc de la priorité : contrôle réseau ou discrétion maximale.

DoT remplace-t-il DNSSEC ?

Non. DoT protège le canal de transport entre le client et le résolveur, tandis que DNSSEC signe les enregistrements pour authentifier les données depuis la zone d’origine. Les deux mécanismes couvrent des menaces différentes et se complètent : l’un sécurise le trajet, l’autre garantit le contenu.

Le mode opportuniste est-il suffisant ?

Le mode opportuniste protège uniquement contre l’écoute passive. Un attaquant en position d’interception active peut forcer un repli en clair ou présenter un faux résolveur. Le profil strict, qui exige la validation du certificat et du nom du résolveur, est nécessaire pour une protection complète.

Sur quel port fonctionne DoT ?

DoT écoute sur le port TCP 853, réservé à cet usage par l’IANA (Internet Assigned Numbers Authority, autorité d’attribution des numéros de l’Internet) à la demande du RFC 7858. Ce port distinct du 53 traditionnel sépare clairement le trafic DNS chiffré du trafic DNS en clair.

Conclusion

DoT apporte au DNS une protection qui lui manquait depuis sa conception : la confidentialité et l’authentification du transport. Correctement déployé en profil strict, sans repli en clair et avec un résolveur fiable, il élimine l’espionnage passif et l’usurpation de résolveur sur le chemin réseau. Il ne dispense pas de DNSSEC, qui protège l’authenticité des données à la source, ni d’une réflexion sur le choix de l’opérateur vers lequel on concentre ses requêtes. Le compromis principal reste la disponibilité : plus la politique est stricte, plus une défaillance de certificat ou un filtrage du port 853 devient bloquant. La bonne pratique consiste à combiner profil strict, connexions persistantes et supervision des certificats, en gardant à l’esprit que chiffrer le trajet ne dispense jamais d’authentifier la donnée.

🦫 Explication de la marmotte 🍫

Quand tu tapes l’adresse d’un site, ton ordinateur ne connaît pas directement où il se trouve. Il pose donc une question à un serveur spécial, une sorte d’annuaire géant, pour obtenir l’adresse exacte de la machine à contacter. Le problème, c’est que cette question voyageait historiquement sans aucune protection : n’importe qui sur le trajet — la personne qui gère le Wi-Fi d’un café, ton fournisseur d’accès, un pirate — pouvait lire quels sites tu cherchais, et même te renvoyer une fausse adresse pour te piéger.

DoT résout ce problème en mettant la question et la réponse dans un tube fermé à clé entre ton appareil et l’annuaire. Ce tube utilise le même système de verrouillage que celui qui protège tes achats en ligne. Deux choses se passent : d’abord ton appareil vérifie qu’il parle bien au véritable annuaire, grâce à une carte d’identité électronique que celui-ci présente ; ensuite tout ce qui circule est brouillé, illisible pour les curieux, et un cadenas numérique détecte la moindre modification en route.

Il existe une version « stricte » qui refuse de continuer si le tube ne peut pas être fermé correctement, et une version « souple » qui accepte de parler à découvert en cas de problème. La stricte est plus sûre. Attention : ce tube protège le trajet, mais si tu confies toutes tes questions à un seul annuaire, celui-ci voit tout ce que tu cherches — le choix de cet annuaire compte donc autant que le cadenas..