Avec la mise à jour de sécurité de juin 2026, le rôle Serveur DNS de Windows Server 2025 s’enrichit d’une nouvelle fonctionnalité : il sait enfin répondre aux requêtes en DNS-over-HTTPS (DoH), ce qui permet de chiffrer les échanges entre les clients et le serveur DNS, en particulier pour les enregistrements internes.

Le trafic DNS circule en clair sur un réseau. C’est la conception du protocole DNS qui veut cela, ce n’est pas un défaut dans l’implémentation du protocole DNS sur Windows. Le DNS a été conçu pour être rapide, pas pour être sécurisé. Mais, forcément, cela représente un risque et il est vulnérable à plusieurs techniques d’attaques, dont le spoofing.

Le DNS-over-HTTPS répond à ce problème de sécurité en encapsulant les requêtes DNS dans des connexions HTTPS, ce qui les rend illisibles en capturant le trafic réseau. En effet, elles sont chiffrées grâce au HTTPS. Ce n’est pas la seule méthode valable pour chiffrer les requêtes DNS, on peut citer également le DNS-over-TLS (DoT) et le DNS-over-QUIC (DoQ).

Dans ce tutoriel, nous allons d’abord observer le DNS en clair à l’aide de Wireshark, puis nous activerons le DoH sur le serveur DNS sous Windows Server. Voici l’environnement utilisé tout au long de cet article :

• Nom de domaine Active Directory :
• Contrôleur de domaine et serveur DNS :
• Autorité de certification d’entreprise (AD CS) :
• Poste client : (Windows 11)

Avant de commencer, notez que la prise en charge de DoH côté serveur DNS nécessite Windows Server 2025 avec la mise à jour de sécurité de juin 2026 (KB5094125) ou une version ultérieure. Sans ce correctif, le cmdlet que nous utiliserons par la suite n’exposera pas le paramètre nécessaire à l’activation du chiffrement.

Comprendre pourquoi le DNS n’est pas chiffré par défaut

Le protocole DNS a été conçu à une époque où la confidentialité des échanges n’était pas une préoccupation. Le DNS classique repose sur le port 53, en UDP la plupart du temps et en TCP pour les réponses volumineuses ou les transferts de zone. Dans les deux cas, le contenu de la requête et de la réponse transite sans aucun chiffrement.

Cela signifie que la résolution d’un nom comme ou est visible en clair sur le réseau. Un attaquant qui parvient à se placer entre le client et le serveur peut non seulement lire ces requêtes, mais aussi les modifier. C’est le principe de l’attaque de type DNS spoofing, où une réponse falsifiée redirige l’utilisateur vers un serveur contrôlé par l’attaquant.

Le DoH, normalisé par le RFC 8484, change la donne en faisant transiter les requêtes DNS à l’intérieur d’une session HTTPS, généralement sur le port TCP 443. Le trafic devient alors indissociable d’une navigation web chiffrée classique : une analyse du trafic montrerait une connexion TLS vers une adresse, sans que l’on puisse savoir quels noms de domaine sont résolus.

Observer le DNS en clair avec Wireshark

Avant de chiffrer quoi que ce soit, il est utile de constater par soi-même que le DNS circule en clair. Cette étape sert de point de départ : nous comparerons l’avant et l’après pour valider que le DoH fonctionne réellement.

Sur le poste , installez Wireshark (ou utilisez Pktmon, l’outil de capture intégré à Windows, si vous ne souhaitez pas installer de logiciel tiers). Lancez une capture sur l’interface réseau qui communique avec .

Pour isoler le trafic DNS, appliquez le filtre d’affichage suivant dans Wireshark :

Si vous souhaitez filtrer uniquement les échanges avec votre serveur DNS, combinez le filtre avec l’adresse IP du contrôleur de domaine :

Pendant que la capture tourne, générez une requête DNS depuis le client. Ouvrez une console PowerShell et exécutez :

De retour dans Wireshark, vous verrez apparaître deux paquets caractéristiques : une requête (Standard query) et sa réponse (Standard query response). En sélectionnant le paquet de requête et en déroulant la section “Domain Name System“, le nom interrogé apparaît en toutes lettres dans la requête. C’est précisément cette information que le DoH va masquer.

