DNS sécurisé sur Windows : DoH/DoT — Ce qui fonctionne réellement

Ce que « DNS sécurisé » signifie réellement sur Windows

Le DNS est le service d’annuaire que toute votre pile considère comme fiable… jusqu’à ce qu’il ne le soit plus. Le DNS traditionnel utilise majoritairement UDP/53, sans authentification, et il est souvent observable ou manipulé en transit. « DNS sécurisé » signifie généralement l’un des deux transports :

• DoT (DNS over TLS) : messages DNS dans TLS, typiquement TCP/853. Ça ressemble à « une chose DNS » sur le réseau. Plus facile à identifier et à bloquer ; parfois plus simple à autoriser de façon intentionnelle.
• DoH (DNS over HTTPS) : messages DNS dans HTTPS, typiquement TCP/443. Se fond dans le trafic web. Idéal pour contourner les portails captifs et les middleboxes mal conçus ; aussi excellent pour contourner votre politique DNS d’entreprise si vous n’y prenez pas garde.

Ni DoH ni DoT ne rendent automatiquement le DNS « digne de confiance ». Vous pouvez toujours interroger un résolveur qui ment. Vous pouvez toujours fuir des requêtes via un mécanisme de repli. Et vous pouvez toujours casser la résolution de noms internes en envoyant des zones privées à des résolveurs publics. Le chiffrement du transport est une couche : il protège la confidentialité et l’intégrité en transit, mais ce n’est pas de la gouvernance.

Sur Windows, « DNS sécurisé » a une signification opérationnelle précise : le client DNS de Windows (Dnscache) envoie des requêtes à un résolveur configuré en utilisant DoH (et dans certains cas retombe en repli). DoT n’est pas l’histoire principale au niveau OS que l’on voit sur d’autres plateformes ; vous le rencontrerez davantage dans des clients dédiés, des appliances, ou quand une entreprise exploite ses propres forwarders compatibles DoT.

Et puis il y a le troisième axe : les navigateurs. Chrome, Edge et Firefox peuvent exécuter leur propre DoH indépendamment des paramètres Windows, selon la politique et la configuration. Vous pouvez donc « activer DoH sur Windows » et avoir quand même des applications qui le contournent. Ou le désactiver et voir des navigateurs continuer. C’est la partie où votre équipe conformité développe soudain un vif intérêt pour les captures de paquets.

Une règle opérationnelle : si vous ne pouvez pas prouver quel résolveur a répondu et par quel transport, vous n’avez pas une configuration — vous avez un système de croyances.

Faits intéressants et contexte historique (court, utile, parfois agaçant)

1. Le DNS est antérieur au Web. Les travaux sur le DNS ont commencé au début des années 1980 comme remplacement évolutif du fichier HOSTS.TXT.
2. DNSSEC est plus ancien que DoH/DoT. Les RFCs centrales de DNSSEC datent du milieu des années 2000 ; il résout l’authenticité des données, pas la confidentialité du transport.
3. DoT a été standardisé avant DoH. DoT (RFC 7858) est arrivé en premier ; DoH (RFC 8484) a suivi, poussé en grande partie par les navigateurs et les communautés pour la confidentialité.
4. Beaucoup de « filtres DNS » reposent sur la visibilité en clair. Quand vous chiffrez le DNS, vous changez non seulement la confidentialité, mais aussi le plan d’application des règles — souvent sans prévenir les exploitants.
5. EDNS Client Subnet (ECS) complique la confidentialité. Certains résolveurs envoient des informations partielles de sous-réseau client en amont pour améliorer la localisation CDN, échangeant performance contre confidentialité.
6. La résolution de noms Windows n’est pas que DNS. Il y a LLMNR, mDNS, NetBIOS, et des règles NRPT dans certains environnements ; DoH ne couvre que les requêtes DNS que le client DNS de Windows effectue réellement.
7. Les portails captifs détestent le DNS chiffré. Ils dépendent souvent de l’interception DNS pour vous rediriger vers une page de connexion ; DoH contourne cela — parfois utile, parfois source du « pourquoi je ne peux pas me connecter au Wi‑Fi de l’hôtel ».
8. Historiquement, les entreprises utilisaient le DNS comme plan de contrôle. Bloquer des domaines, orienter le trafic, sinkholer des malwares, ou séparer vues internes/externes — les transports sécurisés ne suppriment pas ces besoins ; ils changent la manière de les implémenter.

Matrice de support Windows : DoH vs DoT vs « magie du navigateur »

Ce que Windows fait (et ne fait pas)

Windows 11 et les builds modernes de Windows 10 supportent DoH au niveau OS pour le client DNS de Windows. Vous pouvez le configurer par interface et par résolveur. L’OS essaie d’utiliser DoH pour les résolveurs éligibles ; selon les paramètres, il peut retomber en clair si DoH échoue. Ce comportement de repli est la différence entre « plutôt privé » et « discrètement fuitant ».

DoT au niveau système n’est pas la fonctionnalité principale des endpoints Windows. Vous verrez DoT dans le matériel réseau, les forwarders DNS, et les clients tiers. Sur les postes Windows, quand on parle de « DNS sécurisé », on entend presque toujours DoH.

Navigateurs : un univers parallèle

Les navigateurs peuvent faire DoH indépendamment de Windows. Cela signifie :

• Votre navigateur peut utiliser DoH même si Windows est configuré en DNS clair.
• Votre navigateur peut utiliser DNS en clair même si Windows utilise DoH, selon les paramètres et la politique du navigateur.
• Le split DNS (zones internes) peut se casser de manière créative si un navigateur utilise un résolveur public pour des noms n’existant qu’en interne.

En environnement d’entreprise, vous devez répondre clairement : appliquons-nous DoH au niveau OS, au niveau navigateur, au niveau réseau, ou pas du tout ? Mélanger « un peu de tout » est la recette des pannes intermittentes qui surviennent uniquement le mardi, dans les salles de réunion, quand on est sur VPN, avec Outlook ouvert.

Les résolveurs comptent plus que le marketing

DoH sur Windows n’est pas « activez le chiffrement et tout marche ». Windows a besoin d’un résolveur qui supporte DoH et, selon votre configuration, d’un template/mapping connu pour l’endpoint. Les résolveurs publics fonctionnent en général. Votre résolveur interne pourrait ne pas l’être, sauf si vous avez construit ou acheté une capacité DoH.

Aussi : si vous exploitez votre propre DoH, les détails de certificat et de SNI importent. TLS n’est pas une vibe ; c’est strict.

Blague #1 : Le DNS, c’est comme la politique de bureau — tout fonctionne tant que personne ne dit « changez-le vite ».

Ce que je recommande (et ce que j’évite)

Pour la plupart des entreprises : choisissez un de ces deux modèles sensés

Modèle A : résolveur d’entreprise + transport chiffré jusque-là. Les endpoints utilisent le résolveur (ou forwarder) d’entreprise comme d’habitude, mais le transport entre l’endpoint et le résolveur est chiffré (DoH si vous êtes sous Windows, DoT si vous standardisez ailleurs). Le résolveur applique la politique, le split DNS, la journalisation et les besoins d’investigation. C’est le modèle « garder la gouvernance ».

Modèle B : résolveur public géré avec politiques strictes. Si vous êtes une petite organisation ou que vous n’avez pas de zones internes, vous pouvez utiliser des résolveurs publics validés avec DoH et l’appliquer via une politique endpoint. Vous perdez la capacité de split DNS interne sauf si vous ajoutez une autre solution, mais vous gagnez en simplicité.

Ce que j’évite

• La bascule silencieuse vers le clair sauf si vous avez explicitement accepté le risque. Si l’objectif est la confidentialité/l’intégrité, le « meilleur effort » devient « mauvaise excuse ».
• Exploiter des zones internes tout en laissant les navigateurs utiliser DoH publics sans contrôles. C’est comme ça que l’« intranet » cesse de se résoudre dans le navigateur mais marche encore en ping, et tout le monde accuse le proxy.
• Supposer que les clients VPN n’interfèrent pas. Beaucoup de VPN installent leur propre DNS, modifient les métriques d’interface, ou imposent des résolveurs spécifiques. Traitez le VPN comme un moteur de configuration DNS.
• Supposer que les outils de sécurité n’interfèreront pas. Certaines suites de sécurité endpoint et proxies d’inspection TLS cassent ou dégradent DoH selon leur politique.

Une citation pour rester honnête : L’espoir n’est pas une stratégie. (idée paraphrasée, couramment attribuée dans les cercles opérations et fiabilité)

Tâches de vérification pratiques (commandes, sorties, décisions)

Voici des tâches réelles que vous pouvez exécuter depuis une machine Windows (PowerShell) ou depuis une bastion Linux sur le même réseau. Chaque tâche inclut : la commande, un extrait réaliste de sortie, ce que cela signifie, et la décision à prendre.

Task 1 — Identifier quels serveurs DNS Windows pense devoir utiliser

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -AutoSize"
InterfaceAlias ServerAddresses
-------------- --------------
Ethernet       {10.20.0.10, 10.20.0.11}
Wi-Fi          {192.168.1.1}

Signification : Windows interrogera 10.20.0.10/11 sur Ethernet et 192.168.1.1 sur le Wi‑Fi. Si DoH est configuré, il sera lié à ces adresses IP de résolveur (et parfois à des templates).

