DNS-over-HTTPS en 2026 — quand ça aide et quand ça nuit

En résumé : le DNS classique envoie vos requêtes — chaque « quelle est l'IP d'example.com ? » — en clair via UDP, lisibles ou modifiables par n'importe qui sur le chemin réseau. DoH enveloppe ces requêtes dans HTTPS, de sorte que l'observateur sur le réseau ne voit plus les noms de domaine et ne peut plus injecter de fausses réponses. Cela résout trois problèmes réels (espionnage DNS par le FAI, injection DNS dans les cafés, certaines formes de censure DNS étatique) et en crée deux nouveaux (le contrôle parental et la sécurité d'entreprise cessent de fonctionner, et vous venez de confier à votre prestataire DoH chaque domaine que vous visitez). DoH n'est ni « plus privé » ni « moins privé » — il est différemment privé, et la question est de savoir quel compromis correspond à votre modèle de menace.

Ce qu'est réellement DoH (et ce qu'il remplace)

Le DNS classique est l'un des plus vieux protocoles encore en production. Il date de 1983, est antérieur à HTTPS généralisé, et a été conçu à une époque où « tout le monde sur le réseau est globalement de confiance » était une hypothèse raisonnable. Le principe : votre appareil envoie un paquet UDP au port 53 de votre résolveur DNS configuré (généralement celui de votre FAI, ou 8.8.8.8 / 1.1.1.1 si vous l'avez modifié). Le corps du paquet, en clair, dit « donne-moi l'enregistrement A pour example.com. » Le résolveur répond, en clair, avec l'IP. Trois propriétés méritent d'être soulignées :

• N'importe qui sur le chemin réseau peut lire la requête. Votre FAI, le WiFi du café, quiconque fait tourner tcpdump sur le réseau local — chaque nom de domaine que vous résolvez est en clair.
• N'importe qui sur le chemin réseau peut forger une réponse. S'il renvoie une fausse réponse à votre appareil avant que le vrai résolveur le fasse, vous avez été redirigé. C'est ainsi que fonctionnent certains portails captifs et certains régimes de censure.
• Votre résolveur configuré voit chaque requête. Celui qui gère votre DNS connaît chaque domaine que vous visitez, dans l'ordre, avec horodatage.

DoH (RFC 8484, 2018) modifie les points 1 et 2 : les requêtes transitent dans une connexion HTTPS chiffrée par TLS vers le résolveur. Les observateurs en chemin voient des octets HTTPS, pas des noms de domaine. La falsification devient aussi difficile que falsifier n'importe quelle réponse HTTPS (c'est-à-dire pratiquement impossible sans le certificat TLS du résolveur). Le point 3 ne change pas — le résolveur voit toujours les requêtes, car elles lui sont adressées. DoH déplace la frontière de confiance ; il ne la supprime pas.

DoT (DNS-over-TLS, RFC 7858) fait la même chose sur un port dédié (853) au lieu d'utiliser HTTPS sur le port 443. Des propriétés de confidentialité fonctionnellement équivalentes ; une mise en œuvre opérationnellement différente. DoH est plus difficile à bloquer au niveau réseau car le bloquer nécessite de bloquer HTTPS arbitraire, ce qui casse tout l'internet. DoT est plus facile à appliquer ou bloquer sélectivement par les opérateurs réseau. DoH a largement remporté la course au déploiement parce que Mozilla et Google l'ont intégré par défaut dans leurs navigateurs.

Trois choses que DoH résout vraiment

1. Espionnage DNS par le FAI

Aux États-Unis depuis 2017, les FAI sont légalement autorisés à vendre des données de navigation sans opt-in explicite, et les journaux de requêtes DNS font partie de ce qu'ils collectent. Dans d'autres pays, les régimes juridiques varient ; dans certains, la rétention obligatoire des données couvre le DNS par nom. Dans tous les cas : si vous utilisez le résolveur de votre FAI, celui-ci dispose d'un journal complet des sites que vous visitez, avec horodatage.

