L'ordre de la résolution de noms sous Windows — hosts, le cache DNS, LLMNR/mDNS et DoH

« Les réglages sont les mêmes, mais seul ce PC n’atteint pas le serveur interne. » « Cela s’ouvre dans le navigateur, mais l’application métier échoue à la résolution de noms. » « Je l’ai mis dans hosts et cela n’a aucun effet. »

Lorsque l’on enquête sur des problèmes de ce genre, la première chose à établir est quel mécanisme répond pour ce nom. Windows a plusieurs chemins : le cache, hosts, le serveur DNS, LLMNR, NetBIOS et mDNS, et certaines applications utilisent un chemin qui leur est propre, distinct de Windows.

Cet article donne d’abord la vue d’ensemble, range la forme d’un nom et les différences entre les chemins, puis passe à la procédure d’isolement réelle. Si vous devez enquêter tout de suite, sautez à la section concernée depuis le tableau suivant.

Prérequis de cet article

L’article sur la capture de paquets couvre les paquets qui circulent sur le fil, et l’article sur le proxy couvre « les réglages de proxy de qui sont lus ». Cet article couvre l’étape d’avant : « d’où vient l’adresse IP de destination », rangée sur la base des sources primaires de Microsoft.

1. D’abord la conclusion

Il y a trois choses à retenir.

• La résolution de noms Windows n’avance pas toujours le long d’une seule file dans l’ordre. Le cache et hosts viennent d’abord, mais pour un nom à étiquette unique, DNS et LLMNR/NetBT s’exécutent en parallèle par défaut.³⁴
• Le même nom donne des résultats différents lorsque les réglages du PC et le chemin de l’application diffèrent. Pensez séparément aux suffixes, au VPN, à la NRPT et au résolveur intégré du navigateur.⁵⁶⁷
• Dans une enquête, restreignez le chemin utilisé et comparez les résultats. Séparez cache, DNS et lien local avec les commutateurs de Resolve-DnsName, puis confirmez avec un diff de réglages contre un PC qui fonctionne et avec une capture.⁸

Servez-vous du diagramme suivant comme carte d’ensemble.

flowchart TB
    accTitle: La résolution de noms est un empilement de couches
    accDescr: Une demande de résolution de noms passe de l'API de l'application au service Client DNS ; le cache et hosts sont consultés d'abord, puis le serveur DNS, et pour les noms à étiquette unique seulement, LLMNR et NetBIOS (en parallèle de DNS par défaut) sont tentés. Pour les noms .local, mDNS est un chemin supplémentaire à côté du DNS configuré. Le navigateur a son propre résolveur hors de cette file
    app["Application (getaddrinfo)"] --> svc["Service Client DNS"]
    svc --> cache["Cache (hosts inclus)"]
    cache -->|si absent| dns["Interroger le serveur DNS"]
    cache -->|"si absent, nom à étiquette unique (parallèle à DNS par défaut)"| ll["LLMNR / NetBIOS"]
    svc -->|".local (chemin supplémentaire)"| mdns["mDNS"]
    browser["Navigateur"] -.->|résolveur propre, DoH| ext["Chemin distinct"]

Le cache est consulté en premier ; au-delà, DNS et, pour les noms à étiquette unique, LLMNR et NetBIOS s’exécutent en parallèle. Le navigateur a un chemin distinct.

Ci-dessous, « quelle couche répond » est traité aux chapitres 3 à 5, « comment la requête est envoyée » au chapitre 6, et « comment vérifier » aux chapitres 7 et 8. DoH est une fonction qui bascule le transport vers le serveur DNS sur HTTPS ; elle ne remplace pas l’ordre de hosts, du cache et de la NRPT.⁹

Dans le diagramme, un trait continu marque une relation qui vaut toujours et un trait pointillé une relation conditionnelle (les conditions figurent dans l’explication de chaque relation sur la page de détail). La liste complète des relations (48 au total, avec preuve et niveau de certitude) et les définitions des concepts principaux sont rassemblées sur la page de détail de la carte des connaissances (en japonais). Données : JSON-LD / Turtle

2. La « résolution de noms » n’est pas une seule opération

Tout ce que l’application récupère, c’est une adresse ou une erreur

Lorsqu’une application se connecte en utilisant un nom tel que www.example.com, getaddrinfo de Winsock (la version Unicode est GetAddrInfoW) est appelé. Pour l’espace de noms NS_DNS, cette fonction convertit le nom en adresse via DNS, le fichier hosts local et d’autres mécanismes. Si plusieurs fournisseurs d’espace de noms répondent, elle agrège leurs réponses et les renvoie.¹⁰

Autrement dit, d’après le résultat que l’application reçoit, on ne peut pas dire quelle couche a répondu.

Dns.GetHostAddresses de .NET utilise aussi getaddrinfo sous Windows. Pour un hôte listé dans hosts, il renvoie cette adresse sans interroger un serveur DNS. HttpClient s’exécute aussi au-dessus de cette classe Dns, donc une application .NET qui se connecte directement à sa destination hérite de l’ordre de résolution de noms Windows.¹¹

Via un proxy HTTP, le nom qui est résolu change. Ce qui est résolu localement, c’est le nom du proxy ; le nom de destination est résolu côté proxy. Dans ce cas, hosts local, cache, suffixes et NRPT ne jouent aucun rôle dans la résolution de la destination. Quels réglages de proxy sont utilisés est couvert dans l’article sur le proxy.

2.1 Le service Client DNS décide de l’ordre

Ce qui travaille sous getaddrinfo, c’est le service Client DNS (nom de service Dnscache). La documentation de Microsoft décrit l’ordre de base comme suit.³

1. Consulter le cache.
2. Consulter le fichier hosts.
3. Interroger le serveur DNS.

Parce que le contenu de hosts est chargé dans le cache au démarrage du service, cet article traite les deux premiers ensemble comme couche 1, « cache et hosts ».⁵

Au-delà, le chemin se ramifie selon le nom et les stratégies.

La « résolution de noms intelligente multi-adresses » par défaut envoie des interrogations DNS, LLMNR et NetBT à tous les réseaux en parallèle. Quelle réponse est retenue est décidé par les règles des sections 4.3 et 5.2.⁴

Par conséquent, « quand l’interrogation est envoyée » et « la priorité donnée aux réponses qui reviennent » sont deux affaires distinctes. Voir LLMNR ou NetBT dans une capture ne signifie pas à soi seul « DNS a échoué ». Les « trois couches » de cet article sont une division pour l’explication ; elles ne veulent pas dire que les couches s’exécutent toujours séquentiellement dans l’ordre du temps.

2.2 Ce qui est hors de la file

Les deux qu’il est particulièrement facile de confondre sont ceux-ci.

Utiliser le client intégré d’Edge ne signifie pas à soi seul que le serveur DNS change. La section 6.2 le traite séparément du réglage DNS sécurisé qui sélectionne un autre fournisseur.

3. Couche 1 — Le cache et hosts

Ce que l’on veut savoir à cette couche, c’est quelles réponses restent à l’intérieur du PC. Le cache retient non seulement les réponses correctes mais aussi les réponses périmées et les réponses « le nom n’existe pas ».

3.1 hosts est chargé dans le cache

