Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WSL2 DNS issues #5256

Closed
OmegaRogue opened this issue May 23, 2020 · 218 comments
Closed

WSL2 DNS issues #5256

OmegaRogue opened this issue May 23, 2020 · 218 comments
Labels

Comments

@OmegaRogue
Copy link

  • Your Windows build number:
    Microsoft Windows [Version 10.0.19041.264] (desktop)
    Microsoft Windows [Version 10.0.19041.264] (laptop)

  • What you're doing and what's happening:
    on wsl2 on my desktop PC, name resolution seems to always fail (i've had it working in the past)
    on my laptop, wsl2 name resolution works fine
    on my desktop:

    • sudo apt-get update
      Err:1 http://archive.ubuntu.com/ubuntu focal InRelease
        Temporary failure resolving 'archive.ubuntu.com'
      Err:2 http://security.ubuntu.com/ubuntu focal-security InRelease
        Temporary failure resolving 'security.ubuntu.com'
      Err:3 http://archive.ubuntu.com/ubuntu focal-updates InRelease
        Temporary failure resolving 'archive.ubuntu.com'
      Err:4 http://archive.ubuntu.com/ubuntu focal-backports InRelease
        Temporary failure resolving 'archive.ubuntu.com'
      Reading package lists... Done
      W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/focal/InRelease  Temporary failure   resolving 'archive.ubuntu.com'
      W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/focal-updates/InRelease  Temporary   failure resolving 'archive.ubuntu.com'
      W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/focal-backports/InRelease    Temporary failure resolving 'archive.ubuntu.com'
      W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/focal-security/InRelease    Temporary failure resolving 'security.ubuntu.com'
      W: Some index files failed to download. They have been ignored, or old ones used instead.
      
    • ping -c 4 google.com
      ping: google.com: Temporary failure in name resolution
      
    • ping -c 4 172.217.23.174 (the ip i get from ping google.com in cmd)
      PING 172.217.23.174 (172.217.23.174) 56(84) bytes of data.
      64 bytes from 172.217.23.174: icmp_seq=1 ttl=54 time=10.9 ms
      64 bytes from 172.217.23.174: icmp_seq=2 ttl=54 time=9.72 ms
      64 bytes from 172.217.23.174: icmp_seq=3 ttl=54 time=8.60 ms
      64 bytes from 172.217.23.174: icmp_seq=4 ttl=54 time=7.85 ms
      
      --- 172.217.23.174 ping statistics ---
      4 packets transmitted, 4 received, 0% packet loss, time 3006ms
      rtt min/avg/max/mdev = 7.850/9.260/10.865/1.141 ms
      
  • What's wrong / what should be happening instead:
    on my laptop:

    • sudo apt-get update
      Hit:1 http://archive.ubuntu.com/ubuntu bionic InRelease
      Get:2 http://archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB]
      Get:3 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
      Hit:4 http://download.mono-project.com/repo/debian wheezy InRelease
      Get:5 http://archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB]
      Hit:6 https://dl.yarnpkg.com/debian stable InRelease
      Hit:7 https://download.jitsi.org stable/ InRelease
      Get:8 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages [948 kB]
      Get:9 http://archive.ubuntu.com/ubuntu bionic-updates/main Translation-en [322 kB]
      Get:10 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages [724 kB]
      Get:11 http://archive.ubuntu.com/ubuntu bionic-updates/restricted amd64 Packages [55.3 kB]
      Get:12 http://archive.ubuntu.com/ubuntu bionic-updates/restricted Translation-en [13.8 kB]
      Get:13 http://archive.ubuntu.com/ubuntu bionic-updates/universe amd64 Packages [1075 kB]
      Get:14 http://archive.ubuntu.com/ubuntu bionic-updates/universe Translation-en [334 kB]
      Get:15 http://security.ubuntu.com/ubuntu bionic-security/main Translation-en [229 kB]
      Get:16 http://security.ubuntu.com/ubuntu bionic-security/restricted amd64 Packages [45.7 kB]
      Get:17 http://security.ubuntu.com/ubuntu bionic-security/restricted Translation-en [11.4 kB]
      Get:18 http://security.ubuntu.com/ubuntu bionic-security/universe amd64 Packages [666 kB]
      Get:19 http://security.ubuntu.com/ubuntu bionic-security/universe Translation-en [221 kB]
      Get:20 http://security.ubuntu.com/ubuntu bionic-security/multiverse amd64 Packages [7596 B]
      Get:21 http://security.ubuntu.com/ubuntu bionic-security/multiverse Translation-en [2824 B]
      Fetched 4909 kB in 4s (1389 kB/s)
      Reading package lists... Done
      
    • ping -c 4 google.com
      PING google.com (172.217.23.174) 56(84) bytes of data.
      64 bytes from fra15s22-in-f14.1e100.net (172.217.23.174): icmp_seq=1 ttl=54 time=10.1 ms
      64 bytes from fra15s22-in-f14.1e100.net (172.217.23.174): icmp_seq=2 ttl=54 time=9.69 ms
      64 bytes from fra15s22-in-f14.1e100.net (172.217.23.174): icmp_seq=3 ttl=54 time=11.4 ms
      64 bytes from fra15s22-in-f14.1e100.net (172.217.23.174): icmp_seq=4 ttl=54 time=8.50 ms
      
      --- google.com ping statistics ---
      4 packets transmitted, 4 received, 0% packet loss, time 3004ms
      rtt min/avg/max/mdev = 8.501/9.952/11.462/1.059 ms
      
    • ping -c 4 172.217.23.174 (the ip i get from ping google.com in cmd)
      PING 172.217.23.174 (172.217.23.174) 56(84) bytes of data.
      64 bytes from 172.217.23.174: icmp_seq=1 ttl=54 time=10.6 ms
      64 bytes from 172.217.23.174: icmp_seq=2 ttl=54 time=8.54 ms
      64 bytes from 172.217.23.174: icmp_seq=3 ttl=54 time=9.20 ms
      64 bytes from 172.217.23.174: icmp_seq=4 ttl=54 time=8.16 ms
      
      --- 172.217.23.174 ping statistics ---
      4 packets transmitted, 4 received, 0% packet loss, time 3005ms
      rtt min/avg/max/mdev = 8.163/9.133/10.620/0.935 ms
      
@vyas0189
Copy link

I am having the same issue.

@AntonyLeons
Copy link

AntonyLeons commented May 30, 2020

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

@vyas0189
Copy link

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
Copy link
Author

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
Copy link

I made DNS work by disabling Windows firewall

This was referenced Jul 9, 2020
@lukee1234
Copy link

I made DNS work by disabling Windows firewall

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

@gerardojbaez
Copy link

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
Copy link

+1

1 similar comment
@milianj
Copy link

milianj commented Jul 29, 2020

+1

@SamuZad
Copy link

SamuZad commented Jul 29, 2020

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
Copy link

scyto commented Jul 29, 2020

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
Copy link

scyto commented Jul 29, 2020

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
Copy link

SamuZad commented Jul 29, 2020

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:

  • I can ping google.com (and get 216.58.214.206 back)
  • I can ping the IP of google.com (so 216.58.214.206)
  • I can curl google.com

In WSL 2 the results are as follows:

  • I cannot ping google.com (ping: google.com: Temporary failure in name resolution)
  • If I try to ping the IP directly I get something like: 4 packets transmitted, 0 received, 100% packet loss, time 3085ms
  • I cannot curl google.com

@JohnnyQuest1983
Copy link

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
Copy link

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
Copy link

scyto commented Aug 2, 2020

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
Copy link

shoan commented Aug 2, 2020

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
Copy link

scyto commented Aug 2, 2020

@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
Copy link

scyto commented Aug 3, 2020

@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.

  • uninstall all distros
  • disable all of hyper-v component
  • disable WSL component
  • uninstall all TAP based networking by uninstalling two VPN clients i have installed (there are multiple issues logged with DNS issues in hyper-v NAT caused by installing VPNs that create TAP adapters)
  • rebooted
  • dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
  • dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
  • reboot
  • install debian from store
  • run kernel update from here

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
Copy link

stvndall commented Aug 3, 2020

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
Copy link

jruckert commented Aug 5, 2020

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
Copy link

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
Copy link

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
Copy link

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
Copy link

scyto commented Aug 17, 2020

@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
Copy link

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

@Elektronenvolt
Copy link

@iamWing If it's about DNS this should do the trick: #5336 (comment)

@iamWing
Copy link

iamWing commented Nov 2, 2022

@iamWing If it's about DNS this should do the trick: #5336 (comment)

@Elektronenvolt Thanks mate. Unfortunately it doesn't work either. Might be because the firewall is controlled by McAfee rather then Windows. I have no right to change anything in McAfee tho so I've gave up using WSL2 on my work laptop for now.

@qasan85
Copy link

qasan85 commented Dec 2, 2022

1\ editing the sudo nano /etc/resolv.conf
nameserver 8.8.8.8, save the file
2\ editing the sudo nano /etc/systemd/resolved.conf
Uncomment the DNS and FallbackDNS lines by removing the # sign
Now add your preferred DNS servers. The FallbackDNS line is optional anyway
DNS=8.8.8.8
FallbackDNS=8.8.4.4
3\Save the file and exit. Also, you may want to clear any cached queries. Use the command
sudo systemctl start systemd-resolved.service
sudo systemctl is-active systemd-resolved
fix issues resolving internet on ubuntu 20 04 for WSL
that works for me

@snylonue
Copy link

According to the logs of my local dns server, it received the dns query from dig and successfully sent a response, but dig failed to receive the response.

@TLA020
Copy link

TLA020 commented Mar 18, 2023

same issues tried everything.

ERROR: Service 'app' failed to build: Get "https://registry-1.docker.io/v2/": dial tcp: lookup registry-1.docker.io on [::1]:53: read udp [::1]:54660->[::1]:53: read: connection refused

@LuisPeluso
Copy link

LuisPeluso commented Jul 8, 2023

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.

give this man a medal! Thanks!

@MatthewSkingley
Copy link

The past two days I've been having issues with connections to my company's LAN and VPN setup. I use docker on WSL2, and the issue seems to stem from a situation where docker's bridge networks could overlap with the hyper-v switch that provides networking to WSL. This knocks out networking via the VPN. I'm not an expert on IP nor DNS, but I would stress the need to check your company's VPN, your WSL2 vEthernet adapter and docker's bridge interfaces are not colliding on the 172.22.xxx.xxx ranges. It does not seem like my current workaround config is possible with generateResolvConf=true, so I'm using a custom resolv.conf (immutable with chattr) as many others are.

@KonanTheLibrarian
Copy link

DNS NETWORK on WSL2 STILL JUST BREAKS: CLOSING THOUSANDS OF BUG REPORTS ON THIS 10 YEAR OLD BUG (WHICH IS NOT FIXED) IS WEIRD!

I have implemented that hard coded DNS solution (above) and protected /etc/resolv.conf with chattr etc done swap=0 and all sorts and it is a lot better, but WSL2 still looses it's DNS even if you disconnect briefly and reconnect your IPsec VPN. Once that happens still have to reboot. (I am running WSL2 on top end Dell laptop with up-to-date bios and Windows 10.)

When running ordinary applications under Windows or on a Linux PC, any disconnection of the network and reconnection allows all applications to reconnect to the network no problem; not so with WSL2 it's still got a fragile DNS! When running WSL, DNS resolution is lost even with a brief disconnection or the lease time on the network driver laps and reconnects (which is normal), after that you can’t connect or even ping devices unless you reboot! This is specifically and a WSL Linux bug coded brilliantly by Windows network programmers and they have closed THOUSANDS of the same reports, that is WEIRD!

Even with millions of complaints, and thousands of bug reports, this bug has been persistent for almost a decade and NOT FEXED IN JULY 2023! This is so serious many developers avoid all Docker development under WSL and Windows.
When Windows programmers write Linux network code, what could possibly go wrong?

WSL team members even close bug reports rather than combine the data from thousands of similar reports. When reports are closed so that others can’t comment the geniuses have magically fixed the major bug right? NOT! The use of Docker Desktop makes it 100 times worse, but fortunately Docker Desktop is NOT Docker and many people run WSL2 without Docker Desktop.

@Elektronenvolt
Copy link

@KonanTheLibrarian - We had that WSL DNS issue on multiple machines and didn't find a root cause for a long time. Finally figured out that for an unknown reason incoming DNS was blocked on the public network profile on some machines.

See:
#5336 (comment)

We fixed it by setting an inbound firewall rule for the WSL network adapter with Powershell:
New-NetFirewallRule -DisplayName "WSL allow in" -Direction Inbound -InterfaceAlias "vEthernet (WSL)" -Action Allow

Needs to be done again after reboots, but it's a fast workaround. Was not a WSL issue in our case.

@craigloewen-msft
Copy link
Member

Hi folks, we have put out a new update that aims to address networking issues in WSL. In your .wslconfig file you can set experimental.networkingMode=mirrored, as well as some other key settings that should improve your network compatibility! Please try them out and let us know what you think.

More info on this release and the changes can be found here in the blog post.

Please note: You need to be on a Windows Insiders version to use the new networking settings (Any channel of Windows Insiders will do, including release preview). If you see the "These are not supported" messages it means that your current Windows version doesn't have support, and you will need to upgrade. These features will eventually be coming to Windows 11 22H2.

@mirabilos
Copy link

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.

Or WSL 1, which does networking right.

@CatalinFetoiu
Copy link
Collaborator

Hi. Can you try enabling the new experimental "dnsTunneling" feature and let us know if the issue still reproduces?

You can find more details at https://devblogs.microsoft.com/commandline/windows-subsystem-for-linux-september-2023-update/

Thanks!

@mrslezak
Copy link

mrslezak commented Sep 27, 2023 via email

@craigloewen-msft
Copy link
Member

These new networking features are now available on the latest version of Win11 22H2!

Please make sure you're on the latest build to get these features, you can do that by clicking "Check for Updates" in Windows settings. You can check you have the right build by either ensuring you have KB5031354 installed, or run cmd.exe /c ver and ensure that your build number is 22621.2428 or higher (Including the minor build number which is after the . as this was a backport!)

@josemi-ca
Copy link

These new networking features are now available on the latest version of Win11 22H2!

Please make sure you're on the latest build to get these features, you can do that by clicking "Check for Updates" in Windows settings. You can check you have the right build by either ensuring you have KB5031354 installed, or run cmd.exe /c ver and ensure that your build number is 22621.2428 or higher (Including the minor build number which is after the . as this was a backport!)

@craigloewen-msft I have the latest Win11 23H2 stable (10.0.22631.2428) and I get error Key experimental.networkingMode unknown and same with DNS tunneling.

@havran
Copy link

havran commented Nov 1, 2023

These new networking features are now available on the latest version of Win11 22H2!
Please make sure you're on the latest build to get these features, you can do that by clicking "Check for Updates" in Windows settings. You can check you have the right build by either ensuring you have KB5031354 installed, or run cmd.exe /c ver and ensure that your build number is 22621.2428 or higher (Including the minor build number which is after the . as this was a backport!)

@craigloewen-msft I have the latest Win11 23H2 stable (10.0.22631.2428) and I get error Key experimental.networkingMode unknown and same with DNS tunneling.

I download lates prerelease 2.0.7 from here https://github.com/microsoft/WSL/releases, install it and it's works for me.

@keith-horton
Copy link
Member

Sorry for the DNS issues. We have updated our troubleshooting with some configuration conflicts that can break DNS name resolution from the WSL container, as well as a work-around for an OS bug. Please see https://github.com/MicrosoftDocs/WSL/blob/main/WSL/troubleshooting.md#troubleshooting-dns-in-wsl

Thanks.

@AustEcon
Copy link

AustEcon commented Nov 27, 2023

In my case I was unable to ping anything. Not google.com, not github.com and that was causing git clone to timeout.

This was the default generated /etc/resolv.conf file:

# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateResolvConf = false
nameserver 172.27.176.1

So I tried 8.8.8.8 - still no fix. Because in my case it was a networking issue not DNS.

My working theory about what happened is that my laptop while in sleep mode got pinned on my home router.

My laptop was at my place in sleep mode (connected to my home router). Then I took my laptop to a different place while it was still in sleep mode. And I suddenly could not connect to anything at all in wsl2.
The ONLY thing that was able to fix it was a simple full restart of windows. The /etc/resolv.conf file was kept as above.

Everything is working fine now after the restart.

Hope this helps someone - these kinds of things that should "just work" can be maddening to deal with...

@yousmii
Copy link

yousmii commented Dec 12, 2023

What caused the issue for me was another firewall (Portmaster) blocking traffic. I just turned it off and it immediately started working again. I recommend all to check their firewalls (pc-side, router-side, etc.) I hope it helps!

@ccbond
Copy link

ccbond commented Jan 11, 2024

https://github.com/vxiaov/vClash?tab=readme-ov-file

It works for me. [dog]

@qhaas
Copy link

qhaas commented Mar 23, 2024

Looks like dns tunneling is now enabled by default, hopefully that will help with some of the (likely) multiple causes of these DNS issues.

@hyp530
Copy link

hyp530 commented Apr 6, 2024

I just installed WSL2 pre-released, and this is still a issue!!

@ghost
Copy link

ghost commented May 28, 2024

https://learn.microsoft.com/en-us/windows/wsl/networking#dns-tunneling

This should fixed by enabling dns tunnelling, which now no longer experimental.

@ghost ghost closed this as completed May 28, 2024
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests