14

I have a number of multihomed Windows 10 client VMs joined to a Windows 2012 R2 domain. Ethernet1 is connected to a LAN with the domain controllers (which do not have forwarders, or access to the root servers), Ethernet2 is connected to a LAN with access to the internet, Ethernet0 and Ethernet3 both have their media disconnected. Queries for records from the domain controllers are returned just fine, but queries for records from the internet take 10 seconds plus however long my ISP's DNS servers take to return a response. If I query my ISP's DNS servers directly via nslookup the name is resolved promptly (< 1 second), if I just run nslookup without specifying a DNS server the query times out and the name is never resolved, and if I try to ping the DNS name it takes > 10 seconds before the name is resolved.

I've looked around Technet, but there doesn't seem to be any documentation yet on Windows 10. The best i've found is:

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

Which says that I should expect my client to query the primary DNS server for Ethernet1, wait 1 second for the response to timeout, and then query both the secondary DNS server for Ethernet1 and the primary DNS server for Ethernet2, but this doesn't seem to be happening. The documentation goes on to say that after 10 seconds (and more 3 more rounds of DNS queries with longer timeouts) DNS resolution would fail completely for all adapters, but the behavior of the client gives the impression it is taking 10 seconds before even attempting to use the DNS servers for the second adapter.

Absent me (or you) opening up Wireshark and sniffing the line, or blindly modifying HKLM\System\CurrentControlSet\Services\dnscache\Parameters\DNSQueryTimeouts does anyone know how Windows 10 is supposed to behave, and more importantly how I can go about configuring the behavior? I'm willing to live with a ~1 second resolution time, but 10 seconds is rather 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

Update

In case anyone else is wondering, I joined a Win7 SP1 (no patches) VM with the same network adapter configuration to the domain, moved it in to the same OU as the other VMs and updated group policy on the client just in case. It is able to resolve DNS queries both from the DC's DNS servers and my ISPs immediately. So it looks like this is behavior specific to the Windows 10 DNS client.

Update 2

So things are getting stranger. It does look like Win10 by default will issue the queries in parallel but it will not pass the response on to whatever process requested it until all queries timeout. And for some reason the DNS server on my 2nd domain controller isnt working. Does anyone know how to disable this behavior?

Wireshark Packet Trace

Improve this question
7
  • Have a look at this question: superuser.com/questions/966017/… haarymc pointed out that the Windows 10 DNS resolver was significantly modified and points out some possible solutions.
    – Brandon Xavier
    Sep 8, 2015 at 23:43
  • I would start with DisableSmartNameResolution which was mentioned.
    – Brandon Xavier
    Sep 8, 2015 at 23:50
  • Brandon, it looks like setting DisableSmartNameResolution to 1 (rather than 0 as recommended by the link) worked! If you want to post it is as a answer, i'll award the rep. Thanks!
    – Matt
    Sep 9, 2015 at 0:32
  • LOL, so much projection. Stay mad that Brandon Xavier found the problem here, will be getting the +100 rep when he reposts his comment as an answer, and that you couldn't be bothered to read your own citations.
    – Matt
    Sep 9, 2015 at 3:05
  • 1
    Here's another good link about this new feature, and how it changes from Windows 8.1 to Windows 10. medium.com/@ValdikSS/…
    – GuitarPicker
    Sep 9, 2015 at 12:51

3 Answers 3

Reset to default
15
+100

Microsoft has in Windows 10 substantially modified or rewritten the DNS Resolver.

The biggest change was to issue DNS queries to all adapters in parallel, then take the first answer to arrive. Unfortunately the new code contains bugs and omissions, and it seems that rather than take the first answer, it waits for all answers. If one of the DNS queries will time-out, this means a 10-seconds wait before the DNS is resolved.

This bug will undoubtedly be fixed in a future update of Windows 10. Until then, to return the behavior as much as possible to that of previous Windows versions, the following registry modifications exist :

DisableSmartNameResolution (DWORD)

In registry key HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\DNSClient.
The value is 1 to disable, 0 to enable smart resolution.
From Turn off smart multi-homed name resolution :