Décision : Si vous attendez du DNS d’entreprise partout, 192.168.1.1 est un drapeau rouge. Corrigez les règles DHCP/VPN ou les métriques d’interface avant de courir après des fantômes DoH.

Task 2 — Vérifier les paramètres DNS par interface et le risque de fuite via « mauvaise interface »

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Format-Table ifIndex,InterfaceAlias,InterfaceMetric,NlMtu -AutoSize"
ifIndex InterfaceAlias InterfaceMetric NlMtu
------ -------------- -------------- -----
12     Ethernet       15             1500
7      Wi-Fi          55             1500

Signification : La métrique la plus basse l’emporte. L’Ethernet sera préféré pour le routage et souvent pour le comportement DNS autour de « l’interface principale ».

Décision : Si le Wi‑Fi ne doit jamais être utilisé pour la résolution de noms d’entreprise (fréquent dans les scénarios de docking), renforcez les métriques ou désactivez l’interface quand l’ordinateur est docké.

Task 3 — Confirmer si Windows a DoH activé et pour quels résolveurs

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientDohServerAddress | Format-Table -AutoSize"
ServerAddress Template               AllowFallback AutoUpgrade
------------- --------               ------------- -----------
10.20.0.10    https://dns.corp/dns-query False         False
10.20.0.11    https://dns.corp/dns-query False         False

Signification : Windows a des mappings DoH explicites pour les résolveurs d’entreprise, et AllowFallback False signifie qu’il ne doit pas revenir silencieusement au DNS en clair pour ces IP.

Décision : Si vous ne voyez aucune entrée, DoH au niveau OS n’est probablement pas configuré. Si AllowFallback True, décidez si vous acceptez une fuite par conception en cas d’échec.

Task 4 — Inspecter l’impact du Name Resolution Policy Table (NRPT) (fréquent avec VPN)

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientNrptRule | Select-Object -First 5 | Format-List"
Namespace : .corp.example
NameServers : {10.20.0.10, 10.20.0.11}
DirectAccessDnsServers :
DnsSecValidationRequired : False

Signification : Les requêtes pour .corp.example sont forcées vers des serveurs spécifiques. Cela peut écraser les choix globaux de résolveur et est souvent ce que vous souhaitez pour le split DNS.

Décision : Si votre zone interne est définie ici mais que les mappings DoH manquent pour ces serveurs, vous obtiendrez du DNS en clair (ou des échecs) pour les noms internes. Alignez NRPT et la configuration DoH.

Task 5 — Interroger un enregistrement et vérifier quel serveur a répondu (fonctionnalité de base)

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName intranet.corp.example -Type A -Server 10.20.0.10"
Name                           Type   TTL   Section    IPAddress
----                           ----   ---   -------    ---------
intranet.corp.example          A      60    Answer     10.30.4.25

Signification : La résolution de base fonctionne contre le résolveur d’entreprise.

Décision : Si cela échoue mais que les noms publics se résolvent, vous avez un problème de chemin split-DNS — pas une panne DNS générique.

Task 6 — Vérifier que le résolveur est joignable sur l’endpoint DoH depuis le client

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection dns.corp -Port 443"
ComputerName     : dns.corp
RemoteAddress    : 10.20.0.10
RemotePort       : 443
InterfaceAlias   : Ethernet
TcpTestSucceeded : True

Signification : TCP/443 vers l’endpoint DoH est joignable depuis ce client sur l’interface attendue.

Décision : Si c’est faux, arrêtez de blâmer Windows DoH. Corrigez d’abord le routage, le pare-feu, l’interception proxy, ou le split tunneling VPN.

Task 7 — Vérifier la chaîne de certificats TLS que Windows verra (échec courant en entreprise)

cr0x@server:~$ powershell -NoProfile -Command "openssl s_client -connect dns.corp:443 -servername dns.corp -showcerts < NUL | findstr /R /C:\"subject=\" /C:\"issuer=\""
subject=CN = dns.corp
issuer=CN = Corp Issuing CA 01

Signification : Le service présente un certificat pour dns.corp émis par une CA interne.

Décision : Si les endpoints ne font pas confiance à cette CA, DoH échouera et pourra retomber en repli. Distribuez la CA à tous les endpoints ou utilisez des certificats publics là où cela est adapté.

Task 8 — Valider les événements opérationnels du client DNS Windows (ce qu’il a tenté de faire)

cr0x@server:~$ powershell -NoProfile -Command "wevtutil qe Microsoft-Windows-DNS-Client/Operational /c:5 /f:text"
Event[0]:
  Provider Name: Microsoft-Windows-DNS-Client
  Event ID: 3018
  Level: Warning
  Description: Name resolution for the name intranet.corp.example timed out after none of the configured DNS servers responded.

Signification : Le client DNS a expiré. Cela ne vous dit pas encore DoH vs clair, mais ça prouve que le problème se situe au niveau du chemin de résolution client (pas l’application).