DoH vers un résolveur non-FAI (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9, NextDNS, AdGuard DNS, le DNS de Mullvad, le résolveur dans votre VPN) ferme cela complètement du point de vue de votre FAI. Le FAI voit toujours les connexions TLS vers des adresses IP spécifiques, et à partir de ces IP (plus le SNI dans le handshake TLS, voir ci-dessous) peut souvent en déduire le nom d'hôte — mais il n'a plus un journal DNS propre et interrogeable. La confiance passe du FAI à celui qui gère votre résolveur DoH.

2. Injection DNS dans les cafés

Les portails captifs sur les WiFi publics fonctionnent en interceptant les requêtes DNS (et les requêtes HTTP) et en les redirigeant vers une page de portail jusqu'à ce que vous acceptiez les conditions du réseau. Ce mécanisme — l'interception de votre DNS — a la même forme que l'injection DNS malveillante. Un réseau hostile peut réécrire vos réponses DNS pour vous rediriger vers des pages de phishing ou des proxys d'injection publicitaire. Le DNS en clair leur offre une surface d'attaque facile ; DoH la ferme.

C'est l'un des cas où DoH et un tunnel VPN se recoupent. Un VPN tunnelise tout, DNS compris, via des octets chiffrés ; DoH seul tunnelise uniquement les requêtes DNS. Sur un réseau hostile, l'une ou l'autre intervention neutralise la classe d'attaques par injection DNS, mais elles traitent des couches différentes. Nous avons couvert le paysage des menaces dans Attaques sur les WiFi publics en 2026.

3. Certaines formes de censure DNS étatique

Plusieurs régimes de censure mettent en œuvre un blocage au niveau DNS : lorsque vous demandez « quelle est l'IP de site-bloqué.com ? », le résolveur imposé par l'État renvoie NXDOMAIN ou redirige vers une page « ce site est bloqué ». DoH vers un résolveur hors de la juridiction censurante contourne ce mécanisme précis, car le réseau censurant ne voit que du HTTPS vers le résolveur DoH, pas les requêtes à l'intérieur.

La nuance : cela ne fonctionne que jusqu'à ce que le censeur intensifie ses mesures. Les régimes de censure sophistiqués (Chine, Iran) bloquent directement les résolveurs DoH par IP, forcent l'interception HTTPS via des autorités de certification racine imposées par l'État, ou utilisent le blocage basé sur le SNI (voir la section suivante). DoH contourne la censure DNS naïve ; il ne contourne pas la censure déterminée d'un État-nation.

Trois choses que DoH ne résout pas

1. Fuite SNI dans le handshake TLS

C'est le piège que la plupart des articles ignorent. Lorsque vous vous connectez à « example.com » via HTTPS, votre navigateur envoie le nom d'hôte en clair pendant le handshake TLS — précisément dans l'extension SNI (Server Name Indication). La raison : une seule IP héberge souvent de nombreux domaines via la terminaison TLS, et le serveur doit savoir quel certificat présenter avant que la session chiffrée commence. Le SNI est, par conception, en texte clair.

Conséquence concrète : même avec DoH, un observateur sur le réseau voit les noms d'hôtes auxquels vous vous connectez via SNI. La protection contre l'espionnage DNS est partielle. La solution est ECH (Encrypted Client Hello) — une extension TLS relativement récente qui chiffre le SNI. Cloudflare a activé ECH pour les sites derrière son réseau en 2023, et Firefox + Chrome ont ajouté le support, mais l'adoption hors de Cloudflare reste inégale. Tant qu'ECH n'est pas universel, DoH ne ferme qu'à moitié la question « qui peut voir quels sites vous visitez ».

2. Identification des destinations par IP

Même avec DoH et ECH, vos connexions TLS vont toujours vers des IP de destination spécifiques. Pour les sites avec une infrastructure dédiée (banques, services de niche), l'IP de destination est un identifiant quasi-parfait du site, même sans DNS ni SNI. Pour les sites derrière les grands CDN (Cloudflare, Fastly, AWS CloudFront), l'identification par IP est plus floue — des millions de sites partagent quelques IP — mais les plus grands sites ont toujours une infrastructure propre ou des schémas de trafic distinctifs.

DoH ne résout pas cela ; il ne peut pas. Un observateur réseau qui veut vraiment savoir quels sites vous visitez peut construire une table de correspondance IP-vers-domaine et consulter vos destinations de trafic. La solution est un tunnel VPN, qui déplace la visibilité de l'IP de destination du réseau local vers le fournisseur VPN. La confiance doit toujours se trouver quelque part ; DoH seul la laisse à l'opérateur réseau.

