DNS lookup broken if original DNS server goes down but has already been changed in Windows

[hparadiz]

Experienced this with build 14905.

My router's DNS started to stop responding to dns lookups so instead of restarting it I set my DNS server from 192.168.1.1 to OpenDNS 208.67.222.222, 208.67.220.220 in Windows.

Ubuntu for Windows seemed to still be using the old DNS as all lookups would fail. It wasn't until I disabled and then re-enabled the Ethernet adapter in Windows that I was able to have DNS lookups working again in the shell.

[rodrymbo]

The workaround is to note that /etc/resolv.conf is generated from Windows settings when Bash is started from scratch. So, theoretically, if the Windows DNS changes while a Bash.exe is running, the value of /etc/resolv.conf will not change to reflect the new Windows settings until later, according to the Devs. So, to test, make sure all bash.exe processes are stopped and then start them up again, and check to make sure that /etc/resolv.conf reflects new settings on the Windows side (e.g. by comparing to ipconfig /all in Windows). (It might be good to test to see if it also updates when you just restart networking on Windows, but that's less critical.)

The other workaround is to leave your router listed as the first DNS resolver, then put the OpenDNS resolvers in as second and third (using DHCP setup on the router or perhaps Windows network setup). /etc/resolv.conf should then also end up with the same three resolvers the next time it is auto-generated. Then if the router's DNS stops working, both Windows and WSL will switch to one of the alternatives, without having to restart or edit anything. (This is a good strategy any time one sets up a network, assuming fallback resolvers that are secure and work properly.)

Or you could edit /etc/resolv.conf by hand to get things going in WSL without restarting anything, understanding that the file will be auto-generated again when everything restarts.

In no sense do the workarounds mitigate the core problem, which is that DNS resolver is about the only core networking functionality of WSL (routing, firewall, adapter configuration, etc) that isn't handled by the Windows side in real time.

[sunilmut]

Apologize the delay in response here. It is true that /etc/resolv.conf is generated by bash during first launch. Also, the original intended design is to keep the /etc/resolv.conf up to date with any changes that happen on the Windows side. This happens by the LXSS Manager, which registers for WNF notifications for any network changes including IP address & DNS updates. For DNS updates, it should then in turn update the /etc/resolv.conf. But, the update does not seem to be happening (probably because the notification is not coming in) and that is just a bug. I have opened a bug on our end to track this and hopefully we should have a fix for this soon. Apologize for the poor experience and please keep the feedback coming!

[wizll]

I have a similar issue to this with regard to VPNs whereas based on the order of the DNS servers in /etc/resolv.conf anything after the first one doesn't fully work. So for example, I have my normal internet network, and I'm connected to my work VPN via split tunnel. Therefore, all my internet traffic still goes through my network and any VPN traffic will go through that, and of course the VPN traffic would have its own DNS server. This all works fine in Windows itself, but inside the Ubuntu Bash, things are not as happy. the /etc/resolv.conf lists my local dns server for internet, and the couple DNS servers from my VPN. the local dns is first and the others follow it. When I do a 'nslookup or dig' on a VPN only hostname say, vmatwork.myworkvpn.com, it will properly cycle through all the DNS servers and provide the result. However, if I do a 'ping', 'ssh' or anything else using that same hostname, the DNS resolution fails. It basically only tries the first DNS server, and bails out. If I modify and move the VPN's DNS servers to be first in /etc/resolv.conf, it will now allow me to use 'ping', 'ssh', etc against the VPN hostname. However, when doing that, my internet DNS now fails because now it's not first. While this workaround lets me utilize my VPN's internal hostnames, it results in all external (internet) hostnames to fail DNS resolution.

As mentioned, this is not a problem anywhere else in Windows 10. If I use cygwin, both networks work as expected. It's only using Bash for Windows that this is a problem.

[sunilmut]

@wizll - The VPN issue is a known one and is already being tracked by other GitHub posts such as #1350, #963. Please track it using those posts.

The general issue of /etc/resolv.conf should already been fixed in Insider builds.