Le fichier hosts se trouve à C:\Windows\System32\drivers\etc\hosts. Lorsque le service Client DNS démarre, ses correspondances nom-adresse IP sont chargées dans le cache du résolveur. Les enregistrements obtenus par des interrogations DNS sont retenus dans le même cache pendant leur TTL (durée de vie).⁵

ipconfig /displaydns montre à la fois les entrées chargées depuis hosts et les entrées obtenues par des interrogations DNS récentes.¹³ Dans l’exemple de Microsoft lui-même, si vous mettez contoso.com dans hosts, Resolve-DnsName contoso.com renvoie cette adresse et aucun trafic DNS ne circule.³

Comment lire l’absence de paquets DNS

Si vous résolvez un FQDN sans DoH ni DoT, que la résolution de noms réussit, et qu’il n’y a aucune interrogation sur le port 53, le cache ou hosts est vraisemblablement en train de répondre. D’abord, toutefois, écartez les autres chemins suivants.

Ne concluez pas « cache » simplement parce que « il n’y a rien sur le port 53 » ; regardez aussi les chemins qui pourraient être en usage. Une seule ligne de hosts de test laissée sur une machine de développement peut faire dévier une enquête.

Modifier hosts exige des droits d’administrateur, et des produits de sécurité peuvent détecter le changement. Une conception qui fait dépendre les opérations d’une application métier de hosts devrait être évitée.

3.2 Les réponses négatives sont aussi mises en cache

« Introuvable » est aussi l’une des réponses qui sont mises en cache. Le client DNS stocke les réponses négatives autant que les positives.⁵

Si ipconfig /displaydns affiche « Name does not exist » pour le nom cible, une réponse négative du serveur DNS reste sur le client. La procédure de Microsoft vous dit de la jeter avec ipconfig /flushdns.¹⁴¹³

Le temps de conservation du cache négatif est MaxNegativeCacheTtl sous HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters, et la valeur par défaut est 5 secondes.¹⁵ C’est pourquoi un PC peut continuer à renvoyer des échecs pendant quelques secondes même juste après qu’un enregistrement a été ajouté à DNS.

3.3 TTL et « seuls certains PC sont périmés »

Les réponses positives restent aussi pendant leur TTL. Un PC qui a résolu le nom avant que l’adresse IP du serveur soit changée continue d’utiliser l’ancienne réponse, tandis qu’un PC qui le résout pour la première fois après le changement obtient la nouvelle. Même avec le même serveur DNS, le résultat diffère lorsque le moment de la consultation diffère.⁵

Clear-DnsClientCache se comporte de la même façon que ipconfig /flushdns et supprime tout le contenu du cache, y compris les réponses négatives.¹⁶ Avec Get-DnsClientCache, vous pouvez récupérer le cache sous forme d’objets et vérifier le type d’enregistrement et le TTL restant.¹⁷

# Un nom précis est-il dans le cache, et combien de secondes de TTL restent ?
Get-DnsClientCache -Entry 'app01.corp.example.com' |
    Select-Object Entry, Type, Status, TimeToLive, Data

# Vérifier ensemble le contenu de hosts et du cache
ipconfig /displaydns | Select-String -Pattern 'app01' -Context 0,6

# Jeter le cache (réponses négatives comprises)
Clear-DnsClientCache

Si une réponse est trouvée à la couche 1, cette consultation est tranchée avant d’atteindre le serveur DNS. Toutefois, il reste possible qu’une mauvaise réponse ait été apprise à l’origine du serveur DNS. Ne vous arrêtez pas à la vider ; vérifiez aussi la réponse obtenue à neuf à l’étape 3 du chapitre 8.

4. Couche 2 — Interroger le serveur DNS

Si la couche 1 n’a pas de réponse, la résolution avance vers DNS. Ici, pensez séparément à quel nom est envoyé, à quel serveur, et à quel moment.

4.1 Noms à étiquette unique et suffixes

D’abord, vérifiez la forme du nom que l’application a passé.⁵

Un suffixe est la partie de domaine ajoutée après un nom court. Ajouter corp.example.com à app01 fait du nom interrogé app01.corp.example.com.

Lorsqu’une liste de recherche existe

Les suffixes de la liste de recherche de suffixes DNS sont ajoutés dans l’ordre depuis le haut, et le nom est envoyé avec un point final. Une fois qu’une liste de recherche est configurée, seule cette liste est utilisée. Le suffixe principal, les suffixes spécifiques à la connexion et la dévolution de noms ne sont pas utilisés.¹⁸

Lorsqu’il n’y a pas de liste de recherche

Le suffixe DNS principal est ajouté. Si la dévolution de noms est activée, l’étiquette la plus à gauche est retirée après chaque échec et le nom est réessayé ; par exemple, de www.test.contoso.com à www.contoso.com. Si un adaptateur a un suffixe DNS spécifique à la connexion, celui-ci est aussi ajouté et envoyé.⁵

Pour cette raison, le même server01 s’étend différemment dans un environnement où la stratégie de groupe distribue une liste de recherche et dans un environnement où l’appartenance au domaine fournit un suffixe principal.

Une liste longue augmente aussi l’attente

Si le suffixe correct est près de la fin de la liste, le temps d’interrogation s’accumule jusqu’à l’atteindre. Microsoft explique aussi ce délai avec un exemple qui essaie six suffixes. Pour n’essayer qu’une expansion précise, ajoutez un point final, comme dans internal.contoso.com..³

# Réglages globaux : liste de recherche et dévolution
Get-DnsClientGlobalSetting

# Par interface : suffixe spécifique à la connexion et réglages d'enregistrement
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix, UseSuffixWhenRegistering

# Serveurs DNS par interface (IPv4 et IPv6)
Get-DnsClientServerAddress | Where-Object ServerAddresses | Select-Object InterfaceAlias, AddressFamily, ServerAddresses

Get-DnsClientGlobalSetting renvoie les réglages globaux tels que la liste de recherche et si, et jusqu’à quel niveau, la dévolution est activée ; Get-DnsClient renvoie les réglages par interface.¹⁹²⁰

4.2 L’ordre de plusieurs serveurs DNS et les délais d’expiration

Lorsque « cela n’échoue pas, mais il y a une attente de plusieurs secondes », suspectez des retransmissions vers un serveur DNS qui ne répond pas. Pour les serveurs DNS configurés sur une seule NIC, le calendrier de retransmission par défaut s’aligne comme suit.²¹

Ceci est le tableau pour le cas où il n’y a pas de réponse. En particulier, ne confondez pas les deux suivants.

Lorsque « nous en avons arrêté un mais cela ne bascule pas », si un serveur qui détient une ancienne zone continue de tourner et renvoie des réponses négatives, la résolution ne passe pas au serveur suivant.²¹

Les quatrième serveur et suivants ne sont atteints qu’au bout de 4 secondes

Si le serveur qui peut répondre est quatrième ou plus loin dans la liste, au moins 4 secondes passent après la première interrogation. Si l’échéance de l’application est plus courte que cela, elle échoue au stade de la résolution de noms. Pour faire sortir l’interrogation plus tôt, il faudrait déplacer ce serveur parmi les trois premiers, mais la correction de fond est de réparer les serveurs injoignables qui le précèdent, ou de les retirer des réglages. Revoir aussi le délai d’expiration côté application.²¹