3. Votre fournisseur DoH voit tout ce que vous fuitiez à votre FAI

C'est le compromis que le marketing de DoH élude habituellement : DoH ne rend pas vos requêtes DNS privées ; il déplace la visibilité de votre FAI vers votre résolveur DoH choisi. Cloudflare (1.1.1.1), Google (8.8.8.8), Quad9, NextDNS, AdGuard et tout autre fournisseur DoH voient chaque requête que vous faites, exactement comme votre FAI le faisait auparavant. Certains publient des politiques strictes de non-journalisation ; certains publient uniquement une journalisation agrégée ; certains vendent des données agrégées à des « partenaires de recherche ». Le régime juridique autour de votre fournisseur DoH est aussi important que celui autour de votre FAI.

Le 1.1.1.1 de Cloudflare publie des rapports d'audit indiquant qu'ils suppriment les journaux après 24 heures et ne vendent pas les données DNS. Le 8.8.8.8 de Google journalise les requêtes (avec anonymisation) pour des périodes indéfinies selon leur politique de rétention déclarée. NextDNS vous permet de configurer votre propre rétention des journaux de « aucune » à « votre compte, votre choix ». Le choix du fournisseur DoH importe ; la question est de savoir quelle relation de confiance vous préférez — votre FAI sous les lois de votre pays, ou votre fournisseur DoH sous les lois du sien.

Deux choses que DoH casse légitimement

1. Contrôle parental et filtrage du réseau familial

La plupart des systèmes de contrôle parental grand public fonctionnent en inspectant le DNS au niveau du routeur ou via un résolveur DNS de filtre familial configuré (OpenDNS Family Shield, Cleanbrowsing Family, profil famille NextDNS). Quand l'appareil de votre enfant utilise ces résolveurs, les recherches pour du contenu adulte, des jeux d'argent, etc., renvoient NXDOMAIN. Le système dépend du fait que l'appareil interroge d'abord le résolveur de contrôle parental.

DoH au niveau du navigateur (Firefox a activé DoH par défaut en 2019 pour les utilisateurs américains ; Chrome et Edge utilisent le résolveur du système d'exploitation mais avec DoH si configuré) contourne silencieusement ces systèmes. Le navigateur interroge directement Cloudflare ou Google, le résolveur de filtre familial ne voit jamais la requête, et l'enfant accède au site qu'il souhaitait visiter. C'est voulu du point de vue de Mozilla (« nous ne devrions pas laisser les réseaux censurer ») ; c'est accidentel du point de vue d'un parent (« le filtre pour lequel on a payé vient de cesser de fonctionner »).

Des solutions existent mais sont complexes : configurer DoH au niveau du système d'exploitation (pas du navigateur) vers un résolveur conscient de la famille comme le profil famille NextDNS ou OpenDNS Family Shield, puis désactiver DoH au niveau du navigateur pour qu'il bascule sur le choix du système d'exploitation. Les Profils de configuration d'Apple et la Stratégie de groupe Windows le supportent tous les deux. Pour la plupart des foyers, c'est suffisamment compliqué pour représenter une vraie friction.

2. Sécurité d'entreprise et blocage des malwares au niveau réseau

La plupart des réseaux d'entreprise mettent en œuvre une sécurité basée sur le DNS : un serveur DNS sinkhole résout les domaines malveillants connus vers rien (ou vers une page d'alerte interne), bloquant les commandes et contrôles de malwares, les redirections de phishing et l'exfiltration de données vers des points de terminaison connus. Cela fonctionne parce que chaque appareil sur le réseau d'entreprise utilise le DNS d'entreprise, donc chaque résolution est filtrée.