Specifies that a multi-homed DNS client should optimize name resolution across networks. The setting improves performance by issuing parallel DNS link local multicast name resolution (LLMNR) and NetBIOS over TCP/IP (NetBT) queries across all networks. In the event that multiple positive responses are received the network binding order is used to determine which response to accept.If you enable this policy setting the DNS client will not perform any optimizations. DNS queries will be issued across all networks first. LLMNR queries will be issued if the DNS queries fail followed by NetBT queries if LLMNR queries fail.If you disable this policy setting or if you do not configure this policy setting name resolution will be optimized when issuing DNS LLMNR and NetBT queries.

DisableParallelAandAAAA (DWORD)

In registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters.
The value is 0 to enable, 1 to disable DNS A and AAAA queries from executing in parallel on all configured DNS servers, with the fastest response being theoretically accepted first.

Improve this answer
4
  • 2
    Just wanted to add that I am on Win 10.0.10586 and HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\DNSClient does not exist. Also, DisableParallelAandAAAA does not exist but the keys do exist so one can add it.
    – Mahdi
    Feb 23, 2016 at 18:24
  • This has solved the VPN split-dns problem on Windows 10. When connected to a vpn (ie. using a Cisco client), the vpn's dns is only used some of the time because of these two features. By disabling both of these (Smart name resolution and Parallel dns queries), it allows the VPN's dns to be used reliably. Also, it solves the "dns leak" issue that you have when on an insecure/untrusted wi-fi network such as at a coffee shop with Windows 10. Your dns queries will go over the vpn now instead of sometimes going to the coffee shop's dns. Thank you so much for providing this solution!
    – truemedia
    Nov 14, 2016 at 20:02
  • 3
    Handy PowerShell version for anyone hitting this (we are at Stack Exchange): Set-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient" -Name DisableSmartNameResolution -Value 1 -Type DWord and Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" -Name DisableParallelAandAAAA -Value 1 -Type DWord
    – Nick Craver
    Apr 27, 2017 at 2:34
  • 3
    These registry key had no effect on my windows10, what worked was: 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
    Dec 5, 2018 at 14:05
1

source

SMHNR is slightly changed for Windows 10 compared to Windows 8. In Windows 10, you can’t turn it off via the registry.

For Windows 10, you can use "Local Policies" to deactivate the feature. Follow the steps below to do this:

  • 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"
Improve this answer
1
  • Julien, I'm not saying the paths haven't moved in the registry but when you update settings in the Local Policy, the overwhelming majority of what you're doing is making registry changes (by Local Policy Editor). In fact, this is a very common way to figure out what part of the registry to directly modify for a particular setting. Run ProcMon (from Sysinternals) and make the change and then determine what the effective registry path in what hive was updated from what to what.
    – thepip3r
    Dec 5, 2018 at 14:20
0

Since your domain DNS servers don't have access to the root servers and you don't have forwarding set up, you need to delete your unreachable root hints from the DNS server to speed up the queries for addresses it doesn't host. This should speed up the timeouts, and in turn speed up client resolution. Otherwise, it's going to keep trying to contact the root servers before giving up.

The procedure for removing root hints on 2008 R2 is documented here.

Improve this answer
6
  • Thanks for the response but this question was regarding the behavior of the clients, not the domain controller's DNS server, as noted by "...does anyone know how Windows 10 is supposed to behave, and more importantly how I can go about configuring the behavior"
    – Matt
    Sep 8, 2015 at 20:21
  • Fair enough. It sounded like the clients were behaving this way due to a non-optimal configuration. Do you have any non Windows 10 clients that behave differently?
    – GuitarPicker
    Sep 8, 2015 at 20:56
  • No, I have other Win10 VM clients which have Ethernet3 (VPN based internet access and DNS server 1.2.3.4) connected instead of Ethernet2, and they behave the same. And how would a multihomed client with DNS servers for both networks ever be considered non-optimal?
    – Matt
    Sep 8, 2015 at 21:09
  • 1
    GuitarPicker, I tried your non-Win10 client suggestion and it looks like this is behavior specific to Windows 10.
    – Matt
    Sep 9, 2015 at 1:58
  • @harrymc's answer looks like it will take care of things on the client side. I actually found it after reading your comment and before reading his answer. Microsoft is surprisingly quiet about documenting it. My solution might give you a little bit more boost in resolution time for all clients, but his answer would explain the difference in clients.
    – GuitarPicker
    Sep 9, 2015 at 12:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .