Le système de noms de domaine (DNS) est souvent comparé à un annuaire téléphonique de l'internet. Sa fonction est essentielle : traduire un nom de domaine en adresse IP. Pourtant, depuis sa création en 1983 (RFC 1035), le protocole DNS originel, dit Do53, transmet chaque requête en texte clair sur le port 53. Cela signifie que, même lorsqu'un site web utilise le protocole HTTPS pour chiffrer le contenu de ses pages, la requête DNS qui précède la connexion reste nue et visible par toute entité située sur le chemin réseau.
Ce défaut de conception expose les utilisateurs à plusieurs menaces. Le fournisseur d'accès à internet (FAI) de l'internaute, un administrateur réseau sur un point d'accès Wi-Fi public ou une infrastructure de surveillance gouvernementale peuvent tous consulter la liste des domaines résolus. Pire encore, un attaquant peut intercepter la requête en clair pour rediriger la victime vers un site malveillant, une technique appelée détournement DNS (DNS hijacking). Des campagnes documentées, comme Sea Turtle (2019) ou le botnet DNSChanger, ont exploité cette faille. Le protocole HTTPS ne protège pas contre ce détournement si l'attaquant contrôle le résolveur et possède un certificat reconnu par la machine cible.
Pour remédier à cette vulnérabilité, plusieurs protocoles de DNS chiffré ont été développés. Quatre d'entre eux se distinguent aujourd'hui : DNS over TLS (DoT), DNS over HTTPS (DoH), DNS over QUIC (DoQ) et DNS over HTTPS/3 (DoH3). Chacun encapsule la requête DNS dans une couche de transport sécurisée, avec des compromis différents en matière de performance, de confidentialité et de compatibilité.
DNS over TLS (DoT) : le chiffrement dédié
Défini par la RFC 7858 en 2016, DoT enveloppe les requêtes DNS dans une session TLS (Transport Layer Security), la même technologie qui chiffre le trafic web. Il utilise un port dédié, le 853. Cette particularité est un avantage pour les administrateurs réseau, qui peuvent identifier et filtrer ce trafic spécifique, mais elle constitue aussi un inconvénient majeur : le trafic DoT peut être facilement détecté et bloqué par des pare-feux ou des FAI souhaitant restreindre l'usage d'un DNS alternatif.
En revanche, DoT bénéficie d'une large adoption côté client. Android 9 et iOS 14 intègrent nativement le support de DoT sous l'appellation « DNS privé ». Lorsqu'un visiteur utilise un appareil mobile récent, il est probable que ses requêtes DNS soient déjà chiffrées via DoT, indépendamment du serveur web consulté. La contrepartie est une latence accrue au premier échange : DoT nécessite une poignée de main TCP (triple temps d'aller-retour) puis une poignée de main TLS, ajoutant environ deux temps d'aller-retour de latence par rapport au Do53 classique.
DNS over HTTPS (DoH) : le camouflage dans le trafic standard
DoH a été formalisé par la RFC 8484 en 2018. Contrairement à DoT, il n'utilise pas de port dédié : il fait transiter les requêtes DNS par le port 443, celui du trafic HTTPS standard. Cette caractéristique rend le trafic DoH indiscernable du trafic web classique pour un observateur réseau, ce qui complique son blocage ciblé. Du point de vue de la vie privée, c'est un atout décisif face aux tentatives de censure ou de filtrage.
Les navigateurs web, en particulier, ont massivement adopté DoH. Firefox, Chrome et Edge proposent désormais des résolveurs DoH par défaut ou configurables. Cette adoption pose toutefois des questions de gouvernance : le choix du résolveur DoH (Cloudflare, Google, Quad9) concentre une grande partie des métadonnées DNS entre les mains de quelques acteurs. La performance de DoH est similaire à celle de DoT, la latence supplémentaire venant également de la poignée de main TLS.
DNS over QUIC (DoQ) et DNS over HTTPS/3 (DoH3) : la vitesse pour horizon
QUIC est un protocole de transport basé sur UDP, conçu pour réduire la latence de connexion. DoQ (RFC 9250, publiée en 2022) et DoH3 utilisent tous deux QUIC pour transporter le DNS. Leur principal avantage est l'élimination d'une partie de la latence de configuration : QUIC intègre le chiffrement et le contrôle de congestion dès le premier échange, en un seul temps d'aller-retour (voire zéro lors d'une reconnexion). Cela permet d'obtenir des performances plus proches de celles du Do53 non chiffré, tout en offrant le même niveau de sécurité.
DoQ et DoH3 sont toutefois encore en phase de déploiement. Tous les résolveurs publics ne les supportent pas, et la compatibilité avec les pare-feux d'entreprise ou les middleboxes peut être problématique en raison de l'utilisation du port UDP, qui est parfois filtré. Pour un serveur web hébergeant des sites à fort trafic, l'adoption de DoQ ou DoH3 est un levier potentiel pour réduire le temps de résolution DNS et améliorer l'expérience utilisateur, là où l'infrastructure le permet.
Performances : ce que disent les données
Selon les données de référence issues de plus de 3 000 résolveurs DNS testés, le Do53 classique reste le plus rapide, suivi de près par les protocoles basés sur QUIC (DoQ et DoH3). DoT et DoH affichent une latence supplémentaire de quelques millisecondes en moyenne, principalement due à la phase d'établissement de la session TLS. En conditions réelles, cette différence est souvent inférieure à la latence réseau globale et imperceptible pour l'utilisateur, mais elle devient significative sur les réseaux à forte latence ou pour les connexions fréquentes (nombreux sous-domaines, applications temps réel).
Quel protocole choisir pour son serveur ?
Le choix dépend du contexte. Dans un environnement interne ou en centre de données, le Do53 reste acceptable et simple. Pour un service web public, la recommandation est de basculer vers DoT ou DoH, en fonction des capacités du résolveur et de l'infrastructure. DoT est plus simple à auditer en entreprise (port dédié), tandis que DoH offre un meilleur camouflage. DoQ et DoH3 représentent l'avenir, là où le support est assuré.
Configuration côté serveur
Les serveurs web comme nginx peuvent être configurés pour utiliser un résolveur DNS chiffré en amont. Cloudflare propose par exemple un résolveur anycast supportant DoH et DoT. L'activation de DNSSEC (Domain Name System Security Extensions) sur le domaine, via un panneau comme cPanel, constitue un complément de sécurité indispensable pour authentifier les réponses DNS.
Limites de la protection
Le DNS chiffré ne résout pas tous les problèmes. Il ne protège pas contre un résolveur DNS compromis ou un fournisseur d'accès qui imposerait son propre résolveur. Il ne masque pas l'adresse IP du serveur visité, qui reste visible au niveau paquet. Enfin, il n'empêche pas l'analyse de trafic basée sur les métadonnées (taille, timing des requêtes). Les protocoles DoT, DoH, DoQ et DoH3 constituent une barrière nécessaire mais non suffisante contre la surveillance réseau.