WSL2 DNS resolver forwards additional records as regular answers

[TimoRoth]

Version

Microsoft Windows [Version 10.0.22000.258], using WSL2 Preview from Store: 0.48.2.0

WSL Version

• WSL 2
• WSL 1

Kernel Version

5.10.60.1-microsoft-standard-WSL2

Distro Version

Ubuntu 20.04

Other Software

No response

Repro Steps

Reproducing this requires that your DNS resolver returns the addresses of name servers as additional records.
In my case, on my Work-WiFi, that is the case. On wired LAN it is not.

To see the effects, simply nslookup any domain inside WSL.

Expected Behavior

The expected behaviour would be that WSLs DNS resolver either keeps the additional section as additional section, or just strips it away entirely, since it is optional.

nslookup would look something like this then:

$ nslookup google.com
Server:         172.30.0.1
Address:        172.30.0.1#53

Non-authoritative answer:
Name:   google.com
Address: 142.250.181.206
Name:   google.com
Address: 2a00:1450:4005:802::200e

Actual Behavior

For some reason, the WSL resolver decides to convert all the additional records into normal answers.
This leads to the following bizzare nslookup output:

$ nslookup google.de
Server:         172.30.0.1
Address:        172.30.0.1#53

Non-authoritative answer:
Name:   google.de
Address: 142.250.181.195
Name:   ns1.google.com
Address: 216.239.32.10
Name:   ns2.google.com
Address: 216.239.34.10
Name:   ns3.google.com
Address: 216.239.36.10
Name:   ns4.google.com
Address: 216.239.38.10
Name:   ns1.google.com
Address: 2001:4860:4802:32::a
Name:   ns2.google.com
Address: 2001:4860:4802:34::a
Name:   ns3.google.com
Address: 2001:4860:4802:36::a
Name:   ns4.google.com
Address: 2001:4860:4802:38::a
Name:   google.de
Address: 2a00:1450:4005:802::2003
Name:   ns1.google.com
Address: 216.239.32.10
Name:   ns2.google.com
Address: 216.239.34.10
Name:   ns3.google.com
Address: 216.239.36.10
Name:   ns4.google.com
Address: 216.239.38.10
Name:   ns1.google.com
Address: 2001:4860:4802:32::a
Name:   ns2.google.com
Address: 2001:4860:4802:34::a
Name:   ns3.google.com
Address: 2001:4860:4802:36::a
Name:   ns4.google.com
Address: 2001:4860:4802:38::a

This leads to various ill effects on the WSL Linux system.
Most prominently, apt-get has serious trouble, since it seems to include the nameserver IP addresses in its round robin to fetch from.
This leads to apt-get update/install randomly failing individual fetches with TLS errors, or no response errors, since it's trying to talk http to DNS servers.
Just continously re-trying until it works does work, since it will eventually hit the right IP from the round robin.

Curiously, a small C test program using gethostbyname does not return any of the wrong IPs, so it seems to do some additional filtering in the libc there. And also explains why only certain programs are affected.

Diagnostic Logs

I investigated this a bit with Wireshark.
This is the response from the DNS Server on my WiFi:

As you can see, the addresses of the various name servers are attached as additional records.
Now, if I capture the answer that is passed to WSL from the local resolver it's running:

As you can see, it just turned all those additional records into normal answers, which I'm pretty sure is not at all a valid thing to do, even though it keeps the name intact.

On my LANs DNS server, the additional records are simply not sent along, so the issue does not manifest and apt-get works normally.

[ukpidgeon]

This also affects the output from "host", and causes ssh to try and log in to the first name server listed if the actual host you are trying to connect to is down. Configuring /etc/resolv.conf to use a name server that isn't the host machine (e.g. 8.8.8.8) provides a fix, but isn't ideal.

[beowuff]

Same thing happening to me. I'm VPNd into work, everything hard lined (no wireless).

From PowerShell:
nslookup <hostname>
Server: <dns domainname>
Address: <dns server ip>

Name: <hostname>
Address: <correct ip>

From Ubuntu 20.04, WSL:
nslookup <hostname>
Server: 172.22.192.1
Address: 172.22.192.1#53

Non-authoritative answer:
Name: <correct hostname>
Address: <correct ip>
Name: <dns hostname>
Address: <dns ip address>

This had the effect of causing ssh to connect to the dns server instead of the correct host when the host was rebooting.

[vladonemo]

Facing the same issue. Took me some hours to figure this out while trying to get rancher-desktop working (integrated to wsl).
The workaround is to set set different (upstream) nameserver in the /etc/resolv.conf instead.

[b-diggity]

Duplicate of #5806

[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!