No DNS resolution OOB

[Cris Bennett]

With a fresh install from the Microsoft Store of the Ubuntu Community Preview (version 2104.2021.223.0) , followed by an apt update & upgrade, DNS resolution fails with the usual:

 "Err:1 http://archive.ubuntu.com/ubuntu hirsute InRelease
  Temporary failure resolving 'archive.ubuntu.com'"

(etc).

All's fine again after adding replacing the Windows WSL adapter IP with that of an external DNS server in resolv.conf.

[Patrick Wu (callmepk)]

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!

[Cris Bennett (crispinb)]

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

[Cris Bennett (crispinb)]

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.

[Patrick Wu (callmepk)]

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

[Cris Bennett (crispinb)]

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

[Patrick Wu (callmepk)]

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.

[Cris Bennett (crispinb)]

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.

[Patrick Wu (callmepk)]

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.

[Cris Bennett (crispinb)]

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

[Patrick Wu (callmepk)]

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.

[Cris Bennett (crispinb)]

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'

[Patrick Wu (callmepk)]

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.

[Cris Bennett (crispinb)]

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

[Patrick Wu (callmepk)]

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.

[Patrick Wu (callmepk)]

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

[Patrick Wu (callmepk)]

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

[Cris Bennett (crispinb)]

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