MENU
  1. Accueil
  2. Windows
  3. Windows Server
  4. DNS over HTTPS/DoT : état du support dans Windows Server 2022 & 2025 Preview, contournements et feuille de route

DNS over HTTPS/DoT : état du support dans Windows Server 2022 & 2025 Preview, contournements et feuille de route

Windows Server

Le chiffrement des requêtes DNS est devenu indispensable pour renforcer la confidentialité ; pourtant, le rôle DNS Server de Windows Server reste à la traîne. Cet article décrit l’état réel du support DoT/DoH côté serveur, les moyens de pression possibles sur la feuille de route Microsoft et les solutions de contournement éprouvées.

Sommaire

Vue d’ensemble : pourquoi DoT/DoH ?

Le DNS, souvent décrit comme « l’annuaire d’Internet », a historiquement fonctionné en clair sur les ports 53 UDP/TCP. Toute personne placée sur le chemin réseau – opérateur, fournisseur Wi‑Fi, acteur malveillant – peut donc :

  • Observer le nom de chaque site demandé ;
  • Bloquer ou altérer la résolution pour mettre en place de la censure ou des attaques de type spoofing ;
  • Profiler des utilisateurs ou des services internes sans jamais toucher au trafic applicatif.

Les mécanismes DNSSEC signent l’intégrité mais ne chiffrent pas le canal. DNS over TLS (port 853/TCP) et DNS over HTTPS (port 443/HTTPS) répondent donc à un besoin de confidentialité, de conformité (RGPD, PCI‑DSS, Zero Trust) et de résilience face aux attaques.

État du support dans Windows Server 2022 et 2025 Preview

VersionSupport côté client DNSSupport côté serveur DNS
Windows Server 2022 (GA)Oui — même pile que Windows 11 23H2Non — pas de terminaison DoT/DoH
Windows Server 2025 Preview (build Canary)Oui — nouvelles stratégies de groupe pour DoHNon — aucune trace dans dnscmd.exe, PowerShell DNS ni l’UI

En clair : le rôle DNS Server continue d’écouter exclusivement sur 53 UDP/TCP. Les bibliothèques système (HTTP.SYS, SCHANNEL) savent terminer TLS 1.3 et HTTP/3, mais la couche DNS du service dns.exe n’est pas encore reliée à ces capacités.

Documentation officielle et feuille de route

La page « What’s new in Windows Server 2025 Preview » ne mentionne ni DoH ni DoT. Les notes de publication du canal Insider mettent en avant SMB over QUIC, AF_VSOCK et d’autres nouveautés réseau, mais rien sur le DNS sécurisé. Autrement dit, Microsoft n’a pas (encore) communiqué d’engagement public quant à la prise en charge côté serveur.

Comprendre la priorisation produit chez Microsoft

Les équipes Windows Server raisonnent historiquement en scénarios : Active Directory, virtualisation, stockage. Le DNS sécurisé en frontal n’est pas jugé bloquant, notamment parce que :

  1. Le client Windows résout déjà en DoH/DoT vers des résolveurs publics (Cloudflare, Google) ;
  2. Peu d’environnements d’entreprise demandent explicitement la terminaison TLS sur leur DNS interne ;
  3. Les appliances tierces (Infoblox, F5, Cisco Umbrella, etc.) comblent le besoin.

Changer cette perception impose donc de quantifier le risque et les bénéfices métier : conformité avec les lignes directrices CNIL, obligations sectorielles (finance, santé), extension d’un modèle Zero Trust inter‑datacentres, etc.

Comment accélérer l’intégration native

Plusieurs canaux officiels ont un impact réel sur la feuille de route :

  • Feedback Hub : ouvrez une entrée dans la catégorie « Windows Server / Networking » et documentez votre cas d’usage. Plus le nombre de votes + commentaires détaillés est élevé, plus l’item remonte lors des triages de sprint.
  • Windows Insider Program : testez les builds Canary/Dev, mesurez les écarts et soumettez des logs dxdiag / powershell Get-WinEvent pour démontrer les limitations.
  • Conférences Ignite / Build : les sessions Q&A permettent d’interpeller directement les Program Managers réseau. Préparez une question structurée et chiffrée !
  • Partenariats TAP (Technology Adoption Program) : si vous disposez d’un accord Premier ou Unified Support, sollicitez votre Microsoft Account Team pour sponsoriser une feature request.

Solutions de contournement pragmatiques

1. Proxy TLS/HTTPS en frontal

L’idée : laisser le rôle DNS Server intact et ajouter un service qui termine le TLS/HTTPS, puis relaie la requête en clair vers 127.0.0.1:53.

# Exemple d’installation de dnsproxy (Windows)
choco install dnsproxy --params "/service /config=C:\dnsproxy.yaml"

Dans C:\dnsproxy.yaml :

listen_addresses:
  - 0.0.0.0:853    # DoT
  - 0.0.0.0:443    # DoH
upstream_dns:
  - 127.0.0.1:53   # Windows DNS Server local
