search

microsoft / WSL

Issues found on WSL
https://docs.microsoft.com/windows/wsl
MIT License
17.23k stars 808 forks source link

WSL2 DNS issues #5256

Closed OmegaRogue closed 3 months ago

OmegaRogue commented 4 years ago
vyas0189 commented 4 years ago

I am having the same issue.

AntonyLeons commented 4 years ago

editing the /etc/resolv.conf file, add nameserver 1.1.1.1 and disable auto generation of the file in /etc/wsl.conf

vyas0189 commented 4 years ago

editing the /etc/resolv.conf file, add nameserver 1.1.1.1 and disable auto generation of the file in /etc/wsl.conf

This didn't work for me.

OmegaRogue commented 4 years ago

editing the /etc/resolv.conf file, add nameserver 1.1.1.1 and disable auto generation of the file in /etc/wsl.conf

That doesn't work for me because i need to use my routers dns because i use that instead of using IPs

12101111 commented 4 years ago

I made DNS work by disabling Windows firewall

lukee1234 commented 4 years ago

I made DNS work by disabling Windows firewall

tried this too, but didn't work, that's not the problem

gerardojbaez commented 4 years ago

Yet another important issue with WSL 2 and no word from the team. I guess the best and most stable approach right now is to just use a full Linux distribution.

roonie007 commented 4 years ago

+1

milianj commented 4 years ago

+1

SamuZad commented 4 years ago

I'm having the same issue (not using a proxy, or vpn btw). After endless searching, none of the suggested workarounds (turning off firewall, manually overwriting the configuration files) found in other threads resolved the issue, so I had to revert do WSL 1..

It baffles me that an issue that impairs functionality to this degree has not been acknowledged, let alone fixed 2-3 months after "release".

scyto commented 4 years ago

editing the /etc/resolv.conf file, add nameserver 1.1.1.1 and disable auto generation of the file in /etc/wsl.conf

This didn't work for me.

Then this is not your issue, you likely have a firewall issue or some other weird networking scenario like VPN clients mucking it up.

The auto populated IP in the resolv.conf should point to the virtual host adapter IP. This doesn't seem to do DNS resolution (at least it doesn't in the current insider builds), unclear if that is a bug or intentional (it is annoying).

On a fresh WSL install you should always be able to ping say 8.8.8.8 - if you can't ping you don't have a DNS issue you have a networking issue to track down.

scyto commented 4 years ago

I'm having the same issue (not using a proxy, or vpn btw). After endless searching, none of the suggested workarounds (turning off firewall, manually overwriting the configuration files) found in other threads resolved the issue, so I had to revert do WSL 1..

It baffles me that an issue that impairs functionality to this degree has not been acknowledged, let alone fixed 2-3 months after "release".

Sounds like you have an networking issue not a DNS issue - could you ping external IPs?

SamuZad commented 4 years ago

I'm having the same issue (not using a proxy, or vpn btw). After endless searching, none of the suggested workarounds (turning off firewall, manually overwriting the configuration files) found in other threads resolved the issue, so I had to revert do WSL 1.. It baffles me that an issue that impairs functionality to this degree has not been acknowledged, let alone fixed 2-3 months after "release".

Sounds like you have an networking issue not a DNS issue - could you ping external IPs?

The behaviour as follows.

In WSL 1 I can do the following:

In WSL 2 the results are as follows:

JohnnyQuest1983 commented 4 years ago

Then this is not your issue

Incredibly unhelpful.

It is the issue for many people, it is the same in issue trackers/forums/etc across the internet.

The WSL instance cannot resolve domain names. Editing resolv.conf to point to a functioning nameserver "works" for the duration of the session, but as soon as the distro is rebooted resolv.conf is regenerated using WSL's original template. Because etc/resolv.conf is actually a symlink to run/resolvconf/resolv.conf

Steps that have worked for me:

  1. Boot your distro.
  2. cd ~/../../etc
  3. Create wsl.conf, however you see fit. sudo vim wsl.conf, sudo touch wsl.conf and edit it later, whatever.
  4. Add these lines to wsl.conf: [network] generateResolvConf=false
  5. exit or in Windows cmd wsl --terminate [YourDistroName]
  6. Boot your distro.

