WSL 2 does not resolve local hostnames as it does in Windows (DNS issue)

[JRHeaton]

Please fill out the below information:

• Your Windows build number: Microsoft Windows [Version 10.0.18363.836]

• What you're doing and what's happening: Trying to SSH to any device on my local network by way of DNS hostname resolution, and finding that WSL does not resolve hostnames properly for local devices.

j@jbeast /m/c/U/gojoh> ssh -vvv pi@raspberrypi
OpenSSH_7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1d  10 Sep 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "raspberrypi" port 22
ssh: Could not resolve hostname raspberrypi: Name or service not known

• What's wrong / what should be happening instead: WSL should resolve hostnames the exact same way that commands invoked from cmd.exe and powershell.exe can. I am able to run the above command in the command prompt (Windows compiled version of SSH) and have no issues. I also can invoke cmd.exe/powershell.exe from bash and get the same, expected and correct behavior:

j@jbeast /m/c/U/gojoh> uname -a
Linux jbeast 4.4.0-18362-Microsoft #836-Microsoft Mon May 05 16:04:00 PST 2020 x86_64 GNU/Linux
j@jbeast /m/c/U/gojoh> powershell.exe "Resolve-DnsName raspberrypi"

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
raspberrypi.local                              AAAA   120   Answer     fe80::3867:d82b:54cf:a8d6
raspberrypi.local                              A      120   Answer     192.168.1.84


j@jbeast /m/c/U/gojoh> cmd.exe
Microsoft Windows [Version 10.0.18363.836]
(c) 2019 Microsoft Corporation. All rights reserved.

C:\Users\gojoh>ssh pi@raspberrypi
pi@raspberrypi's password:^C

What should be happening is that DNS resolution in the WSL Linux environment works exactly the same as in the Windows environment. Without this, we're forced to "back out" into Windows-land to resolve the IP and then use that directly, which is a huge usability hit. The whole point of the WSL is to provide an alternative environment to the Windows CLI, one which is familiar to developers. IMO a working DNS resolution is a pretty big part of that, lest we need to rely on again, escape-hatching to Windows or workaround by using a proper full Linux distro in a VM software like virtualbox, which will provide this networking translation layer without problems.

• Strace of the failing command, if applicable: strace -o ssh_dns_failure.strace -f ssh pi@raspberrypi https://gist.github.com/JRHeaton/a67f922837cda51dacd3c1594cd13c4d

[therealkenc]

Fundamentally variation #4825. Muticast messages don't make it from your pi to inside WSL.

[vineethelias]

1. Check if you can ssh using IP
2. Do a debug with ssh -vvv
3. Check if you can resolve the DNS name with nslookup
4. Make sure the nssswitch.conf is good.

If you still not able to get is work, follow below steps.

Automated steps: https://gist.github.com/matthiassb/9c8162d2564777a70e3ae3cbee7d2e95

First run on powershell:
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object -ExpandPropert ServerAddresses

Then run bash on windows with either ubuntu or bash commands (depending on your installation). Edit the /etc/resolv.conf and replace all nameserver {ip} with the ones generated by the top one.

You should have internet and intranet back now. Remove the first line to make it permanent but be aware if you change networks it will not update anymore. (back it up first maybe?)

[JRHeaton]

Still waiting for a solution to what feels like a basic problem here... host name resolution should not be this complex. I should be able to access whatever I can access in windows. Do the WSL developers fundamentally disagree? Or is this just a low priority? We are all waiting for a response...

[luiszun]

I'm facing the same issue, except the other way around!
wsl resolves, cmd.exe and PS don't

PS C:\Users\luiszun> ping luiszunvm
Ping request could not find host luiszunvm. Please check the name and try again

luiszun@luiszun-box ~ $ ping luiszunvm
PING luiszunvm (192.168.12.123) 56(84) bytes of data.

I thought it had to do with the name server being chosen, so I took from one of the replies above to figure out the NS used by PS

PS C:\Users\luiszun> Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object -ExpandPropert ServerAddresses
192.168.12.1

I think, surely that nameserver doesn't know my desired host name?
Nope! It knows:

luiszun@luiszun-box ~ $ dig @192.168.12.1 luiszunvm +short
192.168.12.123

But it timesout in PS (note that any non-resolvable domain times out, I haven't seen something like NXDOMAIN)

PS C:\Users\luiszun> Resolve-DnsName -Name luiszunvm -Server 192.168.12.1
Resolve-DnsName : luiszunvm : This operation returned because the timeout period expired
At line:1 char:1
+ Resolve-DnsName -Name luiszunvm -Server 192.168.12.1
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationTimeout: (luiszunvm:String) [Resolve-DnsName], Win32Exception
    + FullyQualifiedErrorId : ERROR_TIMEOUT,Microsoft.DnsClient.Commands.ResolveDnsName

All this was to say: there's a difference in how WSL and cmd/ps does DNS queries.

[Frojdholm]

I had the same problem, but like has been shown above the query actually resolves to a .local hostname

PS> ping raspberrypi_hostname
Pinging raspberrypi_hostname.local [<>] with 32 bytes of data:
...

and pinging the .local hostname worked for me in WSL 2.

So then I can ssh into the pi by using

$ ssh user@raspberrypi_hostname.local

but to make it the same as on Windows I created the following config file in ~/.ssh/config

Host raspberrypi_hostname
    HostName raspberrypi_hostname.local

which makes it possible to run

$ ssh user@raspberrypi_hostname

in WSL 2.

While this doesn't solve the underlying DNS issue it solves the particular problem of ssh-ing to a machine on your local network. So I'll leave this here if others, like me, are searching for a solution to this.

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

[guenhter]

Issue is still relevant

[dannystaple]

There's some intermittency on either side here. I've had the same host work sometimes in both, sometimes only in command, and sometimes only in WSL ubuntu. I am on Windows 11:

>wsl --version
WSL version: 2.2.4.0
Kernel version: 5.15.153.1-2
WSLg version: 1.0.61
MSRDC version: 1.2.5326
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26091.1-240325-1447.ge-release
Windows version: 10.0.22631.3737

$ uname -a
Linux danny-pc 5.15.153.1-microsoft-standard-WSL2 #1 SMP Fri Mar 29 23:14:13 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

[dannystaple]

I've since found #11022, which seems to track that this happened after a window 11 update, with a potential fix too.