Décision : Corrélez les horodatages avec les logs de pare-feu et avec des captures de paquets. Si des timeouts se produisent uniquement quand DoH est activé, suspectez des problèmes TLS/proxy.

Task 9 — Vérifier si un navigateur contourne le DNS du système (Firefox est notoirement indépendant)

cr0x@server:~$ powershell -NoProfile -Command "Get-Process firefox -ErrorAction SilentlyContinue | Select-Object -First 1 | Format-Table Name,Id"
Name    Id
----    --
firefox 10432

Signification : Firefox tourne. Ce n’est pas la preuve d’un DoH, mais c’est un rappel : les navigateurs peuvent ignorer les décisions du résolveur OS.

Décision : Si les noms internes échouent dans le navigateur mais fonctionnent dans Resolve-DnsName, vérifiez les politiques DoH du navigateur avant de toucher aux paramètres DoH de Windows.

Task 10 — Confirmer si les requêtes DNS utilisent encore UDP/53 (test de fuite via capture sur une machine Linux)

cr0x@server:~$ sudo tcpdump -ni eth0 'host 10.20.0.50 and (udp port 53 or tcp port 53 or tcp port 443)' -c 10
IP 10.20.0.50.51722 > 10.20.0.10.443: Flags [S], seq 11223344, win 64240, options [mss 1460], length 0
IP 10.20.0.10.443 > 10.20.0.50.51722: Flags [S.], seq 99887766, ack 11223345, win 65160, options [mss 1460], length 0
IP 10.20.0.50.51722 > 10.20.0.10.443: Flags [.], ack 1, win 64240, length 0

Signification : Vous observez des handshakes TCP/443 vers le résolveur. Vous ne voyez pas UDP/53 dans ces premiers paquets, ce qui est un bon signe pour l’utilisation de DoH (pas définitif sans inspection plus approfondie).

Décision : Si vous voyez UDP/53 vers le résolveur alors que vous pensez imposer DoH, soit le fallback est activé, soit le mapping DoH est manquant, soit un autre résolveur est utilisé.

Task 11 — Confirmer les paramètres proxy qui pourraient intercepter ou bloquer DoH

cr0x@server:~$ powershell -NoProfile -Command "netsh winhttp show proxy"
Current WinHTTP proxy settings:

    Proxy Server(s) : 10.20.1.25:8080
    Bypass List     : (none)

Signification : Les services système utilisant WinHTTP passeront par un proxy sauf contournement. Certaines implémentations DoH et endpoints n’apprécient pas cette configuration.

Décision : Si l’endpoint DoH est interne, ajoutez-le à la liste de contournement. S’il est externe, décidez si l’inspection proxy est autorisée et si cela casse les sémantiques DoH.

Task 12 — Inspecter le comportement du cache DNS local (la staleness peut ressembler à « DoH cassé »)

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientCache | Select-Object -First 5 | Format-Table -AutoSize Entry,Data,TimeToLive"
Entry                 Data           TimeToLive
-----                 ----           ----------
intranet.corp.example 10.30.4.25     00:00:42
wpad.corp.example     10.20.1.25     00:12:10

Signification : Le cache client contient des entrées avec des TTL. Si vous avez récemment modifié des enregistrements DNS et que « cela résout encore mal », c’est peut-être juste du cache.

Décision : Si vous diagnostiquez la correction, videz le cache et retestez. Si vous diagnostiquez la performance, le cache fait partie de l’histoire — ne le videz pas sauf nécessité.

Task 13 — Vider le cache DNS pour isoler résolveur vs cache

cr0x@server:~$ powershell -NoProfile -Command "Clear-DnsClientCache; Write-Output 'cache cleared'"
cache cleared

Signification : Cache vidé sur le client.

Décision : Si les problèmes disparaissent après le vidage puis reviennent, vous poursuivez un TTL/caching négatif ou des réponses incohérentes en amont — pas un problème de transport.

Task 14 — Prouver quel processus utilise le port 53 localement (rare, mais ça arrive)

cr0x@server:~$ powershell -NoProfile -Command "netstat -ano | findstr \":53 \" | more"
  UDP    0.0.0.0:5353           *:*                                    1234
  UDP    192.168.1.10:49712     192.168.1.1:53                         0

Signification : Vous avez mDNS (5353) et du trafic sortant UDP/53 depuis l’hôte. La ligne UDP/53 implique que le DNS en clair est encore utilisé quelque part.

Décision : Si vous attendiez DoH uniquement, découvrez pourquoi UDP/53 existe : une autre interface, un autre résolveur, un fallback, ou un service local (VPN, agent de sécurité) qui fait sa propre résolution.

Task 15 — Vérifier les remplacements du fichier hosts (parce que quelqu’un a toujours « corrigé le DNS » localement)