At this point, thanks to wsl.conf, run/resolvconf should no longer exist and will never be created again.

  1. cd ~/../../etc
  2. sudo rm resolv.conf - this deletes the existing symlink file.
  3. Create a new resolv.conf, however you see fit. sudo vim resolv.conf, sudo touch resolv.conf and edit it later, whatever.
  4. Add this line to resolv.conf: nameserver 8.8.8.8 replace 8.8.8.8 with your preferred functional nameserver.
  5. exit or in Windows cmd wsl --terminate [YourDistroName]
  6. wsl --shutdown just to be sure that you've definitely killed everything.
  7. Boot your distro.
  8. Confirm that your resolv.conf changes are still in effect, or just ping a domain name and cry tears of joy after struggling to get this working for far too fucking long.
adisaljusi commented 4 years ago

Then this is not your issue

Incredibly unhelpful.

It is the issue for many people, it is the same in issue trackers/forums/etc across the internet.

The WSL instance cannot resolve domain names. Editing resolv.conf to point to a functioning nameserver "works" for the duration of the session, but as soon as the distro is rebooted resolv.conf is regenerated using WSL's original template. Because etc/resolv.conf is actually a symlink to run/resolvconf/resolv.conf

Steps that have worked for me:

  1. Boot your distro.
  2. cd ~/../../etc
  3. Create wsl.conf, however you see fit. sudo vim wsl.conf, sudo touch wsl.conf and edit it later, whatever.
  4. Add these lines to wsl.conf: [network] generateResolvConf=false
  5. exit or in Windows cmd wsl --terminate [YourDistroName]
  6. Boot your distro.

At this point, thanks to wsl.conf, run/resolvconf should no longer exist and will never be created again.

  1. cd ~/../../etc
  2. sudo rm resolv.conf - this deletes the existing symlink file.
  3. Create a new resolv.conf, however you see fit. sudo vim resolv.conf, sudo touch resolv.conf and edit it later, whatever.
  4. Add this line to resolv.conf: nameserver 8.8.8.8 replace 8.8.8.8 with your preferred functional nameserver.
  5. exit or in Windows cmd wsl --terminate [YourDistroName]
  6. wsl --shutdown just to be sure that you've definitely killed everything.
  7. Boot your distro.
  8. Confirm that your resolv.conf changes are still in effect, or just ping a domain name and cry tears of joy after struggling to get this working for far too fucking long.

This worked for me. Thank you so much! I still don't know why nobody is tackling this issue. insane...

scyto commented 4 years ago

As I said many folks don’t have a dns issue for example you had a networking issue by your own admission (100% packet loss). As I said one need to change DNS in the immediate post if pinging works. I asked the question to help identify the issue as there was little detail in the post to actually help. So 100% accurate and 100% helpful. Moreover the resolv.conf fix is posted many many times about wsl2..

Tip for folks on GitHub learn to identify what your issue is (networking) not what you think it is (dns).

shoan commented 4 years ago

I recently upgraded to 2004 and got access to WSL2. I installed a fresh version of Ubuntu 20.04 and experienced the same DNS issue reported by several others there. I am able to ping an external ip address (8.8.8.8), but not able to resolve a domain (github.com). This problem does not occur on WSL1.

As mentioned above, the workaround with changing the nameserver in resolv.conf is the only thing that resolves the issue.

scyto commented 4 years ago

@shoan you are totally correct. It seems WSL2 is assuming there is a dns resolver listening on the hosts internal network and there isn’t one listening (or isn’t accessible?).

Makes me wonder if this is actually a hyper-v networking bug rather than a WSL2 bug, aka hyper-v NAT should have a dns resolver listening. I have tried tweaking the WSL adapter to no avail. Next up more research on how and when the hyper-v does and doesn’t do dns resolution for guest VMs.

scyto commented 4 years ago

@shoan ok I think i know what might be causing the issue - it is some interaction of Hyper-V or Hyper-V plus docker desktop. I uninstalled docker desktop, i removed WSL and hyper-v and uninstalled the distros and re-installed this way on tis weeks insider build and name resolution works perfectly. My thesis is it is related to the restrictions mentioned here where only one NAT will work reliably - i noted my system had two vmswitches both with NAT..

re-Install procedure i used after cleaning out hyper-v and wsl and docker.

