À chaque adresse web saisie dans un navigateur, une question discrète est posée en coulisses : où se trouve réellement ce site ? Le DNS over HTTPS, souvent abrégé en DoH, change la manière dont cette question circule sur Internet. Derrière ce sigle technique se joue un débat très concret sur la confidentialité, la sécurité et le contrôle des connexions en ligne.
Le DNS over HTTPS est un protocole qui permet d’envoyer des requêtes DNS à travers une connexion HTTPS chiffrée. Le DNS, pour Domain Name System, sert à traduire un nom de domaine comme exemple.fr en adresse IP, compréhensible par les serveurs et les équipements réseau.
Traditionnellement, ces requêtes DNS circulent en clair, le plus souvent via le port 53. Cela signifie qu’un fournisseur d’accès à Internet, un administrateur réseau ou un acteur placé sur le chemin de la connexion peut voir les noms de domaines consultés. Avec DoH, ces échanges passent dans un tunnel HTTPS, comme une page web sécurisée.
Le DNS a été conçu à une époque où Internet reposait davantage sur la confiance entre réseaux que sur la protection systématique des échanges. Son rôle est essentiel, mais son fonctionnement historique laisse apparaître plusieurs faiblesses. Les requêtes peuvent être observées, filtrées ou parfois manipulées si elles ne sont pas protégées.
Dans la pratique, savoir quels domaines sont résolus permet de déduire une partie de l’activité d’un internaute, même sans connaître le contenu exact des pages consultées. Une requête vers le domaine d’un média, d’un service médical ou d’une plateforme professionnelle peut déjà révéler une information sensible. C’est l’une des raisons pour lesquelles le chiffrement du DNS a gagné en importance.
Lorsqu’un navigateur utilise DoH, il envoie la requête DNS à un résolveur compatible via le protocole HTTPS. Cette requête est encapsulée dans une connexion chiffrée avec TLS, le même mécanisme qui protège les sites affichant une adresse commençant par https://. Le serveur DoH répond ensuite avec l’adresse IP correspondant au nom de domaine demandé.
Ce fonctionnement s’appuie sur des standards publiés par l’IETF, notamment la RFC 8484, qui définit DNS over HTTPS. Pour mieux comprendre ce rôle des documents de standardisation, l’explication consacrée à la signification des RFC dans les standards Internet rappelle comment ces textes structurent l’évolution des protocoles utilisés au quotidien.
Le principal apport de DNS over HTTPS est de réduire la visibilité des requêtes DNS pour les intermédiaires réseau. Sur un Wi-Fi public, dans un hôtel ou dans un réseau partagé, il devient plus difficile d’observer simplement les domaines consultés à partir du trafic DNS brut. Ce n’est pas une anonymisation complète, mais une protection supplémentaire.
Il faut toutefois rester précis : DoH ne masque pas tout. L’adresse IP du serveur contacté peut rester visible, tout comme certains éléments liés à la connexion. De plus, le résolveur DoH choisi reçoit les requêtes DNS. La question de confiance ne disparaît donc pas ; elle se déplace vers l’opérateur du service DNS utilisé.
DoH suscite aussi des réserves. Dans les entreprises, les écoles ou les administrations, les équipes réseau s’appuient souvent sur le DNS pour appliquer des règles de sécurité, bloquer des domaines malveillants ou orienter certaines connexions internes. Si un navigateur contourne le résolveur DNS local au profit d’un service externe, ces contrôles peuvent être moins efficaces.
Autre point discuté : la concentration des requêtes DNS chez quelques grands fournisseurs. Si des millions d’utilisateurs basculent vers les mêmes résolveurs DoH, ces acteurs obtiennent une vision importante des habitudes de navigation. Le chiffrement protège contre certains regards, mais il ne supprime pas la nécessité d’une gouvernance claire des données.
Les principaux navigateurs modernes ont progressivement intégré DNS over HTTPS, parfois de manière automatique selon les pays, les réglages système ou le résolveur déjà utilisé. Firefox, Chrome, Edge et d’autres proposent des options pour activer, désactiver ou personnaliser le fournisseur DoH.
Cette évolution s’inscrit dans un mouvement plus large de sécurisation du Web, où plusieurs mécanismes interviennent à différents niveaux. La négociation des protocoles, par exemple, joue un rôle dans les performances et la compatibilité ; l’article sur la négociation ALPN dans HTTP/2 illustre bien cette logique d’ajustement automatique entre client et serveur.
Sur le plan des performances, DNS over HTTPS peut avoir des effets variables. Le chiffrement ajoute une couche technique, mais les navigateurs réutilisent souvent des connexions existantes et les résolveurs DoH rapides peuvent réduire certains délais. Dans de nombreux cas, l’utilisateur ne remarque pas de différence nette.
DoH cohabite avec d’autres évolutions du Web visant à rendre les échanges plus rapides et plus robustes. HTTP/3, par exemple, repose sur QUIC pour améliorer la gestion des connexions, notamment sur les réseaux mobiles ou instables. Le fonctionnement de QUIC utilisé par HTTP/3 montre comment les protocoles récents cherchent à réduire la latence tout en renforçant la fiabilité.
Pour les organisations, DNS over HTTPS impose de revoir certaines pratiques. Les politiques de filtrage, les outils de supervision et les protections contre les domaines frauduleux doivent être adaptés pour tenir compte des navigateurs capables d’utiliser des résolveurs externes. Certaines entreprises choisissent de désactiver DoH ou de l’orienter vers un résolveur interne contrôlé.
Le sujet rejoint plus largement les mécanismes de sécurité appliqués côté navigateur. Comme le montre le guide sur le mécanisme CORS dans les navigateurs, la sécurité web repose rarement sur une seule barrière. Elle combine des règles côté client, des politiques serveur, des standards ouverts et une configuration rigoureuse.
Pour un particulier, activer DoH peut être pertinent, surtout sur des réseaux publics ou peu fiables. Le choix du résolveur reste important : certains fournisseurs mettent en avant une politique de conservation limitée des journaux, d’autres privilégient la performance ou le filtrage de domaines malveillants. Il est utile de lire leurs engagements plutôt que de se limiter à une promesse générale de confidentialité.
Dans un cadre professionnel, la réponse dépend du contexte. Une activation non maîtrisée peut gêner les contrôles internes, tandis qu’un déploiement encadré peut améliorer la confidentialité sans affaiblir la sécurité. Cette nuance rappelle qu’un protocole ne règle pas tout à lui seul ; l’exemple du protocole SMTP face au spam montre qu’un standard historique doit souvent être complété par des politiques, des filtres et des pratiques opérationnelles.
En résumé, DNS over HTTPS rend les requêtes DNS plus discrètes et plus difficiles à intercepter, mais il ne transforme pas la navigation en activité anonyme. C’est une brique de sécurité utile, à condition de comprendre ce qu’elle protège, ce qu’elle ne protège pas et à qui l’on confie la résolution des noms de domaine.
