Le DNS over HTTPS expliqué : confidentialité ou filtrage du WiFi public
Le DNS over HTTPS chiffre les requêtes au sein du trafic du port 443. Découvrez ce qu'il masque, pourquoi il peut contourner le filtrage WiFi et comment les réseaux conservent le contrôle.
Published 26 octobre 2026
Le DNS over HTTPS envoie les recherches DNS au sein du trafic HTTPS ordinaire sur le port 443, chiffré entre l'appareil et le résolveur, et est devenu une norme IETF en 2018.
Vous avez activé le filtrage de contenu sur votre WiFi invité, mais le navigateur d'un invité ouvre toujours une catégorie que vous pensiez avoir bloquée. Le pare-feu fonctionne, les paramètres réseau semblent corrects et un autre appareil affiche bien la page de blocage attendue. La différence réside peut-être dans le résolveur interrogé par le navigateur, et non dans l'efficacité de votre filtre.
Pour les exploitants de sites et les responsables IT, c'est le problème central du DoH. Il protège une recherche pendant son acheminement, mais le choix de destination du navigateur peut également faire sortir cette recherche de la politique de filtrage de votre réseau.
Table des matières
- Ce que signifie le DNS over HTTPS en termes simples
- Comment une requête DoH voyage de l'appareil au résolveur
- Qui peut voir vos requêtes lorsque le DoH est activé
- Pourquoi le DoH affaiblit le filtrage DNS sur le WiFi partagé
- Ce que le DoH coûte en vitesse et ce que le filtrage continue de faire
- Vérifier et modifier le DoH sur les appareils courants
- Choisissez et superposez vos contrôles DoH
Ce que signifie le DNS over HTTPS en termes simples
Le DNS over HTTPS, généralement abrégé en DoH, achemine les questions et réponses DNS via une connexion web chiffrée. Un résolveur DNS est le service auquel un appareil demande de traduire un nom de domaine en adresse réseau.
Considérez le DNS comme un annuaire téléphonique. Avant d'établir une connexion, une application a besoin d'une adresse, bien qu'elle puisse déjà disposer d'une réponse utilisable dans son cache. Le DNS traditionnel envoie généralement cette requête sous une forme lisible.
Une carte postale est une analogie utile : quiconque la manipule peut lire le message. DoH place la demande dans une enveloppe scellée et la transporte dans le même type de véhicule de livraison utilisé pour le trafic web sécurisé ordinaire.
Comparez le transport, pas seulement le chiffrement
Le DNS over TLS, ou DoT, sécurise également le message, mais utilise un port d'entrée étiqueté séparément. Cela rend son trafic plus facile à identifier par un opérateur réseau grâce à son port de destination.
L'RFC 8484 de l'IETF, publié en octobre 2018, définit l'échange HTTPS de DoH, en utilisant généralement le port 443, contrairement au DNS traditionnel sur le port 53.
Comparaison entre DNS traditionnel, DNS over TLS et DNS over HTTPS
| Fonctionnalité | DNS traditionnel | DNS over TLS (DoT) | DNS over HTTPS (DoH) |
|---|---|---|---|
| Transport | UDP ou TCP | TLS | HTTPS |
| Port habituel | 53 | 853 | 443 |
| Lisible par le réseau local | Oui | Non | Non |
| Facile à repérer par le port | Oui | Oui | Non, partage le port 443 avec le trafic web |
| Facile à bloquer par le port | Oui | Oui | Non, pas de manière sélective par le port seul |
| Défini dans | Spécifications DNS d'origine | Spécification DNS over TLS | RFC 8484 |
Le blocage d'un port DNS dédié est simple. Bloquer le port utilisé par les sites web sécurisés stopperait également le trafic web légitime, DoH nécessite donc des contrôles plus sélectifs.
Le chiffrement ne détermine pas ce qui est filtré. Un résolveur peut déchiffrer une requête DoH entrante, appliquer une règle de contenu ou de sécurité, et renvoyer sa réponse de manière sécurisée. Les questions essentielles sont de savoir qui exploite ce résolveur et quelles règles il applique.
Gardez cette comparaison à portée de main lors de la révision des contrôles. Une règle qui gère le DNS traditionnel ou DoT ne gère pas automatiquement DoH.
Comment une recherche DoH circule de l'appareil au résolveur
Un coursier a besoin d'une adresse avant de livrer un colis. De même, un navigateur a besoin d'une adresse de destination avant de pouvoir se connecter à une page de réservation d'hôtel, à moins qu'il n'ait déjà cette réponse en cache.
Ce schéma suit la recherche du navigateur vers le résolveur et inversement.
Suivre la requête et la réponse
Le navigateur a besoin d'une adresse. Il vérifie s'il dispose déjà d'une réponse utilisable pour le site de réservation. Une mise en cache permet d'éviter complètement une nouvelle recherche, le réseau local ne verra donc aucun échange DNS pour cette action.
Il formule une requête DNS. S'il a besoin d'une réponse récente, le navigateur prépare une requête contenant le nom de domaine. À ce stade, la question se trouve toujours dans l'appareil et ne circule pas sur le WiFi.
Il sélectionne le résolveur DoH. Le navigateur prépare une requête HTTPS pour son résolveur configuré. Le réseau local peut observer l'adresse de destination et les métadonnées de connexion, mais il ne peut pas lire directement le domaine à l'intérieur du message DNS chiffré.
Il établit ou réutilise une connexion sécurisée. Si nécessaire, l'appareil effectue une poignée de main TLS avant d'envoyer la requête protégée. Avec une connexion HTTP persistante, les requêtes ultérieures peuvent réutiliser cette connexion ; le réseau voit un trafic chiffré, y compris sa chronologie et sa taille.
Le résolveur renvoie la réponse. Le résolveur traite la question et insère la réponse DNS dans une réponse HTTP chiffrée. Le réseau peut voir le trafic revenir du résolveur, mais pas le contenu lisible de la réponse.
Le navigateur se connecte au site web. Il utilise l'adresse renvoyée pour démarrer la connexion au site web. Le réseau local peut observer cette nouvelle destination, ce qui est distinct de la lecture de la requête DNS précédente.
Pour plus de détails sur la mise en cache et la résolution, l'explication du rôle d'une recherche DNS sépare le processus de recherche d'adresse de la connexion au site web lui-même.
Identifiez le point de filtrage
Pour une nouvelle connexion nécessitant une résolution DNS, la recherche s'effectue avant le chargement du contenu de la page. Cela donne au résolveur approuvé l'opportunité de refuser une destination bloquée avant que le navigateur ne se connecte.
Un navigateur configuré de manière indépendante peut envoyer cette décision ailleurs. Le résolveur du lieu ne reçoit alors aucune requête à évaluer.
La vidéo d'accompagnement offre un autre moyen de suivre le processus.
Qui peut voir vos recherches lorsque le DoH est activé
Le DoH ne masque pas la navigation à tout le monde. Il protège l'échange DNS contre les observateurs ordinaires entre l'appareil et son résolveur sélectionné, mais ce résolveur doit lire la requête pour pouvoir y répondre.
Cette distinction a son importance sur un réseau WiFi partagé. Un invité peut légitimement souhaiter une protection contre l'interception locale, tandis qu'un hôpital ou une école a besoin de garanties que ses contrôles de protection et de sécurité restent applicables.
Le DoH modifie l'entité à laquelle vous confiez votre activité DNS ; il ne supprime pas la nécessité d'accorder votre confiance.
Séparer la visibilité DNS de la visibilité de navigation
Le tableau décrit l'utilisation ordinaire du DoH sans relais de confidentialité supplémentaire, VPN ou système d'interception. Lire un message DNS et déduire une destination à partir d'une autre activité réseau sont des fonctionnalités différentes.
Qui peut voir les recherches DNS lorsque le DoH est utilisé
| Observateur | Voit les noms de domaine | Voit que le DoH est utilisé | Pourquoi c'est important |
|---|---|---|---|
| Autres appareils sur le même WiFi | Non, pas à partir de la requête chiffrée | Rarement via un accès réseau local ordinaire | La lecture passive du message DNS est bloquée |
| Réseau du site ou du FAI | Non, pas à l'intérieur de l'échange DoH | Souvent, via le trafic vers une adresse de résolveur connue | Les contrôles DNS locaux ne peuvent pas évaluer les requêtes envoyées ailleurs |
| Sites web que vous visitez | Uniquement le site auquel vous vous connectez | Pas uniquement à partir de la connexion au site web | Un site ne reçoit pas vos requêtes DNS non liées |
| Opérateur du résolveur DoH | Oui, chaque requête qu'il reçoit | Oui | Une connexion directe expose ces requêtes aux côtés de votre adresse source |
| Éditeur du navigateur ou du système d'exploitation | Uniquement s'il exploite le résolveur ou reçoit une télémétrie pertinente | Le logiciel connaît son mode configuré ; le signalement à l'éditeur nécessite la télémétrie | La configuration logicielle n'est pas équivalente à une visibilité automatique de l'éditeur |
Le résolveur ne voit pas nécessairement toutes les recherches effectuées par l'appareil. Une autre application peut utiliser un résolveur différent, et les réponses en cache peuvent ne nécessiter aucune requête. Il ne voit que les requêtes qui lui sont directement envoyées.
De même, l'éditeur du navigateur ne reçoit pas automatiquement l'historique DNS au seul motif qu'il fournit le navigateur. Le fonctionnement du résolveur, les paramètres logiciels et la collecte de télémétrie sont des fonctions distinctes.
Rendre la décision de confiance explicite
Pour les installations Firefox gérées, la documentation des règles DNS over HTTPS de Mozilla fournit des contrôles pour la configuration du résolveur et la possibilité pour les utilisateurs de la modifier. C'est un moyen pratique d'aligner le comportement du navigateur avec la gouvernance DNS d'une organisation.
Un établissement ou un FAI peut toujours observer les adresses de destination, l'horodatage des connexions et les volumes de trafic. D'autres métadonnées de protocole peuvent également aider à identifier un site, de sorte qu'une requête DNS chiffrée ne garantit pas une navigation anonyme.
Utilisez une évaluation rapide de la confiance avant d'approuver un résolveur :
- Identifiez l'opérateur. Établissez quelle organisation reçoit les requêtes, plutôt que de vous fier à l'étiquette par défaut d'un navigateur.
- Lisez les conditions de conservation. Vérifiez quelles informations de requête et de connexion sont stockées, pendant combien de temps et dans quel but.
- Vérifiez la juridiction et l'accès. Comprenez où l'opérateur traite les informations et qui peut les obtenir.
- Alignez la visibilité sur la responsabilité. Décidez quels événements de sécurité votre équipe informatique doit analyser et quelles données de navigation elle ne doit pas conserver.
La question utile n'est pas de savoir si la confidentialité ou la gérabilité importe le plus dans l'absolu. Il s'agit de savoir si le chemin DNS que vous avez choisi offre aux utilisateurs une confidentialité appropriée tout en permettant à l'organisation de remplir ses responsabilités énoncées.
Pourquoi le DoH affaiblit le filtrage DNS sur le WiFi partagé
Un hôtel donne aux clients le numéro de la réception pour les aider à trouver des services locaux. La plupart des clients appellent le bureau, mais un autre client utilise plutôt une application d'annuaire. La réception peut contrôler ses propres recommandations, mais pas les réponses fournies par cette application.
Le DNS réseau fonctionne de manière similaire. Votre réseau fournit un résolveur, mais un navigateur disposant de sa propre configuration DoH peut interroger un service externe à la place.
L'illustration montre cet itinéraire alternatif autour du bureau DNS du réseau.
Le contournement concerne l'itinéraire
Le problème n'est pas qu'une requête chiffrée ne puisse jamais être filtrée. C'est que votre filtre ne peut pas appliquer de règle à une requête qu'il ne reçoit jamais.
Sur le réseau invités d'une attraction familiale, cela pourrait signifier qu'un blocage de contenu pour adultes ne s'applique pas à un navigateur particulier. Sur un réseau du personnel, une application malveillante pourrait résoudre un domaine de commande et contrôle via un résolveur non approuvé.
Les conséquences dépendent des contrôles qui reposent sur le DNS :
- Politiques spécifiques au réseau. Les règles attribuées à un SSID ou un VLAN ne régiront pas les requêtes envoyées en dehors du chemin du résolveur approuvé.
- Restrictions de recherche. L'application du contrôle parental (Safe Search) basé sur le DNS peut être contournée, bien que des restrictions au niveau du compte ou du point d'accès puissent toujours s'appliquer.
- Blocage des menaces. Un filtre DNS ne peut pas refuser une requête qu'il ne voit pas, même si sa liste de menaces contient le domaine demandé.
Une étude de mesure du déploiement du DNS chiffré fait état de données de télémétrie Firefox selon lesquelles environ 13,91 % des 9,54 mille milliards de handshakes sur ordinateur utilisaient DoH en 2025. Elle décrit également un ensemble de données dans lequel DoH était environ 6,4 fois plus répandu que DoT.
Ces observations ne permettent pas d'établir la proportion d'appareils qui contournent le filtre de votre établissement. Les paramètres par défaut des navigateurs, le déploiement régional, la compatibilité des résolveurs et les politiques d'administration influent tous sur l'activation du DoH.
Testez la couverture plutôt que de la supposer
Un blocage réussi sur un ordinateur portable du personnel ne prouve pas une couverture équivalente sur le téléphone personnel d'un invité. Les appareils peuvent utiliser des navigateurs, des paramètres DNS ou des tunnels différents.
Traitez votre filtre de contenu WiFi comme un contrôle disposant d'un chemin de trafic défini. Testez ce chemin à l'aide des appareils et des applications que vos visiteurs apportent avec eux.
Le filtrage basé uniquement sur le résolveur fourni par le réseau ne constitue plus une couverture complète par défaut. Il nécessite des contrôles d'assistance et un état des lieux réaliste de ce qui reste en dehors des règles de gestion.
Ce que le DoH coûte en vitesse et ce que le filtrage continue de faire
Le chiffrement ajoute de la charge, mais la question pratique est de savoir si les utilisateurs remarquent une session plus lente. La configuration initiale de la connexion et les recherches répétées ont des coûts différents, c'est pourquoi tester une seule nouvelle requête peut donner une fausse impression.
Une comparaison empirique des transports DNS a révélé des réponses UDP et TLS inférieures à 1 milliseconde dans son environnement local de référence sans délai, tandis que HTTP/2 restait constamment sous la barre des 10 millisecondes ; les résultats ci-dessous conservent le contexte expérimental de l'étude plutôt que de prédire les performances réelles sur site.
Latence de recherche DNS par protocole dans l'étude citée
| Protocole | Résultat signalé | Contexte |
|---|---|---|
| UDP | Moins de 1 ms | Référence locale sans délai |
| TLS | Moins de 1 ms | Référence locale sans délai |
| HTTP/2 | Moins de 10 ms, de manière constante | La réutilisation des connexions et le multiplexage aident à réduire la charge globale |
| HTTP/1.1 | Fluctue considérablement | Attribué aux limites du pipelining |
| DoH public par rapport au DNS traditionnel | Plus lent par nom | Aucune augmentation significative du temps de chargement global de la page n'a été observée |
Mesurez la session, pas seulement le handshake
Les connexions persistantes permettent à un client de répartir les coûts de configuration sur les requêtes ultérieures. Le multiplexage lui permet de gérer plusieurs échanges sans établir de connexion sécurisée distincte pour chaque demande.
Le filtrage DNS peut toujours refuser un domaine avant qu'une nouvelle connexion ne commence, à condition que la requête atteigne le résolveur de filtrage. Le blocage des publicités et des traqueurs peut réduire les requêtes ultérieures, mais le chiffrement seul ne supprime pas les publicités et n'accélère pas une page.
Suivez les signaux opérationnels qui révèlent de vrais problèmes :
- Échecs de handshakes. Recherchez les erreurs de configuration de connexion et les tentatives de réessais.
- Taux de succès de la mise en cache. Séparez les réponses en cache de la résolution récente.
- Temps de réponse du résolveur. Mesurez le comportement pendant les sessions visiteurs chargées.
- Comportement de secours (fallback). Vérifiez si les échecs entraînent l'arrêt de la résolution sur les appareils ou leur basculement vers une autre voie sans préavis.
Règle pratique : Testez la navigation, l'application des politiques et la reprise après panne ensemble, et non comme des vérifications de recette séparées.
Un point de terminaison de résolveur résilient et proche est un meilleur point de départ que le choix d'un protocole basé uniquement sur des hypothèses de latence. Confirmez le résultat sur votre réseau sous une charge réaliste.
Vérifier et modifier le DoH sur les appareils courants
Un paramètre du navigateur peut expliquer pourquoi des appareils sur le même réseau WiFi se comportent différemment. Les libellés des menus changent entre les versions, utilisez donc la recherche dans les Paramètres si le chemin ci-dessous n'est pas visible.
Inspecter le navigateur et le système d'exploitation
- Chrome : Ouvrez Paramètres, Confidentialité et sécurité, Sécurité, puis Utiliser un DNS sécurisé. Vérifiez s'il suit le fournisseur actuel ou s'il spécifie un autre service.
- Firefox : Ouvrez Paramètres, Vie privée et sécurité, puis DNS via HTTPS. Vérifiez le mode de protection, y compris Désactivé, Protection par défaut ou Protection maximale, ainsi que le résolveur sélectionné.
- Edge : Ouvrez Paramètres, Confidentialité, recherche et services, Sécurité, puis Utiliser un DNS sécurisé. Une politique gérée peut verrouiller ce paramètre.
- Android : Ouvrez Paramètres, Réseau et Internet, puis DNS privé. Ce paramètre utilise DoT plutôt que DoH ; le DNS sécurisé au niveau du navigateur nécessite une vérification distincte.
- iOS et macOS : Inspectez les profils de configuration installés, les paramètres de gestion des appareils et les applications liées au DNS. Un profil DNS chiffré peut fonctionner indépendamment du navigateur.
Vérifiez le chemin effectif
Un VPN système peut acheminer le DNS à travers son propre tunnel, quel que soit le paramètre du navigateur. Vérifiez également si une application fournit un service DNS chiffré séparé.
Confirmez quel résolveur reçoit une nouvelle recherche de test effectuée depuis le navigateur ou l'application. Utilisez les diagnostics du navigateur ou un test d'identification du résolveur en parallèle des journaux du résolveur approuvé, plutôt que de vous fier uniquement à l'écran des paramètres.
Choisissez et superposez vos contrôles DoH
Superposez les contrôles en fonction de la propriété des appareils et des besoins d'application des règles. Les ordinateurs portables gérés du personnel peuvent suivre une configuration imposée ; les téléphones personnels des invités ne le peuvent généralement pas. Appliquer les mêmes restrictions aux deux groupes crée soit des failles évitables, soit des dysfonctionnements inutiles.
Vous pouvez autoriser le DoH externe et accepter une visibilité DNS locale réduite, le restreindre et accepter des risques de compatibilité, ou combiner des règles pour appareils gérés avec des contrôles sélectifs sur le réseau invité. L'approche par couches vous offre une vision plus claire de ce qui est protégé et de ce qui ne l'est pas.
Associez chaque contrôle à son périmètre réel
Les contrôles réseau sont utiles, mais ils ne permettent pas d'identifier chaque résolveur chiffré. Un résolveur privé, une adresse changeante ou un tunnel VPN peuvent déjouer les hypothèses basées sur une liste de services connus.
Contrôles pour le DoH sur les réseaux partagés et gérés
| Contrôle | Ce qu'il bloque | Où il s'applique | Compromis |
|---|---|---|---|
| Bloquer le port sortant 853 | DNS over TLS sur port standard | Pare-feu ou passerelle | Aucun effet sur le DoH via HTTPS ordinaire |
| Forcer le port 53 vers le résolveur réseau | Contournement du DNS en clair | Application au niveau de la passerelle, prise en charge par la configuration DHCP | Ignore totalement le DoH ; le DHCP seul ne garantit pas la conformité |
| Bloquer les adresses de résolveurs DoH publics connus | Connexions aux résolveurs répertoriés | Pare-feu ou passerelle compatible | Les listes deviennent obsolètes, de nouveaux résolveurs apparaissent, certaines applications s'arrêtent de fonctionner |
| Désactiver le DoH du navigateur par stratégie gérée | Contournement au niveau du navigateur dans les navigateurs couverts | Ordinateurs portables gérés et appareils du personnel | Ne peut pas atteindre les téléphones personnels sur le WiFi invité |
| Imposer le résolveur réseau via MDM | Modifications DNS non approuvées couvertes par la stratégie d'appareil | Appareils enregistrés du personnel et de l'entreprise | Nécessite une inscription et la prise en charge de la plateforme ; les invités restent en dehors de ce périmètre |
| Accepter le DoH et filtrer sur le point d'accès | Rien du côté réseau | Points d'accès gérés uniquement | Les appareils invités restent en dehors de la stratégie du point d'accès |
Le blocage de l'adresse d'un résolveur peut également bloquer des services non liés hébergés à cette adresse. Évitez de traiter la catégorie DNS chiffré d'un pare-feu comme un inventaire permanent et exhaustif.
Lorsque vous avez besoin d'un contrôle allant au-delà de la résolution de domaine, évaluez une passerelle web sécurisée aux côtés des politiques de réseau et d'équipements terminaux. Vérifiez attentivement les exigences de déploiement, en particulier lorsque les appareils n'appartiennent pas à l'entreprise.
Élaborez une politique d'exploitation verifiable
Commencez par le service que vous devez fournir. Un réseau d'administration pour le personnel, une connexion de bibliothèque publique et un lieu d'activités pour enfants peuvent légitimement nécessiter des restrictions différentes et des explications distinctes pour les utilisateurs.
Utilisez cette liste de contrôle de déploiement :
- Lister les politiques requises. Identifiez les SSID, les VLAN et les groupes d'équipements qui nécessitent des contrôles de contenu ou un filtrage des menaces, puis attribuez un responsable à chacun.
- Séparez les équipements gérés des appareils personnels (BYOD) des visiteurs. Consignez les cas où une politique de navigateur ou un MDM peut être appliqué et ceux où seuls des contrôles réseau sont disponibles.
- Fermez les voies de contournement DNS ordinaires. Lorsque votre politique l'exige, bloquez le DoT sortant et restreignez le DNS traditionnel au résolveur approuvé. Couvrez les deux familles d'adresses réseau prises en charge.
- Appliquez une politique de navigateur géré. Configurez le chemin DNS approuvé et empêchez les modifications non autorisées par les utilisateurs sur le matériel du personnel.
- Maintenez les restrictions du résolveur sur le réseau visiteurs. Examinez régulièrement les adresses de résolveurs bloquées, testez les exceptions et supprimez les règles qui provoquent un blocage collatéral inacceptable.
- Publiez une notice claire pour les visiteurs. Expliquez quelles catégories sont filtrées, quelles informations réseau sont enregistrées et les éventuelles restrictions concernant l'utilisation de DNS chiffré ou de VPN.
- Testez un appareil réel sur chaque réseau. Vérifiez les sites autorisés, les catégories bloquées, les destinations de test de sécurité approuvées, les pannes de résolveur et le comportement des VPN.
Avant le lancement : Une page de blocage prouve qu'une requête particulière a été filtrée, non que chaque application de l'appareil suit le même itinéraire.
Intégrer le DNS chiffré aux tests de recette
Pour utiliser Shield, vous orientez le DNS du réseau vers Shield. Nous répondons à chaque requête DNS sur le réseau que nous protégeons, sur chaque appareil, sans rien à désactiver sur l'équipement ; les chemins de résolveurs externes et de tunnels doivent donc être intégrés dans la conception de la protection du réseau.
Avant que vous ne testiez Shield, notre expert vous montre comment votre réseau gère les VPN et le DNS chiffré. Utilisez cette discussion pour déterminer quelles requêtes atteignent le chemin DNS protégé, quelles commandes l'appliquent et ce qui se passe lorsqu'un appareil tente un autre itinéraire.
Définissez des critères d'acceptation avant de modifier l'accès invité. Un résolveur approuvé, un processus d'exception documenté et des tests d'appareils répertoriables offrent une base plus solide que d'assumer qu'un filtre activé voit tout.
Purple Shield offre un DNS protecteur, un filtrage de contenu, une défense contre les menaces et un blocage des publicités sans installer d'agents sur les appareils invités. Consultez Purple Shield pour organiser un échange préalable à un essai concernant vos SSID, vos règles de filtrage et la manière dont votre réseau gère le DNS chiffré et les VPN.