Dans l’exemple de Microsoft aussi, une configuration dans laquelle un seul des quatre serveurs est joignable prend environ 4 secondes à se terminer. Vous pouvez mesurer le temps écoulé avec Measure-Command, et le même document traite moins d’1 seconde comme acceptable.³

# Interroger un serveur précis directement, DNS seulement, et obtenir le temps écoulé en millisecondes
(Measure-Command {
    Resolve-DnsName -Name 'app01.corp.example.com' -Server 10.0.1.2 -DnsOnly
}).TotalMilliseconds

Parce que cette commande épingle le serveur, elle mesure le temps de réponse de ce serveur seul. Le délai jusqu’à ce que la quatrième entrée de la liste soit atteinte se vérifie avec une interrogation sans -Server, ou avec une capture de cette interrogation.

Notez que le client DNS fait monter les serveurs qui répondent plus vite, se souvient des serveurs qui ne répondent pas, et les réessaie périodiquement. Le délai d’expiration initial est aussi ajusté dans une plage de 25 à 1 000 millisecondes d’après les performances passées. Le tableau ci-dessus est le squelette par défaut, c’est pourquoi les mesures réelles s’en écartent.⁵

4.3 Plusieurs NIC et la « résolution de noms intelligente multi-adresses »

Sur un PC qui a à la fois le filaire et le Wi-Fi, ou un PC auquel un adaptateur VPN est ajouté, vérifiez non seulement la liste des serveurs DNS mais aussi l’interrogation à travers les réseaux et la sélection de la réponse.

Retransmission vers plusieurs adaptateurs

Dans la procédure d’interrogation de Microsoft, l’interrogation va au premier serveur DNS de l’adaptateur préféré, avec une attente de 1 seconde. S’il n’y a pas de réponse, elle va au premier serveur de chaque adaptateur encore dans l’ensemble des candidats, avec une attente de 2 secondes, et ensuite à tous les serveurs de tous les adaptateurs, avec des attentes de 2, 4 et 8 secondes. Lorsqu’un serveur d’un adaptateur renvoie une réponse négative, les autres serveurs de cet adaptateur sont retirés des candidats.⁵

La stratégie qui contrôle l’interrogation parallèle

Le paramètre de stratégie de groupe « Désactiver la résolution de noms intelligente multi-adresses » contrôle le comportement suivant.⁴

Parce que la stratégie s’appelle « Désactiver », notez que activer la stratégie désactive l’optimisation.

Un exemple où le VPN change le résultat

Lorsqu’un nom interne est interrogé, le DNS côté VPN renvoie l’adresse interne, et le DNS côté routeur domestique peut aussi renvoyer une autre réponse positive : une adresse publique sous le même nom de domaine que l’interne, ou l’adresse d’une page publicitaire substituée à un nom inexistant, par exemple.

Avec deux réponses positives, la rétention est tranchée par l’ordre de liaison. Sur Windows actuel, cette priorité est déterminée par la métrique d’interface ; plus InterfaceMetric affiché par Get-NetIPInterface est petit, plus la priorité est haute. Des différences de cet ordre d’un PC à l’autre deviennent des différences de résultat.²²

Si, en revanche, le côté domicile renvoie une réponse négative, cet adaptateur est retiré des candidats et la réponse du côté VPN est utilisée.⁵ Les produits VPN distribuent la NRPT ou « Désactiver la résolution de noms intelligente multi-adresses » précisément pour contrôler ces différences.

4.4 NRPT — Changer où vont les interrogations par espace de noms

La NRPT (Name Resolution Policy Table, table de stratégie de résolution de noms) est une table qui spécifie, par espace de noms tel que .corp.contoso.com, quels serveurs DNS utiliser et les réglages DirectAccess et DNSSEC. Les profils DirectAccess et Always On VPN y écrivent des règles pour produire un comportement tel que « n’envoyer que les noms internes au DNS interne ».²³⁶

Get-DnsClientNrptPolicy -Effective montre les règles réellement en vigueur.

# Les règles NRPT réellement en vigueur
Get-DnsClientNrptPolicy -Effective

# Afficher seulement les règles d'un espace de noms précis. -Namespace ne filtre que sur l'attribut Namespace ; il ne met pas en correspondance un nom.
# Passer 'app01.corp.example.com' ne renvoie pas la règle de suffixe pour '.corp.example.com'.
# Pour trouver quelle règle s'applique à un nom, énumérez les règles et mettez-les en correspondance vous-même, comme à l'étape 4 du chapitre 8
Get-DnsClientNrptPolicy -Effective -Namespace '.corp.example.com'

La NRPT ne s’applique qu’aux applications qui utilisent l’API DNS de Windows. Les applications avec leur propre implémentation DNS contournent ce chemin. La documentation du CSP VPNv2 cite nslookup comme exemple et exige Resolve-DnsName pour vérifier la NRPT. Le résolveur intégré du navigateur et DoH sont aussi hors de l’API DNS de Windows.⁶

5. Couche 3 — Les issues de secours des noms à étiquette unique : LLMNR, NetBIOS, puis mDNS

5.1 En quoi les trois protocoles diffèrent

LLMNR et NetBIOS over TCP/IP (NetBT) sont des moyens alternatifs de résoudre un nom à étiquette unique tel que app01. Par défaut ils s’exécutent en parallèle de DNS, et une réponse de lien local peut être retenue même lorsque DNS renvoie une réponse positive. Ils ne deviennent séquentiels après un échec DNS que lorsque la résolution de noms intelligente multi-adresses a été désactivée.⁴

mDNS est distinct de ceux-ci ; c’est un chemin supplémentaire pour les noms .local. Ce n’est pas un fourre-tout qui se déclenche après qu’une résolution DNS d’un nom à étiquette unique a échoué.²⁴

Même pour .local, ne sautez pas la vérification de DNS

.local ne devient pas mDNS uniquement. Si le domaine Active Directory est quelque chose comme corp.local, ce nom continue d’être résolu aussi par les serveurs DNS configurés et la NRPT. RFC 6762 autorise aussi la coexistence avec le DNS unicast. Lorsque vous enquêtez sur des noms .local, vérifiez aussi les stratégies DNS et VPN.²⁴

NetBT dépend de l’existence de WINS et du type de nœud

Sans WINS configuré, le défaut est B-node ; avec ne serait-ce qu’un serveur WINS configuré, le défaut est H-node.²⁹ Les diffusions LLMNR et NetBT ne traversent pas les sous-réseaux, mais les interrogations vers WINS sont en unicast et le peuvent donc.

nbtstat -c montre le cache de noms NetBIOS, et nbtstat -R purge le cache et recharge LMHOSTS.³¹

5.2 Lequel a la priorité

Quelle réponse a la priorité après les interrogations parallèles est aussi régi par la stratégie.⁴

Sur les réseaux domicile ou publics, la réponse d’un appareil voisin portant le même nom peut avoir la priorité sur DNS. Ici aussi, il importe de lire la priorité des réponses séparément du fait que les interrogations sont séquentielles ou parallèles.

5.3 L’orientation de Microsoft : s’aligner sur mDNS

En avril 2022, Microsoft a annoncé une orientation consistant à s’aligner sur mDNS et à réduire progressivement la résolution de noms NetBIOS et LLMNR.²⁷ D’anciens protocoles de découverte d’appareils peu sûrs tels que Computer Browser ont aussi été dépréciés.³² Les conceptions qui complètent les noms à étiquette unique par la multidiffusion ou la diffusion sont en voie de disparition.