Started debian, sudo ping 8.8.8.8 worked and apt-get upgrade worked perfectly

I will do more testing if i can now create a repro, without a reliable repro MS are not going to be able to troubleshoot this. Whatever the issue is it isn't WSL per-se - it is one of the other subsystems and its interaction with WSL.

This is what my WSL and Hyper-V looks like in add remove. Note Hyper-V appears as unistalled, next up seeing if checking things in the hyper-v component install breaks a working sceanrio.

image

this is what my network looks like - only one vswitch - and all is now working (i have had same issues as rest of you for months and months and months too - now i don't.... though today my PC also updated to 20180 so small chance that fixed it too!)

image

stvndall commented 4 years ago

editing the /etc/resolv.conf file, add nameserver 1.1.1.1 and disable auto generation of the file in /etc/wsl.conf

This worked perfectly for me. just not those nameservers I added nameserver router IP and both google nameservers

had to create the wsl.conf file to stop the generation of the resolv.conf

Thanks!

It's a pity I need to find a work around, But I guess it is beta 🤷‍♂️

jruckert commented 4 years ago

If you have DNS over HTTPS enabled and working on the windows machine, the Ubuntu DNS resolution will stop working. My DNS resolution dropped out as soon as I enabled this on the windows machine.

navjyotnishant commented 4 years ago

Then this is not your issue

Incredibly unhelpful. It is the issue for many people, it is the same in issue trackers/forums/etc across the internet. The WSL instance cannot resolve domain names. Editing resolv.conf to point to a functioning nameserver "works" for the duration of the session, but as soon as the distro is rebooted resolv.conf is regenerated using WSL's original template. Because etc/resolv.conf is actually a symlink to run/resolvconf/resolv.conf Steps that have worked for me:

  1. Boot your distro.
  2. cd ~/../../etc
  3. Create wsl.conf, however you see fit. sudo vim wsl.conf, sudo touch wsl.conf and edit it later, whatever.
  4. Add these lines to wsl.conf: [network] generateResolvConf=false
  5. exit or in Windows cmd wsl --terminate [YourDistroName]
  6. Boot your distro.

At this point, thanks to wsl.conf, run/resolvconf should no longer exist and will never be created again.

  1. cd ~/../../etc
  2. sudo rm resolv.conf - this deletes the existing symlink file.
  3. Create a new resolv.conf, however you see fit. sudo vim resolv.conf, sudo touch resolv.conf and edit it later, whatever.
  4. Add this line to resolv.conf: nameserver 8.8.8.8 replace 8.8.8.8 with your preferred functional nameserver.
  5. exit or in Windows cmd wsl --terminate [YourDistroName]
  6. wsl --shutdown just to be sure that you've definitely killed everything.
  7. Boot your distro.
  8. Confirm that your resolv.conf changes are still in effect, or just ping a domain name and cry tears of joy after struggling to get this working for far too fucking long.

This worked for me. Thank you so much! I still don't know why nobody is tackling this issue. insane...

This worked like a charm! thank you.

jenishngl commented 4 years ago

Then this is not your issue

Incredibly unhelpful.

It is the issue for many people, it is the same in issue trackers/forums/etc across the internet.

The WSL instance cannot resolve domain names. Editing resolv.conf to point to a functioning nameserver "works" for the duration of the session, but as soon as the distro is rebooted resolv.conf is regenerated using WSL's original template. Because etc/resolv.conf is actually a symlink to run/resolvconf/resolv.conf

Steps that have worked for me:

  1. Boot your distro.
  2. cd ~/../../etc
  3. Create wsl.conf, however you see fit. sudo vim wsl.conf, sudo touch wsl.conf and edit it later, whatever.
  4. Add these lines to wsl.conf: [network] generateResolvConf=false
  5. exit or in Windows cmd wsl --terminate [YourDistroName]
  6. Boot your distro.

At this point, thanks to wsl.conf, run/resolvconf should no longer exist and will never be created again.

  1. cd ~/../../etc
  2. sudo rm resolv.conf - this deletes the existing symlink file.
  3. Create a new resolv.conf, however you see fit. sudo vim resolv.conf, sudo touch resolv.conf and edit it later, whatever.
  4. Add this line to resolv.conf: nameserver 8.8.8.8 replace 8.8.8.8 with your preferred functional nameserver.
  5. exit or in Windows cmd wsl --terminate [YourDistroName]
  6. wsl --shutdown just to be sure that you've definitely killed everything.
  7. Boot your distro.
  8. Confirm that your resolv.conf changes are still in effect, or just ping a domain name and cry tears of joy after struggling to get this working for far too fucking long.

Tried this. But still doesn't work for me😞

jenishngl commented 4 years ago

Then this is not your issue

Incredibly unhelpful. It is the issue for many people, it is the same in issue trackers/forums/etc across the internet. The WSL instance cannot resolve domain names. Editing resolv.conf to point to a functioning nameserver "works" for the duration of the session, but as soon as the distro is rebooted resolv.conf is regenerated using WSL's original template. Because etc/resolv.conf is actually a symlink to run/resolvconf/resolv.conf Steps that have worked for me:

  1. Boot your distro.
  2. cd ~/../../etc
  3. Create wsl.conf, however you see fit. sudo vim wsl.conf, sudo touch wsl.conf and edit it later, whatever.
  4. Add these lines to wsl.conf: [network] generateResolvConf=false
  5. exit or in Windows cmd wsl --terminate [YourDistroName]
  6. Boot your distro.

At this point, thanks to wsl.conf, run/resolvconf should no longer exist and will never be created again.

  1. cd ~/../../etc
  2. sudo rm resolv.conf - this deletes the existing symlink file.
  3. Create a new resolv.conf, however you see fit. sudo vim resolv.conf, sudo touch resolv.conf and edit it later, whatever.
  4. Add this line to resolv.conf: nameserver 8.8.8.8 replace 8.8.8.8 with your preferred functional nameserver.
  5. exit or in Windows cmd wsl --terminate [YourDistroName]
  6. wsl --shutdown just to be sure that you've definitely killed everything.
  7. Boot your distro.
  8. Confirm that your resolv.conf changes are still in effect, or just ping a domain name and cry tears of joy after struggling to get this working for far too fucking long.

Tried this. But still doesn't work for me😞

I converted WSL 2 back to 1 and Internet works now in Ubuntu 20.04. I have tried all the rest of the workarounds posted but nothing works for me.

scyto commented 4 years ago

@jenishngl you are confusing symptom, root cause (issue) and fix vs workaround.

There is one symptom - DNS doesn't work.

I assure you on a fresh system WSL 2 DNS works just like it should aka there is no general purpose issue that DNS inside WSL is broken or not operating as designed.

There are multiple issues (these are just the ones I am aware of):

  1. some folks installing 3rd party firewalls - fix uninstall that firewall
  2. an issue with hyper-v networking: - workaround - follow the instructions i posted to reset the broken hyper-V networking
  3. having VPN tap clients installed - known hyper-v bug.
  4. other issues - i am sure there are others, os as si said if the fix i provided doesn't work you have a different issue (root cause - that is a stratement of fact)

The steps you posted (why on earth you posted them again when they already in the issue thread is beyond me) is not a fix, it is a workaround that doesn't fix the underlying cause, yes it may solve the symptom and that's great in short tun but not the long run.

If the firewall fix and the reset of hyper-v networking doesn't work then it is indeed an different issue and rather than reposting the workaround that has been posted several time what would be actually helpful of you is to try and root cause your issue, even better create a repro and then submit bug with right details.

I am trying to do the same on the hyper-v networking, i am stuck at a repro; this isn't about what happens inside WSL2 - it is about the is some combination of hyper-v networking configuration state that either a) is broke or b) the developers of WSL have not accounted for.

We are supposed to use these threads to provide meaningful feedback to get the issue fixed, github issues are not intended to be a general support forum.

So yes i think i am being helpful as i posted new workaround that adds context and new insight to the issue (underlying root cause) and did not repeated what has been posted multiple times. Sorry if you tried every step in my workaround that it didn't work - that means you have a different root issue.

Or if everyone thinks the fix is to mess with resolv.conf then the bug can be closed. Personally i don't.

gerardojbaez commented 4 years ago

This is happening quite FREQUENTLY, and still, NO WORDS from the WSL team. 😒

TRReeve commented 4 years ago

This just happened to me after weeks of using WSL 2 with no issue. This is a complete show-stopper in terms of using WSL 2 for any work.

sc0ttwad3 commented 4 years ago

YMMV as I'm running Win10 insider build 20201:

Check for the existence in the registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters for the "AutoEnableDOH" DWORD (32-bit) Value. If it is present and set to 2, system-wide DNS over HTTPS is enabled—which I've yet to see working with WSL 2— and changing that value back to 0 turns off system-wide DoH, and in my case restored working DNS to WSL 2. A setting of 1 sets DoH with normal unencrypted DNS as a fallback, 2 is DoH encrypted-only.

Even though my system and network adapters showed no configuration changes from the normal/regular port 53 DNS servers—meaning none of the individual adapaters had DNS settings manually set for DoH— this AutoEnableDoH value showed up in the registry, for me, after build 20201. In the past, I'm not sure how many builds back, you had to manually add this to the registry (never done on this system, but which I've done on other machines for system-wide DoH, as those other systems did not have WSL enabled.)