Gardez cette observation en tête, car après l’activation du DoH, le port 53 ne sera plus sollicité pour les clients compatibles et le trafic basculera vers le port 443 en TLS. Surtout, le trafic sera chiffré !

Vérifier les prérequis sur le serveur DNS

Avant de manipuler les certificats, validons que le serveur est prêt. Trois conditions doivent être réunies.

Premièrement, la mise à jour de sécurité de juin 2026 (KB5094125) doit être installée. Vous pouvez le vérifier rapidement en PowerShell :

Si la commande ne retourne rien, installez les dernières mises à jour Windows avant de poursuivre. Le résultat ci-dessus est celui attendu avant de continuer.

Deuxièmement, vous devez disposer d’une autorité de certification de confiance, capable d’émettre un certificat d’authentification serveur. Dans notre cas, c’est le rôle de , une autorité de certification d’entreprise intégrée à Active Directory.

Troisièmement, le port utilisé par le DoH (par défaut TCP 443) doit être autorisé en entrée sur le serveur. La règle peut être créée via l’interface graphique ou PowerShell via la commande suivante :

Vérifiez que la règle a bien été créée :

Note : pensez également aux pare-feu “matériels” placés entre les clients et le serveur : ils doivent eux aussi laisser passer le trafic TCP sur ce port, sans quoi les clients ne pourront pas établir la session DoH.

Obtenir un certificat TLS avec l’autorité AD CS

Le DoH s’appuie sur TLS, donc sur un certificat. Le serveur DNS présente ce certificat aux clients pour prouver son identité et établir la session chiffrée. Le certificat doit respecter plusieurs exigences, faute de quoi la connexion échouera.

Voici les caractéristiques attendues :

• Utilisation améliorée de la clé (EKU) : le certificat doit inclure l’identificateur d’objet « Authentification du serveur » ().
• Nom alternatif du sujet (SAN) : il doit contenir le nom de domaine complet (FQDN) ou l’adresse IP que les clients utiliseront dans leur modèle d’URI DoH. Dans notre cas, ce sera . J’ai repris ici le nom FQDN du serveur DNS (qui est aussi contrôleur de domaine AD, un classique).
• Clé privée : elle doit être présente dans le magasin de l’ordinateur local, associée au certificat, et la protection forte de clé privée ne doit pas être activée.
• Chaîne de confiance : le certificat doit être émis par une autorité reconnue à la fois par le serveur DNS et par les clients.

Le modèle “Serveur Web” fourni par défaut porte bien l’EKU d’authentification serveur, mais il n’autorise pas l’inscription automatique et impose de saisir le sujet à la main à chaque demande. Il servira de point de départ pour créer notre modèle personnalisé aligné sur les besoins du DoH.

Sur , ouvrez la console des modèles de certificats () et dupliquez le modèle “Serveur Web“.

Ajustez ensuite les onglets suivants :

• Général : nom d’affichage « DNS over HTTPS », validité de 2 ans avec renouvellement 6 semaines avant l’échéance. Laissez décochée la publication du certificat dans Active Directory, inutile pour un certificat d’authentification serveur.

• Traitement de la demande : conservez “Signature et chiffrement“. Laissez décochée l’option “Autoriser l’exportation de la clé privée” afin que la clé reste sur le serveur. Le certificat sera demandé directement depuis le serveur DNS, donc nous n’avons pas besoin d’exporter la clé (si ce n’est pas le cas, vous devez activer l’option). Ne cochez pas “Exiger la protection renforcée de la clé privée” : cette protection est incompatible avec le DoH et ferait échouer la liaison.

• Nom du sujet : sélectionnez “Construire à partir des informations Active Directory“, avec le format “Nom commun“, et cochez “Nom DNS” dans les autres noms. Le SAN sera ainsi rempli automatiquement avec le FQDN du serveur, ce qui évite les fautes de frappe et empêche un demandeur de réclamer un nom arbitraire.

• Sécurité : ajoutez le groupe de sécurité “Contrôleurs de domaine” existant par défaut dans l’AD. Ici, je l’utilise car tous mes DC sont serveurs DNS et ce sont les seuls à avoir besoin de ce certificat. Adaptez si besoin. Ce groupe doit pouvoir lire et inscrire des certificats.