cr0x@server:~$ powershell -NoProfile -Command "Get-Content C:\Windows\System32\drivers\etc\hosts | Select-Object -Last 5"
# ::1             localhost
10.30.4.99        intranet.corp.example

Signification : Le fichier hosts force intranet.corp.example sur 10.30.4.99. Le transport DNS est ici sans importance.

Décision : Supprimez les remplacements non autorisés, puis retestez. En entreprise, traitez cela comme un incident de dérive de configuration, pas comme un « bricolage utilisateur ».

Mode opératoire pour diagnostic rapide

Ceci est l’ordre qui trouve rapidement le goulot d’étranglement sans se noyer dans la théorie.

Premier point : est-ce la sélection du DNS, pas le chiffrement du DNS ?

• Exécutez Get-DnsClientServerAddress et confirmez que les IP des résolveurs attendues sont effectivement configurées.
• Vérifiez les métriques d’interface avec Get-NetIPInterface quand plusieurs adaptateurs existent (Wi‑Fi + Ethernet + VPN).
• Vérifiez les règles NRPT si vous avez un VPN ou du split DNS.

Si le mauvais résolveur est sélectionné : corrigez DHCP/VPN/politique/priorité d’interface. Ne commencez pas par bidouiller les templates DoH.

Second point : l’endpoint DoH est-il joignable et digne de confiance ?

• Test-NetConnection vers TCP/443 sur le nom d’hôte DoH.
• openssl s_client pour vérifier le sujet/émetteur du certificat et le comportement SNI.
• Vérifiez le proxy WinHTTP avec netsh winhttp show proxy.

Si TLS/cert/proxy est le problème : vous verrez des timeouts ou des échecs de handshake ; corrigez la chaîne de confiance et le contournement proxy. Ne continuez pas à basculer le fallback en espérant que « ça se stabilise ».

Troisième point : fuyez-vous via fallback ou des piles alternées ?

• Vérifiez Get-DnsClientDohServerAddress pour AllowFallback.
• Capturez le trafic (tcpdump/Wireshark) pour la présence d’UDP/53.
• Validez le comportement DoH au niveau navigateur si les symptômes sont spécifiques à une application.

Si des fuites existent : décidez si vous imposez « DoH seulement » (et acceptez les ruptures en cas d’échec) ou si vous autorisez le fallback (et acceptez les lacunes de confidentialité/intégrité). Choisissez délibérément.

Quatrième point : est-ce réellement un problème de performance du résolveur ?

• Comparez la latence des requêtes (perçue par l’utilisateur) avant et après activation de DoH.
• Recherchez un renouvellement fréquent des sessions TLS (beaucoup de nouvelles connexions) versus réutilisation.
• Vérifiez les symptômes du taux de hit du cache local (les problèmes disparaissent après chauffe).

Si c’est la performance : il vous faudra probablement ajuster la capacité du résolveur, le comportement keep-alive, ou le coût du moteur de politique — pas « plus de chiffrement ».

Trois mini-récits d’entreprises depuis le terrain

Incident n°1 — La panne causée par une mauvaise hypothèse

Le plan était simple : activer DoH sur les portables Windows pour réduire l’espionnage DNS sur le Wi‑Fi public. Le déploiement était progressif, la politique était ciblée, et le ticket CAB avait cette aura familière de « petite amélioration inoffensive ».

Deux jours plus tard, des applications web internes ont commencé à échouer — uniquement dans les navigateurs, uniquement pour certains utilisateurs, et uniquement hors site. Le ping vers les noms internes fonctionnait. Le Bureau à distance fonctionnait. Mais le portail intranet renvoyait « hôte introuvable » dans Edge et Chrome.

La mauvaise hypothèse était subtile : tout le monde pensait que les « paramètres DNS Windows » contrôlaient le DNS. En réalité, les navigateurs avaient opportunistiquement activé DoH vers un résolveur public. Quand les utilisateurs étaient hors site, le navigateur envoyait des noms internes au résolveur public, qui évidemment ne les connaissait pas. Pendant ce temps, Windows résolvait ces noms via le DNS fourni par le VPN sans problème, donc les applications non-navigateurs semblaient santé.

La correction n’a pas été héroïque. Ils ont appliqué une politique navigateur : soit désactiver DoH du navigateur, soit le pointer vers l’endpoint DoH d’entreprise qui comprenait le split DNS. Après cela, les symptômes ont disparu. La leçon est restée : la résolution de noms est une pile de piles, et les navigateurs ne sont plus « juste des apps » — ce sont des plateformes avec une opinion.

Incident n°2 — L’optimisation qui a mal tourné

