Délais d'expiration de la résolution DNS Windows 10 multirésident

J'ai un certain nombre de machines virtuelles clientes Windows 10 multi-hôtes jointes à un domaine Windows 2012 R2. Ethernet1 est connecté à un LAN avec les contrôleurs de domaine (qui n'ont pas de redirecteurs, ni accès aux serveurs racine), Ethernet2 est connecté à un LAN avec accès à Internet, Ethernet0 et Ethernet3 ont tous les deux leurs médias déconnectés. Les requêtes pour les enregistrements des contrôleurs de domaine sont renvoyées très bien, mais les requêtes pour les enregistrements à partir d'Internet prennent 10 secondes, plus le temps que prennent les serveurs DNS de mon FAI pour renvoyer une réponse. Si j'interroge les serveurs DNS de mon FAI directement via nslookuple nom est résolu rapidement (<1 seconde), si je viens de lancer nslookupsans spécifier de serveur DNS, la requête expire et le nom n'est jamais résolu, et si j'essaie de cingler le nom DNS, il prend> 10 secondes avant que le nom ne soit résolu.

J'ai regardé Technet, mais il ne semble pas encore y avoir de documentation sur Windows 10. Le meilleur que j'ai trouvé est:

http://blogs.technet.com/b/networking/archive/2009/06/26/dns-client-resolver-behavior.aspx http://blogs.technet.com/b/stdqry/archive/2011/12 /15/dns-clients-and-timeouts-part-2.aspx

Ce qui signifie que je dois m'attendre à ce que mon client interroge le serveur DNS principal pour Ethernet1, attend 1 seconde pour la réponse au délai d'expiration, puis interroge à la fois le serveur DNS secondaire pour Ethernet1 et le serveur DNS principal pour Ethernet2, mais cela ne semble pas se produire. La documentation poursuit en disant qu'après 10 secondes (et plus de 3 cycles supplémentaires de requêtes DNS avec des délais plus longs) la résolution DNS échouerait complètement pour tous les adaptateurs, mais le comportement du client donne l'impression qu'il faut 10 secondes avant même d'essayer de utilisez les serveurs DNS pour le deuxième adaptateur.

En l'absence de moi (ou de vous) ouvrant Wireshark et reniflant la ligne, ou en modifiant aveuglément HKLM\System\CurrentControlSet\Services\dnscache\Parameters\DNSQueryTimeoutsquelqu'un sait-il comment Windows 10 est censé se comporter, et plus important encore, comment puis-je procéder pour configurer le comportement? Je suis prêt à vivre avec un temps de résolution d'environ 1 seconde, mais 10 secondes est plutôt brutal.

ipconfig