BTW: Has anyone gotten DoH to work in the Win10 host and within WSL 2? Anyone successfully build the latest WSL2-Linux-Kernel with a custom configuration? Better yet, anyone build a working 5.x kernel from the linux-msft-wsl-5.4.y branch?

mainegra commented 4 years ago

This issue started happening to me after a Windows Insider update to 20201. After trying the workarounds suggested here, and failing, I found out that the Ethernet adapter vEthernet (WSL) was disabled by issuing ipconfig /all on a cmd shell. A google search on Ethernet adapter vEthernet (WSL) got me to this link pointing out to the need to turn on the Hyper-V feature on the Turn Windows features on or off which was off in my machine. After that wsl2 is behaving properly again. Just need to find out if it stays that way (just fixed it).

dchaffin commented 4 years ago

I'm not sure how/if this helps, but after reading @scyto 's comment above, I looked at my Network Connections. I had two on Hyper-V.

image

I disabled the one that did not say WSL and rebooted my PC and then everything worked again (I'd had nao trouble like this until today). However, I went to take this screenshot and that connection had been re-enabled. So, I'm not sure exactly what happened, but it's working for now so I thought I'd commend in case this worked for anyone else.

scyto commented 4 years ago

@dchaffin glad it worked for you, that's exactly what i saw. the issue IMHO isn't a bug with WSL - it is a bug with hyper-v networking where it gets into an odd state (potentially different states with different root causes), it seems this can occur for normal non-wsl VMs too from some of the bugs filed over in hyper-v land. Of course WSL product folks need to be aware of this and help push fix into hyper-v.

reducio commented 4 years ago

I rebooted my computer and wsl network just work nice :)