Une autre entreprise avait une plainte de performance : « Le DNS est lent sur Windows quand DoH est activé. » Quelqu’un a remarqué que l’endpoint DoH était derrière un proxy de couche 7 qui faisait inspection TLS et authentification. L’optimisation rapide a été de placer le service DoH derrière un load balancer global avec des health checks agressifs et des timeouts de connexion courts. Sur le papier : latence plus faible, meilleure disponibilité.

En pratique, le load balancer terminait TLS puis le ré-établissait vers l’upstream. Ce n’était pas automatiquement mauvais, mais cela a créé un churn constant de connexions. Certains clients se reconnectaient fréquemment, et le service DoH consacrait trop de CPU aux handshakes. Aux heures de pointe, le résolveur était effectivement une usine à TLS avec une activité secondaire en réponses DNS.

Pire : les checks de santé ressemblaient à du « trafic HTTPS valide » mais n’exerçaient pas toujours le handler DoH réel. Le LB déclarait des backends sains même quand le chemin DoH était dégradé, parce que la couche TCP/TLS était correcte. Les utilisateurs voyaient des échecs intermittents qui ne corrélaient avec rien d’évident sauf « après le déjeuner ».

Ils ont annulé l’« optimisation », puis réintroduit les changements prudemment : keep-alive ajustés, health checks pointant le chemin DoH réel, et éviter des couches de terminaison TLS inutiles. La performance s’est améliorée, mais le vrai gain a été la clarté opérationnelle : si vous ne pouvez pas mesurer le handler DoH séparément de TLS, vous volez à l’aveugle.

Incident n°3 — La pratique ennuyeuse mais correcte qui a sauvé la journée

Une grande entreprise avait une pratique de changement stricte : avant tout changement du transport DNS, ils mettaient à jour un runbook interne avec les « motifs de paquets attendus », les logs d’événements à vérifier, et un plan de rollback simple. Les gens se plaignaient que c’était lent. C’était aussi la raison pour laquelle ils n’ont pas fondu.

Pendant un cycle de mise à jour Windows global, un sous-ensemble d’appareils a commencé à échouer DoH à cause d’un problème de confiance de certificat. La chaîne de certificats du résolveur était correcte, mais une rotation d’une CA intermédiaire n’avait pas été entièrement déployée sur toutes les images. Certains portables pouvaient valider la chaîne ; d’autres non. Le comportement résultant dépendait des paramètres de fallback et si l’appareil était sur VPN.

Parce que l’équipe avait une checklist de validation définie, le helpdesk n’a pas perdu des jours à accuser « Internet ». Ils ont collecté un paquet standard : sortie du mapping DoH, logs d’événements, et un rapide check TLS. Le motif est devenu évident en quelques heures : les appareils manquant l’intermédiaire CA ne pouvaient pas faire DoH, et les appareils avec fallback désactivé avaient des échecs sévères.

La correction a été ennuyeuse aussi : distribuer l’intermédiaire manquant via la gestion des endpoints, confirmer par un contrôle ciblé du magasin de certificats, et relancer les tâches de validation. Personne n’a reçu de trophée. Mais personne n’a vécu une panne d’une semaine non plus. En opérations, l’ennui est souvent la forme la plus élevée de compétence.

Erreurs fréquentes : symptômes → cause racine → correctif

1) « DNS sécurisé activé » mais la capture montre UDP/53

Symptômes : Vous voyez encore des requêtes DNS en UDP/53 partir de l’hôte ; les outils de confidentialité signalent des fuites.

Cause racine : DoH non configuré pour les adresses IP de résolveur réelles ; fallback autorisé ; ou une autre interface/adaptateur VPN utilise encore du DNS en clair.

Correctif : Vérifiez les IP des résolveurs (Get-DnsClientServerAddress), vérifiez les mappings DoH (Get-DnsClientDohServerAddress), mettez AllowFallback False là où approprié, et corrigez la priorité des adaptateurs.

2) Les noms internes échouent seulement dans le navigateur

Symptômes : Resolve-DnsName intranet.corp.example fonctionne ; le navigateur renvoie NXDOMAIN ou ne peut pas résoudre.

Cause racine : DoH au niveau navigateur utilisant des résolveurs publics ; le split DNS n’est pas respecté.

Correctif : Appliquez une politique navigateur pour désactiver DoH ou le pointer vers DoH d’entreprise ; assurez-vous que les zones internes se résolvent via le chemin résolveur d’entreprise.

3) DoH fonctionne au siège mais échoue sur VPN

Symptômes : Sur le LAN : OK. Sur VPN : timeouts. Désactiver le « DNS sécurisé » le fait marcher.

Cause racine : Le VPN pousse des règles NRPT ou des serveurs DNS qui n’ont pas de mappings DoH ; le VPN bloque l’accès à l’endpoint DoH ; les paramètres proxy diffèrent en VPN.