Les informations de Microsoft sur la vulnérabilité LLMNR listent, comme contournements, le blocage de TCP/UDP 5355 et l’activation du paramètre de stratégie de groupe « Désactiver la résolution de noms de multidiffusion ». Elles indiquent aussi qu’en conséquence l’ordinateur peut devenir invisible pour les autres ordinateurs.²⁵ Activer cette stratégie désactive LLMNR sur tous les adaptateurs du client DNS.⁴

La décision de les désactiver est en elle-même correcte, mais un remplacement du chemin qui disparaît doit être fourni dans DNS. Pour les appareils non enregistrés dans DNS, enregistrez leurs enregistrements A ou activez l’enregistrement dynamique via DHCP, et changez les destinations en FQDN. Les appareils qui prennent en charge mDNS peuvent utiliser des noms .local, mais la portée est limitée à là où la multidiffusion passe.

5.4 Le cas typique « seuls certains PC ne se connectent pas » : les noms à étiquette unique

Lorsqu’un fichier de configuration ou un raccourci contient \\fileserver01 ou http://app01/, le même nom produit les différences suivantes.

Ce que Resolve-DnsName app01 -LlmnrOnly vous dit, c’est « s’il peut être résolu via LLMNR ». Cela ne vous dit pas d’où est venue la réponse retenue dans les interrogations quotidiennes. La comparaison avec le résultat sans commutateurs, et les captures, se font à l’étape 5 du chapitre 8.⁸

La correction de fond, ce sont les FQDN et l’enregistrement DNS

Changez les destinations qui dépendent de noms à étiquette unique en FQDN, et concentrez la résolution de noms sur DNS.

SMB2 et les versions ultérieures se connectent directement sur TCP 445 et n’utilisent pas les sessions NetBIOS.³³ Cela, toutefois, est une affaire de transport. Au stade de la résolution du nom dans une destination telle que \\fileserver01\share, LLMNR ou NetBT peut être utilisé. Spécifiez le FQDN, comme dans \\fileserver01.corp.example.com\share, pour retirer la dépendance au chemin des noms à étiquette unique.

Quelques précautions restent même avec les FQDN, toutefois. Un FQDN sans point final est aussi essayé avec des suffixes si la stratégie qui ajoute des suffixes aux noms à plusieurs étiquettes est activée. Un nom se terminant par .local peut utiliser mDNS à côté de DNS. La forme qui épingle le nom sans condition est le nom absolu avec un point final. La prémisse pour traiter « un FQDN est épinglé à DNS » comme vrai en pratique est que la stratégie ci-dessus est désactivée et que le nom de domaine interne n’utilise pas .local.

6. Le transport vers le serveur DNS — DoH ne change pas l’ordre

6.1 DoH sous Windows 11 / Windows Server 2022

Le DoH de Windows est une fonction qui envoie les interrogations au serveur DNS par HTTPS. Il est intégré aux hosts, cache et NRPT existants, et aux réglages de résolveur par adaptateur et par profil ; il ne remplace pas l’ordre décrit aux chapitres 3 et 4.⁹

Le client DNS de Windows 11 prend en charge DoH, et les versions plus récentes prennent aussi en charge DoT (DNS over TLS). La description de Microsoft, toutefois, n’indique pas quelles versions prennent en charge DoT, donc il n’est pas garanti qu’il soit disponible sur chaque environnement que cet article suppose. Ce qui suit couvre DoH.⁹

D’abord, vérifiez la liste des serveurs DoH connus

Sauf si DDR est activé, seuls les serveurs de la liste des serveurs DoH connus peuvent être utilisés. La liste par défaut contient Cloudflare, Google et Quad9, et elle peut être vérifiée avec Get-DnsClientDohServerAddress. Pour un serveur DNS interne et analogues, enregistrez un modèle DoH avec les réglages de repli et de mise à niveau automatique.¹³⁴

# La liste des serveurs DoH connus
Get-DnsClientDohServerAddress

# Enregistrer le serveur DNS interne comme serveur DoH (pas de repli en clair, avec mise à niveau automatique)
Add-DnsClientDohServerAddress -ServerAddress '10.0.1.2' `
    -DohTemplate 'https://dns.corp.example.com/dns-query' `
    -AllowFallbackToUdp $false -AutoUpgrade $true

L’enregistrement est aussi possible avec netsh dnsclient add encryption. Le netsh dnsclient set global doh=yes|no|auto global est un réglage distinct du autoupgrade par serveur.³⁵

auto seul n’interdit pas de retomber sur le clair. Le repli vers UDP en cas d’échec est décidé séparément par le udpfallback par serveur, ou -AllowFallbackToUdp en PowerShell. Pour restreindre la résolution au transport chiffré seulement, désactivez aussi le repli.³⁵

Avec DDR activé, il y a aussi un chemin de découverte dynamique

Sur les versions qui prennent en charge DDR (Discovery of Designated Resolvers), un résolveur configuré en clair peut annoncer ses points de terminaison DNS chiffrés. Parce que la connexion peut être mise à niveau vers le chiffrement sans un enregistrement dans la liste statique, on ne peut pas dire « il n’est pas dans la liste, donc ce n’est pas DoH ».³⁵

Pour que DDR fonctionne, les deux netsh dnsclient set global ddr=yes global et set interface <name> ddr=yes par adaptateur sont requis. Le repli vers le clair lorsque la résolution chiffrée obtenue via DDR échoue est décidé par ddrfallback, désactivé par défaut.

Dans une enquête, outre la liste connue, vérifiez netsh dnsclient show global et netsh dnsclient show state, et les valeurs posées avec set interface sur les adaptateurs qui ont des serveurs DNS. Les sous-commandes show définies dans la documentation sont encryption, global et state ; il n’y a pas de sous-commande show propre à l’adaptateur.³⁵

Séparez « Autoriser », « Exiger » et le repli vers le clair

Dans l’application Paramètres, réglez les paramètres DNS sur manuel ; « Chiffrement DNS préféré » ne peut être choisi que lorsque le serveur DNS préféré est dans la liste connue. Il y a trois options.¹

Le paramètre de stratégie de groupe « Configurer la résolution de noms DNS over HTTPS (DoH) » a Autoriser, Interdire et Exiger. Avec Autoriser, DoH est utilisé lorsque, en plus d’un enregistrement dans la liste connue, des conditions telles que la mise à niveau automatique, le réglage de chiffrement de l’adaptateur, ou le doh=auto global sont remplies. Avec « Exiger », la résolution de noms elle-même échoue face aux serveurs qui ne prennent pas en charge DoH.¹³⁵

N’appliquez pas « Exiger DoH » aux PC joints à un domaine. Microsoft met en garde explicitement à ce sujet. Active Directory Domain Services dépend fortement de DNS, et le service Serveur DNS livré avec Windows Server ne prend pas en charge les interrogations DoH.¹

Dans une capture, lisez les réglages et le trafic réel séparément

Les interrogations réellement envoyées par DoH circulent à l’intérieur de TLS sur le port 443 plutôt que UDP 53. Même avec « Autoriser DoH », toutefois, les interrogations vers des serveurs absents de la liste connue, et les replis après un échec de chiffrement, circulent en clair. Avoir DoH configuré ne fait pas disparaître le trafic du port 53.