TRReeve commented 4 years ago

I resolved in the end by removing all Distros and WSL 2 and reinstalling from scratch.

penance316 commented 4 years ago

This issue started happening to me after a Windows Insider update to 20201. After trying the workarounds suggested here, and failing, I found out that the Ethernet adapter vEthernet (WSL) was disabled by issuing ipconfig /all on a cmd shell. A google search on Ethernet adapter vEthernet (WSL) got me to this link pointing out to the need to turn on the Hyper-V feature on the Turn Windows features on or off which was off in my machine. After that wsl2 is behaving properly again. Just need to find out if it stays that way (just fixed it).

This solved my issue. I just enabled the Hyper-v features in the "turn windows features on or off" menu, then rebooted my PC and now local and external DNS is working correctly again.

I'm not too familiar with the connection between Hyper-v and WSL2 but now its installed my WSL is working as it was previously.

mainegra commented 4 years ago

This issue started happening to me after a Windows Insider update to 20201. After trying the workarounds suggested here, and failing, I found out that the Ethernet adapter vEthernet (WSL) was disabled by issuing ipconfig /all on a cmd shell. A google search on Ethernet adapter vEthernet (WSL) got me to this link pointing out to the need to turn on the Hyper-V feature on the Turn Windows features on or off which was off in my machine. After that wsl2 is behaving properly again. Just need to find out if it stays that way (just fixed it).

This solved my issue. I just enabled the Hyper-v features in the "turn windows features on or off" menu, then rebooted my PC and now local and external DNS is working correctly again.

I'm not too familiar with the connection between Hyper-v and WSL2 but now its installed my WSL is working as it was previously.