Correctif : Alignez les résolveurs fournis par le VPN avec les mappings DoH ; assurez-vous que le nom DoH est joignable via le VPN ; ajoutez un contournement proxy correct pour l’endpoint DoH.

4) Échecs intermittents après activation de DoH

Symptômes : Certaines résolutions bloquent puis réussissent. Timeouts d’applis aléatoires. « Ça marche après un reboot. »

Cause racine : Instabilité du handshake TLS (proxy d’inspection, problèmes de MTU), contraintes de capacité du résolveur, ou load balancer fermant agressivement les connexions inactives.

Correctif : Validez le path MTU ; vérifiez la joignabilité TCP/443 et la chaîne TLS ; ajustez les keep-alives/timeouts du load balancer ; scalez le résolveur ou réduisez le coût des évaluations de politique.

5) « L’endpoint DoH est up » mais Windows ne l’utilise pas

Symptômes : HTTPS vers l’endpoint marche dans un navigateur ; Windows utilise toujours du DNS en clair ou échoue.

Cause racine : Mapping/template DoH manquant pour l’IP du résolveur ; mismatch de nom de certificat ; problèmes SNI.

Correctif : Assurez-vous que le template DoH correspond au résolveur et que le certificat est valide pour le nom d’hôte utilisé par Windows ; validez avec openssl s_client -servername.

6) Le filtrage DNS a cessé de fonctionner « mystérieusement »

Symptômes : Des domaines qui étaient bloqués se résolvent désormais ; l’équipe sécurité observe moins de télémétrie DNS.

Cause racine : Les endpoints/navigateurs sont passés à des résolveurs DoH externes, contournant les contrôles DNS d’entreprise.

Correctif : Appliquez la politique de résolveur (endpoint et/ou contrôles de sortie réseau). Si vous avez besoin de filtrage, gardez la résolution sur des résolveurs que vous contrôlez.

Blague #2 : Le DNS chiffré, c’est super… jusqu’à ce que vous réalisiez que l’outil préféré du helpdesk était « voir quel domaine ils ont tapé ».

Checklists / plan pas-à-pas

Plan A — Déploiement DoH Windows de niveau entreprise (sans blessures auto-infligées)

1. Inventairez vos résolveurs : listez les IP des serveurs DNS que les endpoints reçoivent sur LAN, Wi‑Fi, et VPN. Si vous ne pouvez pas les lister, vous n’êtes pas prêt.
2. Décidez de votre posture d’application : autoriser le fallback (moins de risque de panne, plus de fuites) vs pas de fallback (garantie plus forte, plus fragile). Écrivez la décision.
3. Mettre en place/valider un endpoint DoH : assurez la joignabilité TCP/443 depuis tous les réseaux, certificats corrects, comportement SNI correct, et load balancing prévisible.
4. Implémenter les mappings DoH : mappez chaque IP de résolveur à un template endpoint DoH et définissez le comportement de fallback.
5. Gérer explicitement le split DNS : les règles NRPT pour les zones internes doivent pointer vers les résolveurs d’entreprise ayant DoH activé.
6. Aligner la politique des navigateurs : soit désactiver DoH dans les navigateurs, soit les pointer vers le même endpoint DoH d’entreprise pour éviter les cassures split-DNS.
7. Mesurer avant/après : latence de résolution, taux d’échec, et présence d’UDP/53 sortant. « Ça a l’air OK » n’est pas une métrique.
8. Déployer en anneaux : IT, power users, puis déploiement large. Capturez logs et échantillons de paquets à chaque anneau.
9. Avoir un rollback : un unique basculement de politique pour revenir au DNS en clair pendant le diagnostic.

Plan B — Petite organisation / pas de zones internes (simple et robuste)

1. Choisir une stratégie de résolveur : un fournisseur, deux IP pour redondance, endpoint DoH stable.
2. Activer DoH au niveau OS avec mapping explicite et décider du fallback. Si c’est pour la confidentialité, ne laissez pas le fallback à « oui, peu importe ».
3. Valider la sortie : confirmez que seul TCP/443 vers le résolveur est utilisé, et que UDP/53 ne s’échappe pas vers des routeurs aléatoires.
4. Garder les navigateurs cohérents : ne laissez pas le navigateur choisir un résolveur différent de l’OS à moins d’aimer le debugging.

Checklist opérationnelle — Avant d’accuser DoH

• Est-ce que l’IP du résolveur est correcte pour ce réseau ?
• Le nom DoH est-il joignable sur TCP/443 depuis ce réseau ?
• L’endpoint a-t-il une chaîne de certificats de confiance ?
• Un proxy n’intercepte-t-il pas ou ne bloque-t-il pas le flux DoH ?
• Le navigateur n’utilise-t-il pas ses propres paramètres DoH ?
• Les captures montrent-elles UDP/53 (fuite) ou seulement 443 (attendu) ?