Si aucune interrogation DNS n’est visible, vérifiez DoH et DoT (port 853) en plus de hosts et du cache. Pour comment capturer, voir l’article sur la capture de paquets.

6.2 Le DoH du navigateur est distinct de l’OS

Le client DNS intégré d’Edge et le changement de destination d’interrogation via le DNS sécurisé se comprennent plus facilement une fois découpés en deux étapes.

Le client intégré est contrôlé par BuiltInDnsClientEnabled, et les interrogations DoH sont toujours faites par le résolveur intégré.⁷ Le DNS sécurisé est désactivé par défaut sur les PC gérés par l’organisation et se configure avec DnsOverHttpsMode (off / automatic / secure) et DnsOverHttpsTemplates.³⁶³⁷

Un Edge qui a un autre fournisseur choisi peut résoudre des sites externes mais échouer à résoudre des noms connus seulement du DNS interne. Inversement, Edge seul peut encore ouvrir des pages lorsque le DNS de l’OS est en mauvaise santé. S’il reste avec le fournisseur actuel, la destination d’interrogation ne change pas.

La conclusion : ne traitez pas le succès du navigateur et le succès de l’application métier comme des preuves concernant le même chemin. Vérifiez le chemin de l’OS avec Resolve-DnsName ou ping.

7. Quel chemin l’application emprunte-t-elle ?

Avant de choisir les outils d’une enquête, alignez le chemin que vous regardez.

Les principaux commutateurs de Resolve-DnsName, rangés par but d’enquête, sont les suivants.⁸

7.1 A et AAAA : IPv6 revient en premier

Même lorsque la résolution de noms réussit, la sélection d’adresse qui suit peut rendre la connexion lente.

Le client DNS interroge à la fois A (IPv4) et AAAA (IPv6). Dans une capture aussi, les deux interrogations apparaissent en paire.³ Après le retour des réponses, getaddrinfo et la pile de connexion choisissent l’adresse à utiliser. Windows Vista et les versions ultérieures utilisent la table de préfixes RFC 3484, et par défaut préfèrent l’unicast global IPv6 à IPv4.³⁸

Toutefois, une réponse AAAA à elle seule ne signifie pas qu’une connexion IPv6 est toujours tentée. La sélection de destination écarte d’abord les destinations inutilisables, telles que celles sans adresse source IPv6 ni route, puis ordonne les candidats.³⁹

Le problème se pose dans les environnements où une adresse source IPv6 et une route semblent exister mais ne fonctionnent pas réellement. La résolution de noms réussit, pourtant du temps est perdu sur la connexion. Si IPv6 a vraiment été tenté se confirme non d’après la réponse DNS seule mais d’après les journaux de connexion ou une capture.

Microsoft ne recommande pas de désactiver IPv6 comme remède, parce que certains composants Windows cessent de fonctionner. À la place, il décrit le réglage de DisabledComponents à 0x20 pour préférer IPv4 dans la politique de préfixe.³⁸ Le cas où localhost se résout en ::1 et entre en conflit avec une enquête qui supposait 127.0.0.1 est aussi couvert dans l’article sur la capture de paquets.

8. La procédure d’isolement — retirer les couches depuis le haut

Sur le PC qui échoue, exécutez ce qui suit dans l’ordre. Chaque commande existe pour restreindre le chemin, et son succès seul ne prouve pas le chemin emprunté dans la résolution quotidienne. Combinez la comparaison des résultats avec la capture à la fin.

Étape 1 : Vérifier la forme du nom

Vérifiez, dans un journal ou un fichier de configuration, le nom que l’application passe réellement. Le chemin change selon qu’il s’agit d’un nom à étiquette unique, qu’il se termine par .local, ou qu’il a un point final. Pour un nom court tel que http://app01/, partez de la complétion de la section 4.1 et des différences par PC de la section 5.4.

Étape 2 : Peut-il être résolu depuis le cache et hosts seuls ?

Resolve-DnsName -Name 'app01.corp.example.com' -CacheOnly
Get-DnsClientCache -Entry 'app01.corp.example.com'
Get-Content "$env:SystemRoot\System32\drivers\etc\hosts" | Select-String -Pattern 'app01'

-CacheOnly ne restreint cette consultation qu’au cache local. Si une mauvaise réponse a été apprise du serveur DNS, la même valeur revient après le vidage. Le fait qu’elle était dans le cache n’est pas la preuve que le serveur DNS n’est pas concerné.⁸

Étape 3 : Peut-il être résolu via DNS seul ?

# Exclure hosts, n'envoyer ni LLMNR ni NetBIOS, et n'interroger que les serveurs DNS configurés
Resolve-DnsName -Name 'app01.corp.example.com' -NoHostsFile -DnsOnly

Si l’étape 2 n’avait pas de réponse et que cette étape réussit simplement, c’est en général un manque de cache ordinaire. On ne peut parler d’un problème de cache ou de hosts que lorsque l’étape 2 a montré une réponse périmée, une mauvaise réponse, ou une entrée de cache négatif.

Si cette étape échoue aussi, enquêtez sur la route vers le serveur DNS, le côté serveur, et les stratégies côté client. Avant de passer à l’étape 4, vérifiez ce qui suit.

• Get-DnsClientNrptPolicy -Effective : y a-t-il une règle qui dirige le nom vers un autre serveur DNS ?
• Get-DnsClientDohServerAddress et la stratégie de groupe DoH : « Exiger DoH » est-il posé face à un serveur qui ne le prend pas en charge ?

S’il y a une NRPT, les serveurs cibles de l’étape 4 changent. Si « Exiger DoH » est la cause, seule la résolution de noms échoue tandis que la route et le serveur sont tous deux sains. Terminez d’abord les vérifications des sections 4.4 et 6.1.

Étape 4 : Interroger chaque serveur directement

Collectez les serveurs DNS des adaptateurs connectés, et si une règle NRPT s’applique au nom cible, remplacez-les par les serveurs de cette règle. Incluez aussi les serveurs DNS configurés seulement pour IPv6.

$name = 'app01.corp.example.com'
# Collecter les serveurs DNS des interfaces connectées depuis IPv4 et IPv6.
# Les serveurs restés dans les réglages d'un VPN ou d'un commutateur virtuel déconnecté ne font pas partie du chemin de résolution actuel, donc les exclure (ne pas manquer les serveurs configurés seulement pour IPv6)
$connected = @((Get-NetIPInterface -ConnectionState Connected).ifIndex | Select-Object -Unique)
$servers = @((Get-DnsClientServerAddress |
    Where-Object { $_.ServerAddresses -and ($connected -contains $_.InterfaceIndex) }).ServerAddresses)