Une fois le modèle enregistré, publiez-le sur l’autorité AD CS. Ensuite, avec la console , sous “Modèles de certificats“, faites : un clic droit > Nouveau > Modèle de certificat à délivrer, puis sélectionnez le modèle que l’on vient de créer, à savoir “DNS over HTTPS“.

Demander le certificat depuis chaque serveur DNS

L’inscription automatique n’étant pas utilisée, chaque serveur DNS demande son propre certificat de façon manuelle. Ce choix d’un certificat distinct par serveur a un intérêt concret : la clé privée est générée sur place et n’a jamais besoin d’être exportée ni transportée. Il n’y a donc aucun fichier à copier, ni mot de passe de PFX à gérer.

Sur , puis sur tout autre serveur DNS comme (qui est mon second serveur), il convient d’ouvrir le magasin de certificats de l’ordinateur local (), puis de faire ceci : Personnel > Certificats, clic droit > Toutes les tâches > Demander un nouveau certificat, et choisissez le modèle “DNS over HTTPS“. Comme le sujet est construit à partir d’Active Directory, aucune saisie supplémentaire n’est nécessaire.

Pour ceux qui sont pressés, voici l’équivalent en PowerShell, à exécuter en administrateur sur chaque serveur (utilisez le nom interne du modèle, sans espace) :

Le certificat et sa clé privée sont déposés directement dans le magasin . Chaque serveur utilisera ensuite son propre FQDN dans son modèle d’URI DoH. Le certificat est bien présent sur le serveur !

Notez que cette approche par certificat distinct convient quand les clients interrogent chaque serveur par son nom. Si vous préférez un nom partagé entre plusieurs serveurs (derrière un répartiteur de charge, par exemple), il faudrait alors un certificat commun portant ce nom dans le SAN, avec une clé exportable pour le déployer sur chaque machine, au prix d’un niveau de protection légèrement moindre.

Note : si vous récupérez un certificat généré sur un autre poste (ou émis par une CA publique), vous disposerez d’un fichier à importer avec . Dans ce cas, la clé privée doit avoir été marquée comme exportable lors de sa création pour pouvoir être déplacée, ce qui implique d’ajuster le modèle.

Lier le certificat au port HTTPS

Le certificat étant en place, il faut maintenant l’associer au port sur lequel le serveur DNS écoutera les connexions DoH. Cette liaison s’effectue au niveau de la pile HTTP de Windows, à l’aide de l’utilitaire .

Commencez par générer un identifiant unique (GUID) qui servira à identifier l’application propriétaire de la liaison. La commande de PowerShell sert à générer un GUID aléatoire.

Récupérez ensuite le certificat. Sur un contrôleur de domaine, il peut y avoir déjà plusieurs certificats d’authentification serveur dont le sujet ou le SAN contient le FQDN du serveur. Un filtre basé uniquement sur le sujet en retournerait donc plusieurs, et deviendrait un tableau, ce qui ferait échouer la prochaine action de configuration.

Donc, commencez par lister les certificats candidats pour repérer le bon, en affichant leur empreinte, leur date d’expiration (souvenez-vous que la durée de validité est de 2 ans) et leur usage :

Voici le certificat qui m’intéresse ici :

Copiez l’empreinte () du certificat et récupérez-le en PowerShell :

Avant de poursuivre, vérifiez que la variable ne contient qu’un seul certificat. La commande suivante doit retourner :

Liez enfin le certificat au port 443, pour toutes les adresses IP du serveur :

Remarque : si votre serveur héberge plusieurs adresses IP et que vous souhaitez que le DoH ne réponde que sur l’une d’entre elles, remplacez par l’adresse IP voulue. Cette adresse doit correspondre au nom ou à l’IP figurant dans le SAN du certificat. De la même manière, vous pouvez remplacer par un autre port si le 443 est déjà utilisé par un autre service sur la machine, ce qui est rare sur un contrôleur de domaine (sauf si vous installez n’importe quoi dessus).

