No DNS resolution OOB

I am unable to replicate the bug. Can you include the following?

1. WSL version used;
2. Windows version used;
3. content of /etc/wsl.conf;
4. content of /etc/resolv.conf.

Thank you very much!

Info added as requested below. Note that this is a completely fresh installation of the community preview - wsl.conf & resolv.conf were unedited.

It may be worth noting that though (as described in the issue) I get DNS resolution failures running apt update, I think it's something to do with the root account. Running any process under `sudo` seems to prevent name resolution.

eg. `curl archive.ubuntu.com` is fine
`sudo curl archive.ubuntu.com` results in `curl: (6) Could not resolve host: archive.ubuntu.com`

1. WSL version used;

2104.2021.223.0

2. Windows version used;

Microsoft Windows 10 Pro
10.0.19042 Build 19042

3. content of /etc/wsl.conf;

# 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.29.208.1

(This is the correct IP for my WSL virtual adapter. Changing it to a known nameserver, eg. 1.1.1.1, fixes the issue)

4. content of /etc/resolv.conf.

[automount]
enabled = true
mountfstab = true
root = /mnt/
options =

[network]
generatehosts = true
generateresolvconf = true

[interop]
enabled = true
appendwindowspath = true

It's also perhaps worth noting that none of this is new to the community preview. I get exactly the same thing happening with the mainline Microsoft Store release of Ubuntu 20.04.

Interesting. Do you have any third-party antivirus/VPN installed that could possibly block your network?

No - I did suspect Adguard, which intermediates http/s somehow (internal VPN I think?), but the issue still occurs with that disabled and shut down (& I've checked that the Adguard process isn't running).

Have you tried using other distros on your WSL? If they are also unable to connect, it would be a WSL issue, especially your WSL Virtual Adapter, which it will be a better idea to report at GitHub microsoft/WSL repository; If they can, this would be a Ubuntu problem, and I will investigate further. Right now I am still unable the reproduce the behavior on my three machines using Windows 10 20H2, Windows 10 Beta Channel, and Windows 10 Dev Channel.

I've just tried with Debian, sourced from the Microsoft Store. That doesn't suffer this issue - all commands hitting the network (apt, curl etc) work as expected with and without sudo. I checked to be sure resolv.conf in Debian is pointing to the WSL virtual adapter, and it is.

I don't know what might be specific to my environment, given that you can't reproduce at your end. It's a fairly unmolested Windows 10 installation. I'll be happy to provide more info if there's anything that would be helpful.

Just some more information needed:

1. contents of cat /etc/hosts;
2. Install another Ubuntu (e.g., Ubuntu 20.04 LTS), check if it works and its content:
  (1) content of /etc/wsl.conf;
  (2) content of /etc/resolv.conf;
  (3) contents of cat /etc/hosts.

1. contents of cat /etc/hosts;

# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf: # [network] # generateHosts = false 127.0.0.1 localhost 127.0.1.1 bamboo.localdomain bamboo # The following lines are desirable for IPv6 capable hosts ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters

2. My daily in-use WSL distro is Ubuntu-20.04. As I mentioned a few comments above, this experiences the same issue. My workaround has been to suppress resolv.conf autogeneration, and supply my own DNS resolver details.

  (1) content of /etc/wsl.conf;

[network]
generateResolvConf = false

  (2) content of /etc/resolv.conf;

# 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 1.1.1.1

  (3) contents of cat /etc/hosts.

# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateHosts = false
127.0.0.1 localhost
127.0.1.1 bamboo.localdomain bamboo

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Hi,

Can you install another Ubuntu distro (like Ubuntu), not showing information from your existing installed Ubuntu distro such that I can debug with the proper information? similarly, I need the following information:
  (1) content of /etc/wsl.conf;
  (2) content of /etc/resolv.conf;
  (3) contents of cat /etc/hosts.

This is with a fresh installation of the 'Ubuntu' package from the MS Store (so is 20.04).

(1) content of /etc/wsl.conf;

  (doesn't exist)

(2) content of /etc/resolv.conf;

# 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.29.192.1

(3) contents of cat /etc/hosts.

# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateHosts = false
127.0.0.1 localhost
127.0.1.1 bamboo.localdomain bamboo

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

sudo apt update [sudo] password for xxxx: 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'

I am still not sure what happened, but there is one thing you might try:

flusing DNS by:
   running `ipconfig /flushdns` in an elevated PowerShell prompt;

Also can you show the result of `ip addr`?

I eventually found where you are originally coming from at `microsoft/WSL`. I will raise this issue to Microsoft at our next meeting since I am totally unable to reproduce this but now I do see a lot of people have this issue.

Thanks. See answers below. I probably should just mention that this isn't actually causing me a problem - my main Ubuntu/WSL installation works perfectly for my daily use with an edited resolv.conf. I just happened to try the Ubuntu Community Preview out of curiosity & thought I should report the issue.

`ipconfig /flushdns` didn't make a difference.

Here's the `ip addr` output:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 66:57:3f:c0:25:ff brd ff:ff:ff:ff:ff:ff
3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 7e:0c:d7:b1:be:45 brd ff:ff:ff:ff:ff:ff
4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:34:5f:cd brd ff:ff:ff:ff:ff:ff
    inet 172.29.198.47/20 brd 172.29.207.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::215:5dff:fe34:5fcd/64 scope link
       valid_lft forever preferred_lft forever
5: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0

I accidentally reproduce this issue today (inconsistently). I don't know if it helps, but can you try `sudo systemctl disable systemd-resolved.service`? From my test, it has an extremely inconsistent behavior for me that it will be constantly in between successfully resolve and unsuccessfully resolve.

After a system restart, I cannot reproduce the bug again... I will again raise this issue to Microsoft in the next cycle.

Also can you try to sync the time by using `sudo wslact ts`? Now I suspect it's a time difference issue.

`sudo systemctl disable systemd-resolved.service`. Tried and it doesn't affect the issue.

`sudo wslact ts` - no apparent effect. (I do have time mismatches in my regular wsl/ubuntu (20.04) sometimes, which breaks `apt update`, and I have to restart the wsl vm).

Re indeterminacy - I did have this issue happen exactly once with my test Debians wsl installation. Every other time it has been fine - whereas the Ubuntu installs suffer it every time.