# Les serveurs de la règle NRPT qui s'applique à ce nom (écrits par Always On VPN ou DirectAccess) n'apparaissent pas dans les réglages de l'adaptateur, donc les prendre dans la stratégie effective.
# Le paramètre -Namespace de Get-DnsClientNrptPolicy ne filtre que sur l'attribut Namespace de la règle ; il ne met pas en correspondance le nom.
# Donc mettre en correspondance soi-même la règle Any (.), les règles de suffixe (point initial ; s'appliquent à l'espace de noms lui-même et aux domaines enfants), les règles FQDN, et les règles de préfixe (la partie nom d'hôte ; les jokers tels que web* sont autorisés),
# et retenir la règle plus spécifique (plus longue). La règle Any est la plus courte, donc elle n'est choisie que lorsqu'aucune autre règle ne correspond
# Namespace est un ensemble de chaînes (affiché comme Namespace : {.corp.example.com}), donc développer les éléments de chaque règle pour la correspondance et trier par la longueur de l'espace de noms correspondant
# Pour un nom absolu avec un point final (app01.corp.example.com.), retirer le point seulement pour la correspondance. Passer le $name d'origine à Resolve-DnsName
$matchName = $name.TrimEnd('.')
$label = $matchName.Split('.')[0]
$matched = foreach ($policy in @(Get-DnsClientNrptPolicy -Effective)) {
    foreach ($ns in @($policy.Namespace)) {
        if (-not $ns) { continue }
        $hit = if ($ns -eq '.') { $true }
               elseif ($ns.StartsWith('.')) { $matchName.Equals($ns.TrimStart('.'), [System.StringComparison]::OrdinalIgnoreCase) -or $matchName.EndsWith($ns, [System.StringComparison]::OrdinalIgnoreCase) }
               elseif ($ns.Contains('.')) { $matchName.Equals($ns, [System.StringComparison]::OrdinalIgnoreCase) }
               else { $label -like $ns }
        if ($hit) { [pscustomobject]@{ Namespace = $ns; Policy = $policy } }
    }
}
$rule = $matched | Sort-Object { $_.Namespace.Length } -Descending | Select-Object -First 1
$policyServers = @()
if ($rule) { $policyServers = @(@($rule.Policy.NameServers) + @($rule.Policy.DirectAccessDnsServers) | Where-Object { $_ }) }
if ($policyServers.Count -gt 0) {
    # Si la NRPT spécifie des serveurs pour cet espace de noms, l'interrogation de l'étape 3 va vers ces serveurs. Les serveurs de l'adaptateur sont hors du chemin, donc les remplacer
    $servers = $policyServers
}
$servers = $servers | Where-Object { $_ } | Select-Object -Unique
foreach ($server in $servers) {
    $sw = [System.Diagnostics.Stopwatch]::StartNew()
    try {
        $r = Resolve-DnsName -Name $name -Server $server -DnsOnly -ErrorAction Stop
        $status = 'OK'
        # Plusieurs enregistrements peuvent revenir dans un ordre différent par réponse, donc trier avant de comparer
        $answer = ($r.IPAddress | Sort-Object) -join ','
    } catch {
        # Les réponses négatives (le nom n'existe pas), SERVFAIL et les délais d'expiration atterrissent ici. Conserver la raison au lieu de la jeter
        $status = $_.Exception.Message
        $answer = ''
    }
    [pscustomobject]@{ Server = $server; Status = $status; Answer = $answer; Milliseconds = [int]$sw.ElapsedMilliseconds }
}

D’abord, aligner les serveurs à comparer

Les NameServers et DirectAccessDnsServers de la NRPT peuvent ne pas apparaître dans les réglages DNS de l’adaptateur. Si l’étape 3 a interrogé les serveurs de la NRPT mais que l’étape 4 n’examine que les serveurs de l’adaptateur, vous finissez par comparer des chemins différents.

La NRPT a des types de règles tels que suffixe, FQDN, préfixe et Any (.), et les règles plus spécifiques ont la priorité.⁴⁰ -Namespace ne filtre que sur l’attribut de la règle ; il ne met pas en correspondance le nom d’hôte. C’est pourquoi le code ci-dessus développe les espaces de noms des règles et les met en correspondance avec le nom cible.²³

Sur un VPN à DNS partagé (split-DNS), il est normal que le résolveur côté domicile renvoie une réponse négative pour un nom interne tandis que seul le côté NRPT en renvoie une positive. Si vous comparez aussi des serveurs hors du chemin, enregistrez-les séparément comme « témoin » et ne les mélangez pas dans le jugement des écarts de zone. Les délais d’expiration face aux serveurs restés sur des adaptateurs déconnectés sont de même distincts des délais sur le chemin de résolution actuel.

Ensuite, lire les résultats à part

S’ils diffèrent aussi en tant qu’ensembles, vérifiez le contenu des zones et les numéros de série. De plus, ceci est une mesure avec la destination épinglée par -Server. Le délai causé par la position dans la liste, « 4 secondes jusqu’à ce que les quatrième serveur et suivants soient atteints » de la section 4.2, se vérifie à l’étape 3 ou dans sa capture.

Étape 5 : Vérifier la couche de lien local

Resolve-DnsName -Name 'app01' -LlmnrOnly          # LLMNR seulement
Resolve-DnsName -Name 'app01' -LlmnrNetbiosOnly   # LLMNR ou NetBIOS seulement (pas de DNS)
nbtstat -c                                        # Cache de noms NetBIOS

Cette vérification vise les noms à étiquette unique. -NetbiosFallback ne retombe sur NetBIOS que lorsque DNS échoue, donc pour un nom que DNS peut résoudre ce n’est pas une vérification NetBIOS.⁸

Lisez les résultats comme suit.

Quel protocole a répondu se distingue dans une capture par UDP 5355 (LLMNR) versus UDP 137 (NetBT). Pour confirmer le chemin de résolution quotidien, comparez aussi avec l’adresse renvoyée par Resolve-DnsName sans commutateurs, et s’ils divergent, vérifiez la réponse retenue dans la capture, parce que par défaut DNS est aussi interrogé en parallèle.

Étape 6 : Faire le diff des dumps de réglages

Dans une enquête « seulement certains PC », exécutez le même script sur un PC qui fonctionne et un PC qui échoue et comparez.

