Windows – Multihomed Windows 10 DNS resolution timeouts

dnsmulti-homedtimeoutwindowswindows 10

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

Best Answer

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.

Related Question