DoH au niveau du navigateur contourne cela silencieusement. Un navigateur compromis qui devrait être bloqué pour ne pas atteindre son serveur C2 peut simplement résoudre le nom d'hôte C2 via DoH sur Cloudflare, obtenir la vraie IP, et se connecter directement. Les équipes IT d'entreprise ont répondu en : (a) configurant la politique du navigateur pour désactiver DoH, (b) déployant une inspection TLS complète afin que la pile de sécurité puisse voir à l'intérieur de HTTPS incluant le trafic DoH, ou (c) bloquant les IP connues des résolveurs DoH au pare-feu. Aucune de ces options n'est agréable — l'option (a) laisse les utilisateurs en DNS en clair à domicile aussi, l'option (b) nécessite d'installer un CA racine sur chaque appareil, l'option (c) se casse à mesure que de nouveaux points de terminaison DoH apparaissent.

DoH sur chaque plateforme — la configuration réelle

iOS 14+ / iPadOS 14+ : Réglages → Général → VPN & gestion des appareils → DNS — mais uniquement via un profil de configuration installé. iOS n'expose pas DoH dans l'interface Réglages standard ; vous installez un fichier .mobileconfig (Cloudflare, Quad9, NextDNS, AdGuard, Mullvad en publient tous). Une fois installé, chaque application de l'appareil utilise DoH vers ce résolveur. C'est voulu — iOS traite DoH comme un réglage au niveau du système d'exploitation, pas par application.

Android 9+ : Paramètres → Réseau & Internet → Avancé → DNS privé — mais il s'agit en réalité de DoT, pas de DoH. Android a mis en œuvre le « DNS privé » en utilisant DoT (port 853) plutôt que DoH (HTTPS). Des propriétés de confidentialité fonctionnellement équivalentes ; le protocole est différent. Entrez le nom d'hôte d'un résolveur DoT (one.one.one.one pour Cloudflare, dns.google pour Google, dns.adguard.com pour AdGuard) et Android chiffre chaque requête DNS à l'échelle du système.

macOS 11+ : même mécanisme de profil de configuration qu'iOS. Apple intègre son propre support DoH mais ne l'expose pas via les Préférences Système ; vous installez un profil.

Windows 11 : Paramètres → Réseau & Internet → propriétés de l'adaptateur → Attribution du serveur DNS → « Chiffré uniquement (DNS sur HTTPS) » — Windows connaît Cloudflare, Google et Quad9 par défaut et configure automatiquement DoH si vous définissez ces IP. Windows 10 supporte DoH mais il est plus difficile à trouver.

DoH au niveau du navigateur : Firefox active DoH par défaut pour les utilisateurs américains (Paramètres → Vie privée & sécurité → DNS sur HTTPS). Chrome l'appelle « DNS sécurisé » (Paramètres → Confidentialité et sécurité → Sécurité). Safari utilise la configuration au niveau de macOS plutôt qu'une configuration spécifique au navigateur. Edge utilise le niveau Windows. DoH au niveau du navigateur est rapide à activer mais crée le problème de contournement du contrôle parental / d'entreprise mentionné ci-dessus ; DoH au niveau du système d'exploitation place la décision en un seul endroit où elle peut être gérée.

Choisir un résolveur DoH — la comparaison honnête

Choisir votre résolveur DoH est la véritable décision de confidentialité que DoH vous permet de prendre. Les principales options :

• Cloudflare 1.1.1.1 : rapide (anycast, sous 15 ms dans la plupart des grandes villes), rétention des journaux 24 heures, audité annuellement. Dispose d'une variante « famille » (1.1.1.3) qui bloque les contenus adultes. Cloudflare propose également WARP, un VPN-lite qui combine DoH avec un tunnel vers le réseau de Cloudflare.
• Google 8.8.8.8 : rapide, omniprésent, rétention des journaux indéfinie selon la politique déclarée de Google. Confidentialité raisonnable selon les standards de Google, mais si « faire confiance à Google avec un flux de données supplémentaire » vous pose problème, regardez ailleurs.
• Quad9 9.9.9.9 : fondation suisse à but non lucratif, bloque par défaut les domaines malveillants connus, politique de non-journalisation déclarée, plus conservateur sur les données que la plupart.
• NextDNS : configurable par profil (listes de blocage, filtre familial, rétention des journaux) — le choix des utilisateurs avancés. Voir notre comparaison pour plus de détails.
• AdGuard DNS : bloque agressivement les publicités et traceurs au niveau DNS, supporte DoH et DoT.
• DNS de Mullvad : disponible en autonome (sans abonnement VPN requis), suédois, blocage de contenu configurable, accessible via DoH et DoT.
• Le résolveur de votre fournisseur VPN : Casper's Cloak, ProtonVPN (NetShield), Mullvad — DNS géré à l'intérieur du tunnel VPN, aucune configuration séparée requise. Pratique ; cela signifie faire confiance au fournisseur VPN pour les deux couches, ce qui est inévitable si vous utilisez un VPN de toute façon.

La formulation honnête : il n'y a pas de « meilleur » résolveur DoH ; il y en a un qui est meilleur pour votre modèle de menace. La vitesse importe pour certains, les listes de blocage pour d'autres, la politique de non-journalisation pour d'autres encore, la juridiction pour d'autres. Choisissez-en un, configurez-le au niveau du système d'exploitation (pas seulement du navigateur) pour que le choix couvre chaque application, et réévaluez lorsque vos priorités ou les rapports de transparence d'un résolveur changent.

La place de DoH avec les VPN et le blocage des publicités — la vue d'ensemble

Trois couches de confidentialité indépendantes, chacune fermant une surface d'attaque différente :

• Tunnel VPN : chiffre la visibilité de l'IP de destination depuis le réseau local, la déplace vers le fournisseur VPN. Ferme « le café / le FAI peut voir à quelles IP vous vous connectez ».
• DoH / DoT : chiffre les requêtes DNS depuis le réseau local et depuis le FAI, déplace la visibilité DNS vers le résolveur DoH. Ferme « le journal DNS chez le FAI » et « l'injection DNS au niveau réseau ».
• Filtrage de contenu au niveau DNS (Pi-hole, NextDNS, AdGuard DNS) : bloque les résolutions pour les publicités, traceurs, malwares, phishing — au niveau du résolveur. Ferme « chaque application de votre appareil charge des SDK de traceurs dont les points de terminaison pourraient être bloqués au niveau DNS ».

DoH seul est une couche. Une vraie posture de confidentialité empile les trois. Casper's Cloak est conçu pour délivrer cette pile en une seule application : tunnel VPN + filtrage DNS Pi-hole (nous gérons une instance Pi-hole par utilisateur comme résolveur) + détection de phishing zero-day basée sur le ML en plus des listes de blocage statiques. DoH est implicite dans la façon dont tout cela est câblé — les requêtes DNS entre l'appareil et notre résolveur sont chiffrées. La formulation honnête est que c'est une architecture valide parmi d'autres ; une autre consiste à « configurer DoH au niveau du système d'exploitation vers NextDNS, ajouter votre VPN de choix par-dessus, obtenir le même résultat final avec plus de réglages ». Les deux fonctionnent ; le compromis est commodité contre configurabilité. Nous avons couvert le même point sous l'angle du filtrage DNS dans Comment le filtrage au niveau DNS fonctionne réellement.

En résumé

DoH est une amélioration de confidentialité réelle et utile, avec des nuances absentes des brochures marketing. Il ferme l'espionnage DNS par le FAI, l'injection DNS dans les cafés et la censure naïve — trois vrais problèmes pour de vrais utilisateurs. Il ne ferme pas la fuite SNI, l'identification des destinations par IP, ni la confiance en votre résolveur choisi. Et il casse le contrôle parental et la sécurité d'entreprise dans des cas d'usage légitimes si vous ne configurez pas soigneusement.

La décision DoH la plus importante est de choisir quel résolveur utiliser, configuré au niveau du système d'exploitation pour que chaque application en bénéficie de manière cohérente. La deuxième décision la plus importante est de savoir si vous combinez DoH avec un tunnel VPN (ferme la visibilité de l'IP de destination) et un filtrage de contenu au niveau DNS (bloque les publicités/traceurs/résolutions de domaines malveillants). DoH seul résout une couche ; la pile unifiée couvre la surface entière.

À lire aussi : Comment le filtrage au niveau DNS fonctionne réellement couvre la couche de filtrage que DoH seul n'inclut pas ; Attaques sur les WiFi publics en 2026 couvre le modèle de menace d'hostilité réseau auquel DoH contribue ; VPN gratuit vs VPN payant en 2026 couvre la couche de tunnel VPN. La comparaison NextDNS et la comparaison Pi-hole approfondissent les choix de résolveurs DNS configurables.