# name-resolution-dump.ps1 -- exécuter avec des droits d'administrateur et comparer côte à côte les fichiers de sortie des deux machines
$out = "$env:COMPUTERNAME-name-resolution.txt"
$sections = [ordered]@{
    'Get-DnsClientServerAddress' = { Get-DnsClientServerAddress | Format-Table -AutoSize | Out-String -Width 200 }
    'Get-DnsClientGlobalSetting' = { Get-DnsClientGlobalSetting | Format-List | Out-String }
    'Get-DnsClient'              = { Get-DnsClient | Format-Table InterfaceAlias, ConnectionSpecificSuffix, UseSuffixWhenRegistering -AutoSize | Out-String -Width 200 }
    'Get-DnsClientNrptPolicy'    = { Get-DnsClientNrptPolicy -Effective | Format-List | Out-String }
    'Get-DnsClientDohServerAddress' = { Get-DnsClientDohServerAddress | Format-Table -AutoSize | Out-String -Width 200 }
    'netsh dnsclient show state' = { netsh dnsclient show state 2>&1 | Out-String }
    'Get-NetIPInterface'         = { Get-NetIPInterface | Sort-Object AddressFamily, InterfaceMetric | Format-Table InterfaceAlias, AddressFamily, InterfaceMetric, ConnectionState, Dhcp -AutoSize | Out-String -Width 200 }
    'DNSClient policy registry'  = { Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient' -ErrorAction SilentlyContinue | Format-List | Out-String }
    'ipconfig /all'              = { ipconfig /all | Out-String }
}
$sections.GetEnumerator() | ForEach-Object {
    "===== $($_.Key) ====="
    try { & $_.Value } catch { "ERROR: $($_.Exception.Message)" }  # Laisser les éléments manquants (tels que DoH sous Windows 10) enregistrés comme erreurs
} | Set-Content -Path $out -Encoding UTF8
Write-Host "wrote $out"

Ce qu’il faut comparer, ce sont l’ordre des serveurs DNS, la liste de recherche, les suffixes spécifiques à la connexion, la NRPT, DoH, les métriques d’interface et les valeurs de stratégie.

HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient détient EnableMulticast pour « Désactiver la résolution de noms de multidiffusion », DisableSmartNameResolution pour « Désactiver la résolution de noms intelligente multi-adresses », la liste de recherche, le suffixe principal, etc.⁴ Vérifiez le diff contre le fonctionnement de chaque couche rangé jusqu’ici.

Étape 7 : L’étayer avec une capture de paquets

La procédure de collecte de données de Microsoft démarre netsh trace start capture=yes à la fois sur le client et sur le serveur, jette le cache avec ipconfig /flushdns, reproduit le problème, et s’arrête avec netsh trace stop.⁴¹

Dans Wireshark, filtrez avec dns.qry.name == "app01.corp.example.com" ou dns.qry.name contains "app01" pour voir quel serveur a été interrogé sur quoi, et ce qui est revenu.

Si le pare-feu côté émission bloque UDP 53, Resolve-DnsName expire et aucune interrogation DNS n’apparaît non plus dans la capture. Isolez non seulement le cas où la résolution de noms réussit et aucun trafic ne sort, mais aussi le cas où elle échoue et aucun trafic ne sort.³

Au-delà de DNS, vérifiez 5355 pour LLMNR, UDP 5353 pour mDNS, et UDP 137 pour le service de noms NetBT. DoH est 443 et DoT est 853. Comment capturer et lire les captures est rassemblé dans l’article sur la capture de paquets.

9. Concevoir côté application métier — la rendre robuste face à la résolution de noms

Pour alléger les enquêtes, il importe que le côté application puisse enregistrer « quel nom, résolu en quoi, et où cela a échoué ». Recouper le journal de l’application avec les dumps de réglages et les captures que les responsables informatiques collectent rend plus facile de décider où commencer au chapitre 8.

Conservez les destinations en FQDN et ne dépendez pas de hosts

Faites des FQDN les valeurs par défaut des fichiers de configuration, des raccourcis et des chemins UNC. Cela retire la dépendance à la complétion par suffixe des noms à étiquette unique et à LLMNR et NetBT. Les précautions de la section 5.4 restent toutefois : mDNS à côté de DNS pour les noms .local, et la stratégie qui ajoute des suffixes aux noms sans point final.

hosts est commode pour un remplacement temporaire pendant le développement, mais il exige des droits d’administrateur et du travail manuel. La distribution et l’historique des changements sont difficiles à gérer, et certains résolveurs ne le consultent pas du tout (nslookup ne le fait pas¹²). Basculez les destinations via les fichiers de configuration.

Enregistrez le résultat, le temps et la raison d’échec de la résolution de noms

Au démarrage et à des points analogues, enregistrez les adresses IPv4 et IPv6 et le temps écoulé pour les destinations principales. Parce que Dns.GetHostAddresses renvoie le même résultat que getaddrinfo, vous pouvez retracer « sur quel PC, depuis quand, en quoi cela a été résolu ».¹¹

// Enregistrer les résultats de résolution de noms des destinations principales au démarrage (.NET 6 ou une version ultérieure)
static async Task LogNameResolutionAsync(ILogger logger, string host)
{
    var sw = System.Diagnostics.Stopwatch.StartNew();
    try
    {
        var addresses = await System.Net.Dns.GetHostAddressesAsync(host);
        logger.LogInformation("Résolution de noms {Host} -> {Addresses} ({Elapsed} ms)",
            host, string.Join(",", addresses.Select(a => a.ToString())), sw.ElapsedMilliseconds);
    }
    catch (System.Net.Sockets.SocketException ex)
    {
        logger.LogError(ex, "Échec de la résolution de noms {Host} erreur {Code} ({Elapsed} ms)",
            host, ex.SocketErrorCode, sw.ElapsedMilliseconds);
        throw;
    }
}

Journalisez les échecs et relancez. Basculer en silence vers un autre nom ou une IP fixe rend le chemin réel inconnaissable pendant une enquête. Avec le code d’erreur et le temps écoulé, les responsables informatiques peuvent décider où commencer aux étapes 2 à 4.

Prévoyez les délais d’expiration et les réponses IPv6

Le client DNS passe jusqu’à 10 secondes par candidat interrogé face à des serveurs qui ne répondent pas.²¹ Si la recherche de suffixes produit plusieurs candidats, le total peut dépasser 10 secondes.

Si le délai d’expiration de connexion est resserré à 2 ou 3 secondes, la résolution de noms ne se termine pas avant l’échéance dans des configurations telles que celle où le serveur qui peut répondre est quatrième ou plus loin. Le deuxième serveur, toutefois, est interrogé après 1 seconde et le troisième après 2 secondes, donc un seul serveur en échec ne signifie pas nécessairement l’échec. Concevez en ayant à l’esprit le calendrier de retransmission de la section 4.2.

De plus, lorsqu’une réponse AAAA revient et qu’une adresse source IPv6 et une route existent, Windows préfère IPv6 par défaut.³⁸ Du code de connexion qui suppose IPv4 seulement peut échouer à se connecter alors même que la résolution de noms a réussi. Séparez le succès de la résolution de noms du succès de la connexion, et gérez les deux sortes d’adresse.

10. Résumé

Les premières choses à séparer dans la résolution de noms Windows sont la forme du nom, la couche qui renvoie la réponse, et le chemin que l’application emprunte.

Le cache et hosts répondent d’abord, et pour les noms à étiquette unique DNS et LLMNR/NetBT s’exécutent en parallèle par défaut. Pour .local, mDNS s’ajoute. Une fois que la résolution passe à DNS, les suffixes, le calendrier de retransmission, plusieurs NIC et la NRPT changent le résultat. DoH est une fonction qui bascule ce transport, et on la considère séparément du résolveur intégré du navigateur.

L’enquête restreint le chemin dans l’ordre -CacheOnly, puis -NoHostsFile -DnsOnly, puis -Server, puis -LlmnrOnly, et confirme avec un diff de réglages et une capture. Ce qui importe, c’est de ne pas manquer le cache négatif, la différence entre aucune réponse et une réponse négative, et les stratégies côté client.

Lorsque « seul ce PC ne se connecte pas », vérifiez d’abord ces deux choses.

Sous quelle forme le nom est-il passé ? Sur ce PC, quel chemin répond ?

Ces deux points établis, vous pouvez resserrer où regarder.

Articles connexes

• Capture de paquets sous Windows en pratique — choisir entre pktmon, netsh trace et Wireshark
• Proxy d’entreprise et applications Windows — démêler la résolution de proxy dans WinINET, WinHTTP et .NET
• N’enfermez pas HttpClient dans un using — la communication HTTP en C# pour applications métier (modèles de création, délais d’expiration, tentatives)
• Le pare-feu Windows et les applications métier — enregistrer les règles entrantes depuis l’installateur
• Les pièges des lecteurs réseau et des chemins UNC — Travailler avec un serveur de fichiers (dossier partagé) depuis une application métier
• NTLM et Kerberos expliqués en images — Pourquoi l’authentification « retombe »-t-elle sur NTLM ?
• Recueil de commandes PowerShell pratiques — enrichir les petits outils utilisés au quotidien

Domaines de conseil associés

KomuraSoft LLC prend en charge les enquêtes de cause racine des pannes de communication liées à la résolution de noms telles que « l’application métier n’atteint pas le serveur interne, et seulement sur certains PC » et « cela s’ouvre dans le navigateur mais l’application échoue à la résolution de noms », les revues de conception pour savoir si une application métier tient face à des changements d’environnement tels que la désactivation de LLMNR, DoH et le VPN, et l’implémentation d’une couche de communication qui enregistre les résultats de résolution de noms et les délais d’expiration. Si vous joignez les dumps de réglages d’un PC qui fonctionne et d’un PC qui échoue lorsque vous nous contactez, le point de départ de l’enquête se fixe vite.

• Analyse des bugs et des causes
• Conseil technique et revue de conception
• Développement d’applications Windows
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

J'ai modifié le fichier hosts mais le changement ne prend pas effet. Pourquoi ?

Sous Windows, le contenu du fichier hosts est chargé dans le cache au démarrage du service Client DNS, et la résolution de noms avance dans l'ordre cache, hosts, serveur DNS. Lorsque le changement ne prend pas effet, vérifiez d'abord l'entrée de ce nom avec ipconfig /displaydns, et s'il reste une ancienne réponse, jetez-la avec ipconfig /flushdns. Ensuite, demandez-vous si l'outil avec lequel vous testez passe vraiment par le résolveur Windows. nslookup n'utilise pas le résolveur de l'OS ; il contourne le cache, hosts et la NRPT et interroge le serveur DNS directement, donc rien de hosts ne se reflète dans sa sortie. Pour voir le résultat réel de la résolution, hosts compris, utilisez Resolve-DnsName ou ping. Si cela ne prend toujours pas effet, vérifiez si l'application, comme un navigateur, a son propre résolveur ou DoH.

Le site s'ouvre dans le navigateur, mais seule l'application métier échoue à la résolution de noms.

Le plus probable est que le navigateur et l'application résolvent le nom par des chemins différents. Par défaut, Microsoft Edge parle au serveur DNS avec son client DNS intégré plutôt qu'avec le client DNS de l'OS, et si un autre fournisseur est choisi sous DNS sécurisé (DoH), il interroge un résolveur externe. En revanche, Dns.GetHostAddresses de .NET, et un HttpClient qui se connecte directement à la destination, passent par getaddrinfo de l'OS, donc ils sont soumis à hosts, au cache DNS, à la NRPT et à la liste de recherche de suffixes DNS (pour les requêtes qui passent par un proxy HTTP, le nom de destination est résolu côté proxy). Lorsque les deux renvoient des réponses différentes, le chemin le plus court est de recouper quel chemin a demandé quoi à quel serveur DNS, avec Resolve-DnsName et une capture de paquets.

Les réglages devraient être identiques, et pourtant seuls certains PC n'atteignent pas le serveur interne. Que faut-il comparer ?

Comparez la forme du nom et la couche à laquelle chaque PC obtient sa réponse. Un nom à étiquette unique (un nom sans point, tel que server01) est complété avec la liste de recherche de suffixes DNS du PC ou le suffixe spécifique à la connexion et envoyé à DNS, et par défaut il est aussi envoyé, en parallèle, à des mécanismes limités au même sous-réseau tels que LLMNR et la diffusion NetBIOS (ils ne sont tentés en séquence après un échec DNS que lorsque l'optimisation a été désactivée ; si WINS est configuré, NetBIOS utilise l'unicast et peut traverser les sous-réseaux). Un PC joint à un domaine peut résoudre le nom parce que le suffixe le complète en FQDN, tandis qu'un PC en VPN ou sur un autre sous-réseau, ou un PC avec LLMNR et NetBIOS désactivés, ne peut pas résoudre le même nom. La méthode fiable est de collecter la sortie de Get-DnsClientServerAddress, Get-DnsClientGlobalSetting, Get-DnsClient et Get-DnsClientNrptPolicy -Effective à la fois sur un PC qui fonctionne et sur un PC qui échoue, et d'en faire le diff. La correction de fond est de mettre les destinations des fichiers de configuration et des raccourcis en FQDN.

La résolution de noms n'échoue pas ; elle met simplement plusieurs secondes avant que la connexion passe enfin. Quelle en est la cause ?

C'est le mécanisme de délai d'expiration et de nouvelle tentative du client DNS qui affleure. Face à un serveur DNS qui ne répond pas, Windows retransmet à 1, 2, 4 et 8 secondes depuis le début et abandonne à 10 secondes. Même avec plusieurs serveurs DNS configurés, si celui qui répond est quatrième ou plus loin dans la liste, Windows attend au moins 4 secondes avant d'interroger ce serveur. Une longue liste de recherche de suffixes DNS empile aussi du délai, parce qu'un nom à étiquette unique est essayé avec chaque suffixe à tour de rôle. Mesurez combien de temps prend Resolve-DnsName avec Measure-Command, et appliquez un filtre dns.qry.name dans Wireshark pour voir les interrogations de quel serveur restent sans réponse.

Nous avons désactivé LLMNR et NetBIOS comme mesure de sécurité, et maintenant certains appareils ne sont plus joignables par nom.

C'est un effet secondaire attendu. LLMNR et NetBIOS over TCP/IP sont des moyens secondaires de résoudre les noms à étiquette unique d'appareils non enregistrés dans DNS à l'intérieur du même sous-réseau, et les désactiver supprime ce chemin. Microsoft lui-même a annoncé en 2022 une orientation consistant à s'aligner sur mDNS et à réduire progressivement la résolution de noms NetBIOS et LLMNR, donc la décision de les désactiver est en elle-même la bonne. Le remède est de concentrer la résolution de noms sur DNS : enregistrer les enregistrements A des appareils dans le DNS interne, ou activer l'enregistrement dynamique via DHCP, et réécrire les destinations des applications et des partages en FQDN. Les appareils qui prennent en charge mDNS peuvent être résolus par leurs noms .local, mais ce chemin aussi est limité à la portée que la multidiffusion atteint.

Que devient la résolution de noms interne lorsque j'active DoH (DNS over HTTPS) sous Windows 11 ?

DoH est une fonction qui bascule le transport vers HTTPS lorsque le client DNS interroge les serveurs DNS configurés ; l'ordre existant de hosts, du cache et de la NRPT reste tel quel. Sauf si DDR (Discovery of Designated Resolvers) est activé, DoH ne peut être utilisé que lorsque le serveur figure dans la liste des serveurs DoH connus, donc si vous voulez utiliser un serveur DNS interne, un administrateur doit l'enregistrer avec Add-DnsClientDohServerAddress. Si le paramètre de stratégie de groupe « Configurer la résolution de noms DNS over HTTPS (DoH) » est réglé sur « Exiger DoH », la résolution de noms elle-même échoue face aux serveurs qui ne prennent pas en charge DoH. Microsoft dit explicitement de ne pas activer ce paramètre sur les PC joints à un domaine, parce que le service Serveur DNS livré avec Windows Server, dont Active Directory dépend, ne prend pas en charge les interrogations DoH.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.