tls_crt: C:\certs\dns.example.crt
tls_key: C:\certs\dns.example.key

Avantages :

  • Aucune modification dans la console DNS ;
  • Maintenance simple : mise à jour du binaire proxy sans toucher aux zones AD‑integrated ;
  • Possibilité de journaliser séparément les flux TLS.

Inconvénients :

  • Complexité de gestion des certificats (expiration, renouvellement ACME) ;
  • Débit potentiellement réduit si l’on active HTTP/2 avec nombreux streams parallèles.

2. Serveur DNS alternatif

Déployer CoreDNS, Knot Resolver, PowerDNS Recursor ou BIND 9.19+ directement sur l’hôte Windows (via WSL 2 ou binaire natif) ou sur une VM/Linux. Procédure classique :

  1. Activer les zone transfers depuis le contrôleur AD vers le nouveau résolveur.
  2. Créer des forwarders conditionnels pour déléguer _msdcs.domain si besoin.
  3. Basculer progressivement les clients via GPO ou DHCP Option 6.

La plupart de ces serveurs gèrent :

  • Le protocole DoH/DoT en mode listener ;
  • La mise en cache avancée (prefetch, serve‑stale) ;
  • La réécriture de réponse (filtrage parental, blocage publicité).

3. Appliance réseau ou cloud

Pour des exigences de haute disponibilité, les appliances spécialisées peuvent :

  • Publier plusieurs VIP Anycast en 443/853 avec Health checks ;
  • Gérer l’auto‑scaling (Azure DNS Private Resolver, GCP Cloud DNS) ;
  • Supporter la signature TSIG/GSS‑TSIG pour le transfert de zone sécurisé.

Le coût est plus élevé mais l’intégration SLA/SOC plus riche (rapports, alertes).

Bonnes pratiques en attendant le support natif

  • DNSSEC partout : même si le canal reste en clair, l’intégrité des enregistrements protège contre les empoisonnements de cache.
  • Monitoring du canal DNS interne : activer l’audit avancé DNS Analytic et Debug + Sysmon Event ID 22 pour tracer les requêtes.
  • Segmentation réseau : isolez les flux DNS dans un VLAN dédié ; appliquez des ACL strictes pour réduire la surface d’attaque.
  • Automatisation des certificats : si vous utilisez un proxy, coupler Certbot ou Win‑ACME avec un secret store (Key Vault, HSM).
  • Veille technologique : suivre le canal Twitter/X des Program Managers @msftdnc.core et les GitHub issues de CoreDNS pour connaître les évolutions et rétroporter vos besoins.

Foire aux questions (FAQ)

Le rôle DNS Server prendra‑t‑il un jour en charge HTTP/3 ?

Probable, car HTTP/3 repose sur QUIC (UDP/443), déjà exploitable par SMB over QUIC. Une fois DoH/DoT implémenté, activer HTTP/3 sera la suite logique pour réduire la latence.

Les clients Windows 10 recevront‑ils l’option « Encrypted DNS only » ?

Non. Microsoft réserve les nouveautés DoH/DoT aux builds 2004+ avec la pile « Platform DNS ». Windows 10 LTSC 2019 restera limité aux paramètres de résolution traditionnelle.

Puis‑je activer DoT/DoH via un regedit caché côté serveur ?

Non. Aucune clé de registre ne charge un listener TLS dans dns.exe. Les références trouvées dans HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters concernent exclusivement le client.

Étude de cas : migration d’un groupe scolaire

Un rectorat devait se conformer à la recommandation ANSSI / référentiel sécurité ID‑NOS :

  • 15 000 postes ; 300 établissements ; bande passante WAN limitée.
  • Conservation d’Active Directory pour l’authentification.
  • Besoin de journaliser et filtrer les domaines inappropriés.

Solution retenue :

  1. Déploiement d’un cluster AdGuard Home (DoH/DoT, Ratelimit) sur deux VM Linux.
  2. Activation du mode Authoritative upstream vers les DNS Server Windows pour les zones AD‑integrated.
  3. Transition des postes via DHCP Scope Option 6 + Script PowerShell pour forcer netsh dns add encryption 192.0.2.10 doh.
  4. Gain mesuré : −27 % de trafic en clair sur le WAN, +12 % de temps de réponse DNS moyen (cache multiplié par 4).

Conclusion

Le support natif de DNS over TLS / DNS over HTTPS côté serveur Windows Server reste absent en 2025 Preview, et rien n’indique une arrivée à court terme. En attendant, trois stratégies s’offrent à vous : un proxy TLS, un serveur DNS tiers ou une appliance dédiée. Pour peser sur la feuille de route, centralisez vos exigences dans Feedback Hub, participez activement au programme Insider et alignez votre cas d’usage sur les objectifs Zero Trust largement promus par Microsoft. Tôt ou tard, la pression réglementaire et la demande marché devraient faire évoluer la situation ; en vous préparant dès aujourd’hui, vous garantissez une transition fluide lorsque la fonctionnalité sortira enfin.

Windows Server
sécurité DNS Windows Server DoH DoT
Sommaire