It’s always DNS. That’s the typical mantra when troubleshooting AD issues.
But what about a fully updated Windows 10/11 machine totally ignoring the DNS server it was told to use via DHCP? Yes, that unfortunately was a recent problem. On the machine it appeared to have the public Google DNS server (8.8.8.8) stuck. Regardless of what network the machine connected to, it ignored the DNS server assignment from DHCP and persisted in using Google’s DNS.
For the many cases this is probably a non issue as that DNS service is accessible. But imagine you are on an airplane trying to get to the captive portal for the WIFI and wondering why it is not working. Other examples would be portals at various coffee shops etc. In those cases the client must use the DNS server assigned by the local network as the captive portal will fail to load if a different DNS server is used.
Another annoying example is when the client tries to use a non-existent DNS server that was only relevant to one particular network or the firewall block the DNS requests making it inaccessible.
Non-Existent DNS Server
In this example the DNS server X.X.98.137 does not exist for this network. This was an education customer using a full class B network with public IPs used internally. The IP address is redacted else it would identify the customer.
Below you can see the registry location where the DNS information is persisted for a given interface.
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet\Services\Tcpip\Parameters\Interfaces\ <Interface GUID>
The <Interface GUID> is a unique ID that is assigned to each unique interface on the local machine, this is the underlined item. Below the Interface GUID you will likely see server keys which correlate to the different WIFI networks you have joined, one example is indicated via the arrow.
There are two values that are of interest under a given WIFI network ID:
-
DhcpNameServer - DNS server provided by DHCP
-
ProfileNameServer – Manually entered DNS server
These values are highlighted in the example below.
The ProfileNameServer value simple will not work for this network and since Windows only tries to use that DNS server all name resolution fails.
Airline Captive Portal Example
The same issue was observed with an airplane captive portal. The results from ipconfig /all are shown for the WIFI adapter.
Note that the Google DNS server is visible, but this is incorrect. The DNS server used *Must* be the one provided by DHCP else the captive portal name can not be resolved hence no Internet…
Note - the SSID and MAC address are redacted.
Delete Stale ProfileNameServer Value
The quickest way is to remove the ProfileNameServer registry value and this should allow the machine to then use the DHCP provided DNS server.
Some older Windows 10 builds would use NameServer instead but the same process should provide relief.
Some other folks have uninstalled and re-installed the NICs to reset the settings but that would not be my initial go-to solution.
That could be done manually via Device Manager or using the Network Reset under Settings.
Searching For Stale DNS Servers
We can quickly search for the IP address of 8.8.8.8 using reg.exe to query for locations that contain the stale DNS server.
reg.exe query HKLM\SYSTEM\CurrentControlSet\services\Tcpip /s /f "8.8.8.8"
Note that there are several WIFI network IDs as this machine has connected to many different airport, customer and enterprise networks.
The details are located under this registry path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\{8ea49799-e862-4152-86ab-19145ed11cb6}\052756D69657D6027596D2649602358656271647F6E6027457563747
Deleted All user Added Networks
As a side note, removing all joined networks did NOT clear the offending registry value. In the screenshot below you can see three networks that are system managed and I can not remove them. They are Microsoft networks and do not use Google DNS.
Note that there are still stale entries.
Cheers,
Rhoderick
