Illustration générée par IA — visuel conceptuel.
Pourquoi ce sujet apparaît maintenant dans les projets Wi‑Fi (hôtel, bureau, villa)
Dans un établissement recevant des invités (hôtel, espaces événementiels, bureaux avec visiteurs, grande villa), le DNS est souvent un « outil d’exploitation » : il aide à appliquer un filtrage simple, à faire apparaître un portail captif, et à produire des journaux utiles pour le support. Or, de plus en plus de systèmes et navigateurs savent utiliser DNS over HTTPS (DoH) : les requêtes DNS passent alors dans un flux HTTPS chiffré. Le résultat est très concret : les mécanismes qui reposent sur l’observation ou la modification du DNS « en clair » deviennent moins visibles, moins pilotables, parfois inopérants.
Important : l’objectif ici n’est pas de décrire des techniques de contournement, mais de donner un cadre de décision et des options « propres » pour garder une expérience Wi‑Fi prévisible, tout en conservant un niveau de maîtrise proportionné (sécurité, support, conformité interne).
Pour resituer le sujet dans l’exploitation d’un Wi‑Fi visiteurs, vous pouvez aussi lire : Wi‑Fi invités : sécurité, portail captif, isolation et expérience client.
DoH, en pratique : ce que dit le standard (et ce que cela implique)
Le RFC de référence décrit DoH comme un transport des messages DNS « au-dessus » de HTTPS (voir RFC 8484 — DNS Queries over HTTPS (DoH)). Dans ses considérations opérationnelles, il souligne un point directement pertinent pour les réseaux gérés : les mécanismes de filtrage ou d’inspection qui s’appuient sur du DNS non sécurisé ne s’appliquent pas de la même manière en environnement DoH, du fait des protections apportées par TLS.
Traduction projet : si votre stratégie repose sur « voir le DNS en port 53 » (ou injecter des réponses DNS), vous devez accepter que certains terminaux, dans certaines configurations, échappent à ce levier dès lors qu’ils utilisent DoH vers un résolveur externe.
Trois impacts typiques côté bâtiment : filtrage, portail captif, journaux
Filtrage “par DNS” : une promesse plus difficile à tenir sur un réseau invité
Dans beaucoup de projets, le filtrage côté Wi‑Fi invités est volontairement simple : listes de domaines, catégories, SafeSearch, anti‑malware “DNS‑based”. Tant que le terminal interroge votre résolveur (ou votre service de filtrage DNS), la politique est visible. Avec DoH vers un résolveur tiers, ce n’est plus garanti.
Conséquence : si le filtrage fait partie d’un engagement d’exploitation (par exemple « Wi‑Fi famille »), il faut cadrer ce que vous garantissez réellement sur du BYOD, et sur quels périmètres vous pouvez être strict (terminaux gérés vs invités).
Portail captif : attention aux portails qui reposent sur des détournements DNS/HTTP
De nombreux portails captifs historiques “fonctionnent” en pratique en jouant sur DNS et/ou HTTP : renvoyer une adresse identique pour toutes les requêtes DNS, ou intercepter les requêtes HTTP et renvoyer un redirect. Le document de conception Chromium OS sur la détection de portails décrit explicitement ces schémas comme fréquents dans les portails d’hôtels, cafés ou aéroports (voir Chromium OS — Network Portal Detection).
Le risque avec DoH n’est pas uniquement « le portail ne s’affiche pas » : c’est surtout une variabilité d’expérience selon les terminaux (navigateur, OS, applications), car certains parcours d’onboarding supposent implicitement un DNS “pilotable”. Le RFC 8952 — Captive Portal Architecture rappelle d’ailleurs une limite structurelle : les solutions de portail captif qui affectent DNS/HTTP fonctionnent généralement comme prévu avec les navigateurs, mais peuvent casser d’autres applications utilisant ces protocoles, et les applications d’autres protocoles ne sont pas forcément alertées que le réseau est captif.
En environnement hospitality, cela se traduit souvent par des symptômes “terrain” : applications qui semblent « sans Internet » alors que le Wi‑Fi est associé, casting qui ne se comporte pas comme attendu, ou parcours de connexion qui dépend trop d’un seul mécanisme.
Journalisation DNS : utile pour le support… mais moins complète si une partie du DNS part en DoH externe
Beaucoup d’organisations s’appuient sur les journaux DNS pour diagnostiquer : « l’utilisateur a-t-il bien résolu tel domaine ? », « y a-t-il eu des requêtes suspectes ? », « quel équipement a tenté quoi ? ». Si une partie des terminaux envoie du DNS en DoH vers un service tiers, votre résolveur local ne verra pas ces requêtes : la journalisation “DNS‑centrée” perd en exhaustivité.
Point de gouvernance : ce n’est pas “plus de logs”, c’est “pas les bons logs au même endroit”. Il faut donc décider où placer l’observabilité (réseau, proxy/SWG, EDR, SIEM…), et ce qui est réellement nécessaire pour l’exploitation (support, sécurité, audit interne).
Réponses « propres » : options de conception plutôt qu’un bras de fer avec le BYOD
1) Séparer clairement les périmètres : invités vs métiers vs technique
La réponse la plus robuste (et la plus “bâtiment”) consiste souvent à limiter ce que vous attendez du réseau invité, et à renforcer ce qui compte sur les périmètres que vous maîtrisez :
- Invités (BYOD) : viser une expérience simple, stable, et une isolation réseau forte ; accepter que vous ne contrôlez pas le terminal (et donc pas complètement son DNS).
- Staff / back‑office : politiques de sécurité plus strictes, supervision, contrôle des postes.
- IoT bâtiment / GRMS / GTB / CCTV : segmentation, flux minimaux autorisés, et dépendances documentées.
Cette logique rejoint l’architecture globale d’un réseau hospitality. Voir : Architecture réseau IP d’un hôtel : faire cohabiter Wi‑Fi, IPTV, VoIP, CCTV et GRMS, ainsi que Cybersécurité d’un hôtel connecté : comment protéger GRMS, PMS, GTB et réseau ?.
Si vous cherchez une explication plus “méthode” sur la séparation des usages, vous pouvez aussi lire : VLAN : pourquoi séparer domotique, caméras, invités et équipements professionnels ?.
2) Concevoir le portail captif comme un service (parcours, compatibilité, modes dégradés)
Le message du RFC 8952 est utile à traduire en cahier des charges : un portail captif n’est pas seulement une redirection, c’est un service d’onboarding qui doit tenir face à des applications et OS variés.
Recommandations de projet (sans entrer dans des recettes techniques) :
- Éviter de dépendre d’un “détournement DNS” pour déclencher l’expérience de connexion ; à défaut, en connaître les limites.
- Tester le parcours avec plusieurs profils de terminaux (smartphones, laptops, objets de chambre, usages de salles de réunion) et pas seulement “un navigateur sur un PC”.
- Prévoir un mode secours exploitable par l’accueil ou le support (information simple, procédure, escalade), car la variabilité des terminaux est une donnée de base de l’hospitality.
Pour la partie “dépendances invisibles” (DNS/DHCP/RADIUS) qui peut aussi se confondre avec des symptômes liés au DNS chiffré, voir : Wi‑Fi d’hôtel en panne : vérifier DNS, DHCP et RADIUS.
3) Sur les équipements que vous gérez : poser une politique endpoint explicite sur DoH
Sur le périmètre géré (postes staff, tablettes d’accueil, équipements de salles, flotte entreprise), le bon levier est souvent la politique endpoint (MDM/AD/gestion navigateur) plutôt qu’une bataille sur le réseau invité.
- Microsoft Edge documente la stratégie DnsOverHttpsMode (off/automatic/secure) et détaille les comportements associés : Microsoft Edge — Policy DnsOverHttpsMode.
- Apple (MDM) documente le payload com.apple.dnsSettings.managed (protocole HTTPS ou TLS, Server URL) pour pousser des réglages de DNS chiffré sur les appareils supervisés : Apple — DNS Settings payload (MDM) et Apple device-management (spécification du payload).
Objectif : être cohérent. Soit vous désactivez DoH sur un périmètre donné (si votre politique interne l’exige), soit vous l’accompagnez avec un DNS chiffré sous contrôle (voir point suivant).
4) Proposer un DNS chiffré “sous gouvernance” (plutôt que subir un DoH tiers)
Dans certains contextes, la réponse la plus propre n’est pas d’empêcher le DNS chiffré, mais de fournir un DNS chiffré opéré/maîtrisé par l’organisation (en interne ou via service managé), surtout pour les segments staff et techniques. Microsoft décrit l’activation et le dépannage dans sa documentation sur le DNS chiffré et DoH : Microsoft Learn — DNS Encryption using DNS over HTTPS et Enable DNS over HTTPS in DNS Server.
Intérêt projet : vous conciliez confidentialité sur le Wi‑Fi (DNS chiffré) et exigences d’exploitation (split‑DNS, politiques internes, journalisation adaptée), au lieu d’avoir des terminaux qui “sortent” vers des résolveurs publics hétérogènes.
5) Tirer parti des mécanismes de “signal réseau” quand ils existent… sans les surestimer
Firefox documente des mécanismes pour éviter d’activer DoH par défaut sur des réseaux où il peut casser des fonctions locales (noms privés, filtrage, etc.). Mozilla décrit notamment le principe du canary domain use-application-dns.net et précise ses conditions et limites : il ne s’applique pas si l’utilisateur active DoH manuellement. Voir : Mozilla — Configure networks to disable DNS over HTTPS et Mozilla — Canary domain use-application-dns.net.
C’est une piste utile de gouvernance (surtout en environnements corporate), mais elle reste dépendante du navigateur et de son mode d’activation : on la considère comme un signal, pas comme un contrôle universel du parc invité.
Mini plan de tests (exploitation) : valider l’impact sans “sur‑ingénierie”
Avant de décider “bloquer vs accompagner”, un plan de tests simple évite les décisions théoriques. Voici une grille orientée exploitation (à adapter à votre contexte et à vos fournisseurs) :
| Ce que vous testez | Ce que vous observez | Limites à garder en tête |
|---|---|---|
| Onboarding portail captif (plusieurs OS/navigateurs) | Affichage de la page, stabilité de la session, réauthentification après veille | Un test « navigateur » ne couvre pas les apps non-navigateur ; le RFC 8952 souligne les limites des mécanismes DNS/HTTP pour ces cas. |
| Services sensibles côté client (casting, applis de réunion, streaming) | Découverte, connexion, comportement en “réseau captif” | Les symptômes peuvent être confondus avec des dépendances DNS/DHCP/RADIUS. |
| Filtrage annoncé sur Wi‑Fi invités | Écart entre filtrage “théorique” et filtrage réellement constaté | Avec DoH, les leviers DNS non chiffrés ne s’appliquent pas nécessairement (voir RFC 8484). |
| Observabilité (support) | Quels journaux sont vraiment exploitables lors d’un incident | La journalisation DNS n’est plus exhaustive si une partie du DNS part en DoH externe. |
À retenir (décisionnel)
- DoH chiffre le DNS dans HTTPS ; le RFC 8484 explique pourquoi les approches de filtrage/inspection basées sur du DNS non sécurisé deviennent moins opérables en environnement DoH.
- Les portails captifs “historiques” basés sur DNS/HTTP sont structurellement fragiles (compatibilité applicative) ; un DNS chiffré peut accentuer la variabilité d’expérience côté invité (voir RFC 8952).
- La réponse la plus robuste est souvent : segmentation (invités vs interne), politiques endpoint sur le périmètre géré, et éventuellement un DNS chiffré sous gouvernance plutôt qu’un DoH tiers.
Sources et documentation
- RFC 8484 — DNS Queries over HTTPS (DoH)
- RFC 8952 — Captive Portal Architecture
- Chromium OS — Network Portal Detection (principes et comportements observés)
- Mozilla — Configure networks to disable DNS over HTTPS ; Mozilla — Canary domain use-application-dns.net
- Microsoft Learn — DNS Encryption using DNS over HTTPS ; Enable DNS over HTTPS in DNS Server
- Microsoft Edge — Policy DnsOverHttpsMode
- Apple — DNS Settings payload (MDM) ; Apple device-management (spécification du payload)
Si vous préparez une rénovation ou un nouveau site, l’étape la plus efficace est souvent de formaliser ces choix dans un livrable d’exploitation (périmètres, politiques, tests et modes dégradés), puis de valider sur une zone pilote avant généralisation. Pour cadrer ce livrable, vous pouvez compléter avec : DOE et maintenance d’un hôtel connecté : que faut-il remettre à l’exploitant ?.