Ethernet adapter Ethernet1:

   Connection-specific DNS Suffix  . : intranet.mydomain.net
   Description . . . . . . . . . . . : Intel(R) 82574L Gigabit Network Connection #2
   Physical Address. . . . . . . . . : 00-0C-29-CC-E8-93
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::999b:3e21:749b:6f55%7(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.2.0.20(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.0.0
   Lease Obtained. . . . . . . . . . : Sunday, September 6, 2015 8:17:00 AM
   Lease Expires . . . . . . . . . . : Sunday, September 13, 2015 8:17:00 AM
   Default Gateway . . . . . . . . . :
   DHCP Server . . . . . . . . . . . : 10.2.0.2
   DHCPv6 IAID . . . . . . . . . . . : 83889193
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1D-74-AB-6A-00-0C-29-CC-E8-89
   DNS Servers . . . . . . . . . . . : 10.2.0.1
                                       10.2.0.2
   NetBIOS over Tcpip. . . . . . . . : Enabled

Ethernet adapter Ethernet2:

   Connection-specific DNS Suffix  . : internet.mydomain.net
   Description . . . . . . . . . . . : Intel(R) 82574L Gigabit Network Connection #3
   Physical Address. . . . . . . . . : 00-0C-29-CC-E8-9D
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::944:ded1:dc53:cec4%6(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.1.116(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Sunday, September 6, 2015 8:17:04 AM
   Lease Expires . . . . . . . . . . : Monday, September 7, 2015 8:17:04 AM
   Default Gateway . . . . . . . . . : 192.168.1.1
   DHCP Server . . . . . . . . . . . : 192.168.1.1
   DHCPv6 IAID . . . . . . . . . . . : 83889193
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1D-74-AB-6A-00-0C-29-CC-E8-89
   DNS Servers . . . . . . . . . . . : 75.75.75.75
                                       75.75.76.76
                                       8.8.8.8
   NetBIOS over Tcpip. . . . . . . . : Enabled

nslookup

C:\Users\username>nslookup www.google.com 75.75.75.75
Server:  cdns01.comcast.net
Address:  75.75.75.75

Non-authoritative answer:
Name:    www.google.com
Addresses:  2607:f8b0:4001:c07::69
          74.125.196.106
          74.125.196.104
          74.125.196.147
          74.125.196.105
          74.125.196.99
          74.125.196.103


C:\Users\username>nslookup www.google.com
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  10.2.0.1

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Request to UnKnown timed-out

Mise à jour

Au cas où quelqu'un d'autre se poserait la question, j'ai rejoint une machine virtuelle Win7 SP1 (sans correctifs) avec la même configuration d'adaptateur réseau vers le domaine, je l'ai déplacée vers la même unité d'organisation que les autres machines virtuelles et j'ai mis à jour la stratégie de groupe sur le client au cas où. Il est capable de résoudre immédiatement les requêtes DNS à partir des serveurs DNS du contrôleur de domaine et de mes FAI. Il semble donc que ce comportement soit spécifique au client DNS Windows 10.

Update 2

Les choses deviennent donc plus étranges. Il semble que Win10, par défaut, émettra les requêtes en parallèle, mais il ne transmettra pas la réponse au processus demandé jusqu'à l'expiration de toutes les requêtes. Et pour une raison quelconque, le serveur DNS sur mon 2ème contrôleur de domaine ne fonctionne pas. Quelqu'un sait-il comment désactiver ce comportement?

— Mat
source

Jetez un œil à cette question: superuser.com/questions/966017/… haarymc a souligné que le résolveur DNS de Windows 10 a été considérablement modifié et indique quelques solutions possibles.

— Brandon Xavier

Je commencerais par DisableSmartNameResolution qui a été mentionné.

— Brandon Xavier

Brandon, on dirait que mettre DisableSmartNameResolution sur 1 (plutôt que 0 comme recommandé par le lien) a fonctionné! Si vous voulez le poster comme réponse, je vais attribuer le représentant. Merci!

— Matt

LOL, tellement de projection. Restez fou que Brandon Xavier ait trouvé le problème ici, obtiendra le représentant +100 quand il reposera son commentaire comme réponse, et que vous ne pouviez pas être dérangé de lire vos propres citations.

— Matt

Voici un autre bon lien à propos de cette nouvelle fonctionnalité et comment elle passe de Windows 8.1 à Windows 10. medium.com/@ValdikSS/…

— GuitarPicker

Réponses:

Microsoft dans Windows 10 a considérablement modifié ou réécrit le résolveur DNS.

Le plus grand changement a été d'émettre des requêtes DNS à tous les adaptateurs en parallèle, puis de prendre la première réponse pour arriver. Malheureusement, le nouveau code contient des bogues et des omissions, et il semble que plutôt que de prendre la première réponse, il attend toutes les réponses. Si l'une des requêtes DNS expire, cela signifie une attente de 10 secondes avant la résolution du DNS.

Ce bogue sera sans aucun doute corrigé dans une future mise à jour de Windows 10. D'ici là, pour restituer autant que possible le comportement à celui des versions précédentes de Windows, les modifications de registre suivantes existent:

DisableSmartNameResolution (DWORD)

Dans la clé de registre HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\DNSClient.
La valeur est 1 pour désactiver, 0 pour activer la résolution intelligente.
À partir de Désactiver la résolution de noms multi-hébergement intelligente :

Spécifie qu'un client DNS multi-hébergé doit optimiser la résolution de noms sur les réseaux. Le paramètre améliore les performances en émettant des requêtes de résolution de nom de multidiffusion locale de liaison DNS parallèle (LLMNR) et NetBIOS sur TCP / IP (NetBT) sur tous les réseaux. Dans le cas où plusieurs réponses positives sont reçues, l'ordre de liaison réseau est utilisé pour déterminer la réponse à accepter. Si vous activez ce paramètre de stratégie, le client DNS n'effectuera aucune optimisation. Les requêtes DNS seront d'abord émises sur tous les réseaux. Les requêtes LLMNR seront émises si les requêtes DNS échouent, suivies des requêtes NetBT si les requêtes LLMNR échouent. Si vous désactivez ce paramètre de stratégie ou si vous ne configurez pas ce paramètre de stratégie, la résolution du nom sera optimisée lors de l'émission des requêtes DNS LLMNR et NetBT.

DisableParallelAandAAAA (DWORD)

Dans la clé de registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters.
La valeur est 0 pour activer, 1 pour désactiver les requêtes DNS A et AAAA de s'exécuter en parallèle sur tous les serveurs DNS configurés, la réponse la plus rapide étant théoriquement acceptée en premier.

— harrymc
source

Je voulais juste ajouter que je suis sur Win 10.0.10586 et HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\DNSClientn'existe pas. Aussi, DisableParallelAandAAAAn'existe pas mais les clés existent donc on peut l'ajouter.

— Mahdi

Cela a résolu le problème VPN split-dns sur Windows 10. Lorsqu'il est connecté à un vpn (c'est-à-dire en utilisant un client Cisco), le dns du vpn n'est utilisé qu'une partie du temps en raison de ces deux fonctionnalités. En désactivant les deux (résolution de nom intelligente et requêtes DNS parallèles), cela permet aux DNS du VPN d'être utilisés de manière fiable. En outre, cela résout le problème de "fuite DNS" que vous rencontrez lorsque vous êtes sur un réseau Wi-Fi non sécurisé / non fiable, comme dans un café avec Windows 10. Vos requêtes DNS vont maintenant passer par le VPN au lieu d'aller parfois au café. DNS. Merci beaucoup d'avoir fourni cette solution!

— truemedia

Version PowerShell pratique pour tous ceux qui frappent cela (nous sommes à Stack Exchange):

Set-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient" -Name DisableSmartNameResolution -Value 1 -Type DWord

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" -Name DisableParallelAandAAAA -Value 1 -Type DWord

— Nick Craver

Ces clés de registre n'ont eu aucun effet sur mes fenêtres10, ce qui a fonctionné était:

Press WIN+R and write gpedit.msc Expand Administrative templates Expand Network Click DNS-client Double-click "Turn off smart multi-homed name resolution" Check the box called "Enabled" Click "Apply all" and then "OK"

— Julien

la source

SMHNR est légèrement modifié pour Windows 10 par rapport à Windows 8. Dans Windows 10, vous ne pouvez pas le désactiver via le registre.

Pour Windows 10, vous pouvez utiliser des «stratégies locales» pour désactiver la fonctionnalité. Suivez les étapes ci-dessous pour ce faire:

Appuyez sur WIN + R et écrivez gpedit.msc
Développez Modèles d'administration Développez Réseau
Cliquez sur DNS-client Double-cliquez sur "Désactiver la résolution de noms multi-hébergement intelligente"
Cochez la case intitulée "Activé"
Cliquez sur "Appliquer tout" puis sur "OK"

— Julien
source

Julien, je ne dis pas que les chemins n'ont pas bougé dans le registre, mais lorsque vous mettez à jour les paramètres dans la stratégie locale, la grande majorité de ce que vous faites apporte des modifications au registre (par l'éditeur de stratégie locale). En fait, c'est un moyen très courant de déterminer quelle partie du registre modifier directement pour un paramètre particulier. Exécutez ProcMon (à partir de Sysinternals) et apportez la modification, puis déterminez le chemin de registre effectif dans quelle ruche a été mis à jour de quoi à quoi.

— thepip3r

Étant donné que vos serveurs DNS de domaine n'ont pas accès aux serveurs racine et que vous n'avez pas configuré de transfert, vous devez supprimer vos indications racine inaccessibles du serveur DNS pour accélérer les requêtes pour les adresses qu'il n'héberge pas. Cela devrait accélérer les délais d'attente et à son tour accélérer la résolution du client. Sinon, il va continuer d'essayer de contacter les serveurs racine avant d'abandonner.

La procédure de suppression des indications de racine sur 2008 R2 est documentée ici .

— GuitarPicker
source

Merci pour la réponse, mais cette question concernait le comportement des clients, pas le serveur DNS du contrôleur de domaine, comme indiqué par "... est-ce que quelqu'un sait comment Windows 10 est censé se comporter, et surtout comment je peux procéder pour configurer le comportement "

— Matt

C'est suffisant. Il semblait que les clients se comportaient de cette façon en raison d'une configuration non optimale. Avez-vous des clients non Windows 10 qui se comportent différemment?

— GuitarPicker du

Non, j'ai d'autres clients VM Win10 qui ont Ethernet3 (accès Internet basé sur VPN et serveur DNS 1.2.3.4) connecté au lieu d'Ethernet2, et ils se comportent de la même manière. Et comment un client multi-hôte avec des serveurs DNS pour les deux réseaux pourrait-il être considéré comme non optimal?

— Matt

GuitarPicker, j'ai essayé votre suggestion de client non Win10 et il semble que ce soit un comportement spécifique à Windows 10.

— Matt

La réponse de @ harrymc semble s'occuper des choses du côté client. Je l'ai trouvé après avoir lu votre commentaire et avant de lire sa réponse. Microsoft est étonnamment silencieux sur sa documentation. Ma solution pourrait vous donner un peu plus de temps de résolution pour tous les clients, mais sa réponse expliquerait la différence entre les clients.

— GuitarPicker