No name resolution in WSL2 even with custom resolv.conf

[peperami97]

Environment

Windows build number: Microsoft Windows [Version 10.0.18363.1139]
Your Distribution version: Ubuntu 20.04
Whether the issue is on WSL 2 and/or WSL 1: Linux version 4.19.128-microsoft-standard (oe-user@oe-host) (gcc version 8.2.0 (GCC)) #1 SMP Tue Jun 23 12:58:10 UTC 2020 -- It should be WSL 2

Steps to reproduce

Upon starting the Ubuntu instance, it has no DNS resolution. When attempting any action by name it fails.

ping www.google.com
ping: www.google.com: Temporary failure in name resolution

$ nslookup
> server
Default server: 192.168.1.1
Address: 192.168.1.1#53
Default server: 192.168.1.3
Address: 192.168.1.3#53
Default server: 1.1.1.1
Address: 1.1.1.1#53
> google
;; connection timed out; no servers could be reached

> google.co.uk
;; connection timed out; no servers could be reached

However ping 1.1.1.1 returns successfully, as does ping 213.136.79.113 (a vps of mine)

I can also ping the 192.168.1.x network locally to my machine.

I am on my work machine which is connected to the work network using a juniper pulse vpn, disconnecting the vpn makes no difference.

run on wsl
 ip addr
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 6a:9e:cf:7d:19:f6 brd ff:ff:ff:ff:ff:ff
3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether d2:38:34:cc:46:89 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:cb:41:66 brd ff:ff:ff:ff:ff:ff
    inet 192.168.85.235/28 brd 192.168.85.239 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::215:5dff:fecb:4166/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

ipconfig

Windows IP Configuration


Ethernet adapter Ethernet 4:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Ethernet adapter vEthernet (WSL):

   Connection-specific DNS Suffix  . :
   IPv4 Address. . . . . . . . . . . : 192.168.85.225
   Subnet Mask . . . . . . . . . . . : 255.255.255.240
   Default Gateway . . . . . . . . . :

Ethernet adapter Ethernet 3:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : local.lan
   IPv4 Address. . . . . . . . . . . : 192.168.1.129
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.1.1

Wireless LAN adapter WiFi:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . : local.lan

Ethernet adapter Bluetooth Network Connection:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

My resolv.conf has the 3 nameservers mentioned in the nslookup and I have an /etc/wsl file preventing the resolv.conf being replaced.

If I downgrade the ubuntu to wsl 1 it works fine and I have connectivity with DNS resolution.

I have docker for windows installed

WSL logs:

I have submitted the feedback but I am suspicious that they will be blank, as I think the feature is blocked by group policy.

Expected behavior

I would expect name resolution to work and for me to be able to access network resources on the internet and local network by name

Actual behavior

I can not perform dns resolution and so am unable to access resources by name.

[lukee1234]

Maybe you should look at #5437

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!