Pour confirmer que la liaison a bien été enregistrée, affichez les associations SSL existantes :

Repérez dans la sortie l’entrée correspondant à (ou à votre adresse IP) et vérifiez que la ligne “Hachage du certificat” correspond bien à l’empreinte relevée précédemment.

Activer DNS-over-HTTPS sur le serveur DNS

Tout est désormais en place pour activer le chiffrement ! L’activation se fait avec la cmdlet , en précisant le modèle d’URI que les clients utiliseront pour joindre le service.

Le modèle d’URI suit la forme . L’hôte doit correspondre au nom présent dans le SAN du certificat, et le port doit être identique à celui de la liaison. Pour ma part, cela donne cette commande :

Redémarrez ensuite le service correspondant au serveur DNS pour appliquer la configuration :

Le serveur DNS répond maintenant au trafic DoH sur le port 443, tout en continuant d’écouter le DNS classique sur le port 53 pour les clients qui ne sont pas configurés en DoH. Cette coexistence permet une migration progressive : vous pouvez basculer vos postes vers le DoH par lots, sans interrompre la résolution pour les machines non encore configurées.

Vérifier le bon fonctionnement de DoH

Avant de toucher au client, contrôlez l’état de la configuration du DoH sur Windows Server 2025. Tout d’abord, cette commande devrait vous retourner la déclaration de l’endpoint DoH :

Ouvrez ensuite l’Observateur d’événements sur et rendez-vous dans : Journaux des applications et des services > Serveur DNS. Recherchez l’événement portant l’identifiant 822. Sa présence confirme que le service DoH a démarré correctement.

Voici un exemple :

Tester DoH depuis un client Windows 11

Le serveur DNS est prêt à recevoir des requêtes DNS sur le port 443. Toutefois, il reste à configurer un poste client pour vérifier si cela est bien opérationnel. Ici, je vais reprendre mon client pour qu’il interroge le serveur DNS en DoH. Ce sera l’occasion de valider le résultat avec une nouvelle capture réseau.

Sur Windows 11, le DoH client se configure au niveau des paramètres de l’interface réseau, ou en PowerShell. Déclarez le serveur DNS comme prenant en charge le chiffrement avec un modèle d’URI identique à celui du serveur. Voici un exemple en PowerShell, en indiquant , car il s’agit de l’adresse IP de :

Le paramètre impose le chiffrement et empêche le client de revenir au DNS en clair si le DoH échoue. C’est un réglage à manier avec prudence, car une erreur de configuration coupe la résolution DNS sur la machine locale.

Depuis l’application “Paramètres” de Windows 11, vous pouvez aussi configurer le DoH : Réseau et Internet > Ethernet > Attribution du serveur DNS > Modifier. Vous devez ensuite spécifier l’adresse IP du serveur DNS, le modèle d’URI pour le DoH et l’option “Retour au texte en clair” correspond au fallback (utiliser le DNS classique, en clair, en cas d’échec du DoH).

Désormais, je vais refaire le même test DNS qu’en début d’article. Ce sera l’occasion de faire un réel avant / après.

La résolution doit aboutir normalement. La différence se joue sur le réseau. Relancez une capture Wireshark sur , mais cette fois en filtrant le port 443 et l’adresse IP du serveur DNS :

Vous constaterez que les requêtes ne partent plus en clair sur le port 53 vers le serveur. À la place, une session TLS s’établit vers sur le port 443, et le contenu des requêtes DNS n’est plus lisible ! Une excellente nouvelle ! Wireshark affiche du trafic TLSv1.2 sans pouvoir visualiser le contenu des trames. C’est la preuve que le DoH protège désormais vos requêtes.

Conclusion

L’arrivée du DNS-over-HTTPS côté serveur DNS dans Windows Server 2025 comble un manque de longue date pour les environnements Active Directory. Jusqu’ici, chiffrer la résolution de noms interne supposait de s’appuyer sur des résolveurs tiers, mais ce n’était clairement pas l’idéal lorsqu’il est question de résoudre des noms internes ! Désormais, la chaîne DNS du client au contrôleur de domaine peut être protégée par le chiffrement avec les outils natifs de Windows Server.

FAQ – DoH Windows Server 2025