Sadly it solves the problem only temporarily! And it probably solves it because of the reboot! The same problem is being reported in separate issues at https://github.com/microsoft/WSL/issues/5821 https://github.com/microsoft/WSL/issues/5805 where peeps are getting the service restarted by restarting the Hyper-V Virtual network adapters, the LxssManager service and the Host Network Service. I've tried that, and it works temporarily, and not always. So, there is something serious going on with the Hyper-V stuff. Although I agree that it seems to be an issue outside of wsl2, it affects it directly. Which does not happen in wsl. I am thinking of reverting back to the legacy wsl since I am wasting a lot of time "fixing" this issue!

metawrap-dev commented 4 years ago

I had an issue with DNS lagging or not resolving.

I solved this by adding 

[network]
generateResolvConf=true

to my /etc/wsl.conf

And then restarting.

Seems to be working for now. Mind you, this issue seems to be intermittent and a change and a restart appears to fix it for some people, at least for a while. My above effort may just be futile and the restart provides a temporary solution.

Rizary commented 4 years ago

anyone having trouble with xserver? I'm using X410, and when I boot my qemu kvm image, suddenly the connection is disconnected. But when reboot my windows machine, the connection up again until I run my qemu kvm image

danvy commented 4 years ago

Could you please test this https://gist.github.com/danvy/9486bf730371436131cb888ff4c2ceb6 ?

Rizary commented 4 years ago

@danvy thank you! it works!

simon-letch commented 3 years ago

Disconnecting from my corporate vpn client solved the problem for me.

nour-s commented 3 years ago

Now I'm super frustrated! I'm in the same situation and I found a lot of people having the same issue with no simple answer! In my case, disabling the firewall fixed the issue but of course I can't keep it disabled. Adding a rule for wsl.exe and wslhost.exe didn't fix the issue.

Editing /etc/resove.conf and changing the name server to whatever DNS you want (google, or even your router) fixed the issue temporarily and it comes back after restart (Uncommenting the #generateResolveConf=false didn't stop resetting the file).

It was a while before I found a comment to add this rule to the firewall that magically fixed the issue:

New-NetFirewallRule -DisplayName "WSL" -Direction Inbound -InterfaceAlias "vEthernet (WSL)" -Action Allow

Original comment: https://github.com/microsoft/WSL/issues/4585#issuecomment-610061194

PS: I use Wireguard VPN but it is off all the time.

ArthurYdalgo commented 3 years ago

So, I came here with the same problem, and right after I figured out what was the problem. I've just reset my Windows 10, and Norton automatically installs every time, and Smart Firewall blocks it (WSL 2) from accessing anything. I use AVG so Norton was going away either way. Maybe it's not the same reason, but maybe it is. Have a good one!!

nour-s commented 3 years ago

@ArthurYdalgo I use Windows Defender, and I'm assuming they already whitelist WSL 2 once you install it!

scyto commented 3 years ago

people are experiencing same symptoms, different causes on this thread.

  1. firewall issues
  2. networking configuration corrupted
  3. others.

for example for me nothing I do to the firewall ever fixed this, including totally disabling all firewall functions. just FYI so folks are careful about asserting there is any one specific fix or workaround - just set of things to try - nice work folks on creating all these workarounds to cover all the scenarios

Tuatarian commented 3 years ago

Then this is not your issue

Incredibly unhelpful.

It is the issue for many people, it is the same in issue trackers/forums/etc across the internet.

The WSL instance cannot resolve domain names. Editing resolv.conf to point to a functioning nameserver "works" for the duration of the session, but as soon as the distro is rebooted resolv.conf is regenerated using WSL's original template. Because etc/resolv.conf is actually a symlink to run/resolvconf/resolv.conf

Steps that have worked for me:

  1. Boot your distro.
  2. cd ~/../../etc
  3. Create wsl.conf, however you see fit. sudo vim wsl.conf, sudo touch wsl.conf and edit it later, whatever.
  4. Add these lines to wsl.conf: [network] generateResolvConf=false
  5. exit or in Windows cmd wsl --terminate [YourDistroName]
  6. Boot your distro.

At this point, thanks to wsl.conf, run/resolvconf should no longer exist and will never be created again.

  1. cd ~/../../etc
  2. sudo rm resolv.conf - this deletes the existing symlink file.
  3. Create a new resolv.conf, however you see fit. sudo vim resolv.conf, sudo touch resolv.conf and edit it later, whatever.
  4. Add this line to resolv.conf: nameserver 8.8.8.8 replace 8.8.8.8 with your preferred functional nameserver.
  5. exit or in Windows cmd wsl --terminate [YourDistroName]
  6. wsl --shutdown just to be sure that you've definitely killed everything.
  7. Boot your distro.
  8. Confirm that your resolv.conf changes are still in effect, or just ping a domain name and cry tears of joy after struggling to get this working for far too fucking long.

This solved my problem after several days of trying. I was able to ping google.com and it returned, but got weird errors when trying to sudo apt update

scyto commented 3 years ago

@Tuatarian try pinging the repo names you saw fail, if it can resolve the names to the correct IP then DNS is working and you likely have some other issue. What was the strange error you saw?

Tuatarian commented 3 years ago

@Tuatarian try pinging the repo names you saw fail, if it can resolve the names to the correct IP then DNS is working and you likely have some other issue. What was the strange error you saw?

For clarity, I was able to ping google.com before doing the steps laid out. The issues were given during sudo apt update, which those steps fixed :)