FAQ

1) Activer DoH dans Windows sécurise-t-il automatiquement tout le DNS sur la machine ?

Non. Cela sécurise les requêtes DNS effectuées via le client DNS de Windows vers les résolveurs configurés/mappés pour DoH. Les applications et navigateurs peuvent faire leur propre DNS (y compris leur propre DoH), et d’autres protocoles comme mDNS/LLMNR sont séparés.

2) DoH est‑il « meilleur » que DoT ?

Au niveau opérationnel : DoT est plus facile à identifier et gérer au niveau réseau ; DoH est plus difficile à distinguer du HTTPS normal et donc plus dur à contrôler. En termes de confidentialité, les deux peuvent être efficaces. En entreprise, « meilleur » signifie généralement « s’intègre à notre politique et ne casse pas le split DNS ».

3) Pourquoi le split DNS interne casse‑t‑il quand DoH est activé ?

Il casse quand des requêtes pour des zones internes vont vers un résolveur qui ne les connaît pas — souvent un résolveur DoH public utilisé par un navigateur. Corrigez cela en appliquant la politique navigateur et en garantissant que les zones internes se résolvent via les résolveurs d’entreprise (NRPT aide).

4) Si je désactive le fallback, est‑ce que ça va casser des choses ?

Parfois, et c’est le but : vous échouerez en mode fermé au lieu de fuir silencieusement. Si votre endpoint DoH est peu fiable ou bloqué sur certains réseaux, désactiver le fallback fera apparaître des échecs visibles pour l’utilisateur. Décidez selon votre modèle de menace et votre tolérance aux pannes.

5) Un proxy d’inspection TLS peut‑il casser DoH ?

Oui. Certains proxies bloquent ou interfèrent avec les endpoints DoH ; d’autres « fonctionnent » mais ajoutent latence et modes de défaillance. Si vous devez inspecter, traitez DoH comme une application avec ses propres SLO et testez‑la comme telle.

6) Comment prouver que DoH est réellement utilisé ?

Utilisez une combinaison : vérifiez les mappings DoH de Windows, confirmez la connectivité TCP/443 vers l’endpoint DoH, et capturez le trafic pour confirmer l’absence d’UDP/53 vers vos résolveurs. Pour une preuve approfondie, inspectez les requêtes HTTPS vers le chemin DoH côté serveur (logs) ou via la télémétrie endpoint.

7) Pourquoi je vois UDP/53 même quand DoH est configuré ?

Causes communes : fallback activé, une autre interface utilise le DNS en clair, le VPN a injecté des paramètres de résolveur sans mapping DoH, ou un agent local fait sa propre résolution. Traitez UDP/53 comme un symptôme et tracez le processus/interface qui l’a produit.

8) DoH remplace-t‑il DNSSEC ?

Non. DoH chiffre le transport ; DNSSEC signe les enregistrements pour l’authenticité (quand il est correctement validé). Ils résolvent des problèmes différents et peuvent être utilisés ensemble.

9) DoH améliorera-t‑il les performances DNS ?

Parfois, mais n’y comptez pas systématiquement. DoH ajoute un overhead TLS et peut être plus lent si les connexions churnent ou si des proxies interfèrent. Les améliorations de performance viennent généralement d’un meilleur résolveur, du caching, et du routage — pas du chiffrement seul.

10) Quel est le choix par défaut le plus sûr pour des portables d’entreprise ?

Résolveur d’entreprise + mapping DoH explicite + politique navigateur alignée sur la résolution d’entreprise + un choix délibéré sur le fallback. Le plus sûr, c’est la cohérence. Une résolution incohérente est la façon dont vous avez à la fois des trous de sécurité et des pannes.

Étapes suivantes qui ne saboteront pas votre lundi

Faites-les dans cet ordre :

1. Choisissez votre modèle : résolveur d’entreprise avec transport DoH, ou résolveur public géré. Ne faites pas les deux sans limites claires.
2. Rendez-le observable : décidez comment vous prouverez le transport et l’identité du résolveur (logs d’événements, captures de paquets, logs serveur).
3. Alignez les navigateurs : appliquez une politique pour que les navigateurs ne contournent pas votre stratégie DNS.
4. Décidez du fallback : acceptez les fuites (fallback activé) ou acceptez les pannes (fallback désactivé). Documentez la décision et le rollback.
5. Exécutez les tâches ci‑dessus sur trois réseaux : LAN du siège, Wi‑Fi domestique, et VPN. La plupart des pannes DNS sont « ça marche à un endroit ».

Si vous ne faites rien d’autre : arrêtez de vous fier aux hypothèses. Le DNS sécurisé sur Windows fonctionne — quand vous le traitez comme de la plomberie de production, pas comme un autocollant de confidentialité.