I've got a strange problem with one of the machines in our organization. Namely, it's using the wrong DNS server when trying to resolve names.

The DNS configuration is pretty straightforward - we have two internal DNS servers, and the DHCP assigns the public Google DNS servers as backup.

In total, a DHCP client receives the following DNS servers, in order:

  • Internal DNS #1
  • Internal DNS #2

This configuration works for everyone... except one Windows 10 machine, which seems to be using the Google DNS rather than the internal DNS. That machine has internet access, of course, but cannot access our internal resources. It's also worth noting that the machine can ping both the DNS servers and our internal IPs just fine, so this doesn't appear to be a connectivity problem.

Stranger still, IF that machine connects via WiFi (the DHCP remains the same, there's just an AP in the way), then the correct, internal, DNS is used.

There are no custom IPv4 settings on that machine, and I'm not aware of Windows using any other kind of DNS priority system beyond the order in which the servers are listed.

What could be wrong here?

EDIT: Some additional information:

  • All machines are connected to a local DC
  • The machine in question, when running nslookup will show the default DNS server being used as
  • Using nslookup <internalDNSname> <internal DNS IP> on the target machine works and produces the expected result, so the machine in question can communicate with our DNS servers just fine
  • If I remove the public Google DNS servers from the DHCP configuration and refresh the connection on the target machine everything works fine and internal DNS servers are used. If I re-add the Google DNS servers, the machine will start using those once more.
  • You can 'hide' a DNS server in the connection's Advanced settings - what's the output of ipconfig -all on the machine? Additionally, with a DHCP reservation, there can be special settings for that machine. – Zac67 Jul 10 '17 at 14:12
  • Are these machines joined to an Active Directory domain? – joeqwerty Jul 10 '17 at 15:04
  • What happens if you do nslookup with debug=on? Do you see it try to hit the internal DNS servers? IE: nslookup -debug=on google.com – RobbieCrash Jul 10 '17 at 17:10
  • The owner of the machine isn't at work today - I'll update the question with the relevant information as soon as I am able. – Shaamaan Jul 11 '17 at 10:34
  • @joeqwerty Yes, they are. – Shaamaan Jul 11 '17 at 10:35

If the wireless adapter is working OK then it does sound like a setting configured locally on the NIC properties or a DHCP reservation that is giving out different option information to that NIC. I would check IPv4 > Advanced for the NIC that is having the problems and check DHCP to make sure no one has configured a reservation for that NIC with the wrong options.

Have you tried configuring the DNS setting statically? if you do that does the Win10 machine use the correct DNS Settings?


It sounds like the machine is failing to contact the internal DNS servers, or it's not getting a valid resolution.

The DNS client initiates queries in specified order in rapid succession. If the primary is too slow and the secondary responds sooner, it may favor the secondary for subsequent queries. However, since external DNS servers won't have a resolution for your internal names, it should come back around and attempt those internal DNS servers.

What happens when you do an nslookup against those internal servers, do they respond with a resolution for an internal hostname?

Does your network adapter for the eth connection have the proper advanced DNS settings? (e.g: Appending DNS Suffix). Does that look the same as your Wifi adapter?

What happens when you restart the DNS Client service on that workstation?

  • nslookup against internal DNS servers works fine. – Shaamaan Jul 11 '17 at 10:34
  • Ok, so honestly... it doesn't sound like there's a problem. The workstation uses internal DNS servers to properly resolve internal hostnames, and uses the external DNS server to resolve external names. It sounds like you would ideally like to have it use the internals for all queries, but it's quite possible that the external servers are just faster for those queries (cutting out a hop). DNS will "switch" the preferences if one responds sooner, as I stated above. If you want to benchmark it to vett that theory, use a tool like Dig, which will give you query response times. – Ulfy Jul 11 '17 at 13:46
  • Uhm, no. There IS a problem. nslookup, when started, indicates it's using as the primary DNS, when it should be using our internal DNS. As such that particular machine isn't resolving ANY internal DNS names. Google's DNS doesn't know of any of our internal names after all. I can force nslookup to use our internal DNS servers - nslookup <internal name> <internal DNS IP> will produce expected results, but nslookup <internal name> will fail. – Shaamaan Jul 11 '17 at 13:48
  • I covered that in my original answer. Even if the workstation had it as a primary preference, the lack of a valid response would trigger it to attempt your other DNS Servers. Order doesn't matter if the subsequent servers can handle it. Something else is wrong here... as in it is not contacting your servers for whatever reason, or is not getting the correct response back. Did you verify and compare the advanced DNS settings on the Eth vs Wifi adapters? DNS Suffix set? – Ulfy Jul 11 '17 at 13:51
  • There were no advanced settings specified on that machine on those adapters (or at least, none that I could find). The machine consistently falls back to the Google DNS servers, so it's not a one-time thing. The machine can communicate with our internal DNS servers just fine (so why the fallback?). Removing Google DNS servers from the DHCP config makes the machine work as expected (albeit then there's no fallback in case our DNS goes down, obviously). – Shaamaan Jul 11 '17 at 14:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.