CatchABus commented 3 years ago

Then this is not your issue

Incredibly unhelpful.

It is the issue for many people, it is the same in issue trackers/forums/etc across the internet.

The WSL instance cannot resolve domain names. Editing resolv.conf to point to a functioning nameserver "works" for the duration of the session, but as soon as the distro is rebooted resolv.conf is regenerated using WSL's original template. Because etc/resolv.conf is actually a symlink to run/resolvconf/resolv.conf

Steps that have worked for me:

  1. Boot your distro.
  2. cd ~/../../etc
  3. Create wsl.conf, however you see fit. sudo vim wsl.conf, sudo touch wsl.conf and edit it later, whatever.
  4. Add these lines to wsl.conf: [network] generateResolvConf=false
  5. exit or in Windows cmd wsl --terminate [YourDistroName]
  6. Boot your distro.

At this point, thanks to wsl.conf, run/resolvconf should no longer exist and will never be created again.

  1. cd ~/../../etc
  2. sudo rm resolv.conf - this deletes the existing symlink file.
  3. Create a new resolv.conf, however you see fit. sudo vim resolv.conf, sudo touch resolv.conf and edit it later, whatever.
  4. Add this line to resolv.conf: nameserver 8.8.8.8 replace 8.8.8.8 with your preferred functional nameserver.
  5. exit or in Windows cmd wsl --terminate [YourDistroName]
  6. wsl --shutdown just to be sure that you've definitely killed everything.
  7. Boot your distro.
  8. Confirm that your resolv.conf changes are still in effect, or just ping a domain name and cry tears of joy after struggling to get this working for far too fucking long.

These steps made resolution work for me, but I have a new issue now. Everytime I try a 'git clone' or git commands that have access to remote, terminal will hang and throw an error response. Here is response message:

error: RPC failed; curl 52 Empty reply from server
fatal: the remote end hung up unexpectedly

I have no issues when cloning or executing any remote commands from Windows. This is frustrating.

cpoptic commented 3 years ago

Apparently an update in the last few weeks fixed this DNS resolving error. I had to turn on the option to >Receive updates for other Microsoft products when you update Windows

wsl --status

Kernel version: 4.19.104

After enable the Windows Update setting: 'Receive updates for other Microsoft products when you update Windows'.

wsl --status

Kernel version: 4.19.128

Re-start WSL. Now ping google.com works fine

EDIT When closing WSL shell and reopening, the error persists. Even following the above instructions to remove and edit resolv.conf file did not fix it. Only a hard reboot of the host machine fixed this.

CatchABus commented 3 years ago

Apparently an update in the last few weeks fixed this DNS resolving error. I had to turn on the option to >Receive updates for other Microsoft products when you update Windows

wsl --status

Kernel version: 4.19.104

After enable the Windows Update setting: 'Receive updates for other Microsoft products when you update Windows'.

wsl --status

Kernel version: 4.19.128

Re-start WSL. Now ping google.com works fine

How is wsl --status supposed to work? I checked and there is no such parameter.