microsoft
Able to nslookup `.local` address but Unable to ping
Windows Version
Microsoft Windows [Version 10.0.19045.4780]
WSL Version
2.3.24.0
Are you using WSL 1 or WSL 2?
- [x] WSL 2
- [ ] WSL 1
Kernel Version
Linux version 5.15.153.1-microsoft-standard-WSL2 (root@941d701f84f1) (gcc (GCC) 11.2.0, GNU ld (GNU Binutils) 2.37) #1 SMP Fri Mar 29 23:14:13 UTC 2024
Distro Version
Ubuntu 24.04
Other Software
No response
Repro Steps
Assume the hostname is foo.
After upgrading Ubuntu from 22.04.5 to 24.04.1:
-
ping foo.localin wsl
Expected Behavior
should ping IP like 172.18.160.1
Actual Behavior
$ ping foo.local -v
ping: sock4.fd: 3 (socktype: SOCK_RAW), sock6.fd: 4 (socktype: SOCK_RAW), hints.ai_family: AF_UNSPEC
ping: foo.local: Name or service not known
$ ping foo.local -v -4
ping: sock4.fd: 3 (socktype: SOCK_RAW), sock6.fd: -1 (socktype: 0), hints.ai_family: AF_INET
ping: foo.local: Name or service not known
$ ping foo.local -v -6
ping: sock4.fd: -1 (socktype: 0), sock6.fd: 3 (socktype: SOCK_RAW), hints.ai_family: AF_INET6
ping: foo.local: Name or service not known
curl cannot use foo.local as proxy:
$ curl 'https://api.ipify.org?format=json'
curl: (5) Could not resolve proxy: foo.local
if removed https_proxy env, curl can visit internet:
$ export https_proxy=""
$ curl 'https://api.ipify.org?format=json'
* Uses proxy env variable no_proxy == 'foo.local,localhost,mirrors.cloud.tencent.com'
* Host api.ipify.org:443 was resolved.
* IPv6: (none)
* IPv4: 104.26.12.205
* Trying 104.26.12.205...
* Connected to api.ipify.org (104.26.12.205) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
* subject: CN=ipify.org
* start date: Sep 15 06:18:44 2024 GMT
* expire date: Dec 14 06:18:43 2024 GMT
* subjectAltName: host "api.ipify.org" matched cert's "*.ipify.org"
* issuer: C=US; O=Google Trust Services; CN=WE1
* SSL certificate verify ok.
* Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA256
* Certificate level 1: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
* Certificate level 2: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://api.ipify.org/?format=json
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: api.ipify.org]
* [HTTP/2] [1] [:path: /?format=json]
* [HTTP/2] [1] [user-agent: curl/8.5.0]
* [HTTP/2] [1] [accept: */*]
> GET /?format=json HTTP/2
> Host: api.ipify.org
> User-Agent: curl/8.5.0
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/2 200
< date: Fri, 01 Nov 2024 00:58:56 GMT
< content-type: application/json
< content-length: 24
< vary: Origin
< cf-cache-status: DYNAMIC
< server: cloudflare
< cf-ray: 8db7f0788bed84b2-HKG
<
* Connection #0 to host api.ipify.org left intact
{"ip":"***.***.***.***"}
But dig works fine:
$ dig foo.local
; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> foo.local
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40653
;; flags: qr rd ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;foo.local. IN A
;; ANSWER SECTION:
foo. 0 IN A 172.18.160.1
foo. 0 IN A 172.18.176.1
foo. 0 IN A 192.168.166.233
foo. 0 IN A 169.254.242.21
;; Query time: 0 msec
;; SERVER: 172.18.160.1#53(172.18.160.1) (UDP)
;; WHEN: Thu Oct 31 16:25:54 CST 2024
;; MSG SIZE rcvd: 106
nslookup too:
$ nslookup foo.local
;; Got recursion not available from 172.18.160.1
Server: 172.18.160.1
Address: 172.18.160.1#53
Non-authoritative answer:
Name: foo
Address: 172.18.160.1
Name: foo
Address: 172.18.176.1
Name: foo
Address: 192.168.166.233
Name: foo
Address: 169.254.242.21
;; Got recursion not available from 172.18.160.1
Name: foo
Address: fe80::ac52:a8c7:50a7:7374
Name: foo
Address: fe80::1486:e7a8:3ccc:79a9
Diagnostic Logs
No response
Logs are required for review from WSL team
If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'. Otherwise please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.
How to collect WSL logs
Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:
Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1
The script will output the path of the log file once done.
If this is a networking issue, please use collect-networking-logs.ps1, following the instructions here
Once completed please upload the output files to this Github issue.
Click here for more info on logging If you choose to email these logs instead of attaching to the bug, please send them to [email protected] with the number of the github issue in the subject, and in the message a link to your comment in the github issue and reply with '/emailed-logs'.
View similar issues
Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it!
Open similar issues:
- HOSTNAME.local: Name or service not known (#10077), similarity score: 0.76
- mDNS stopped working in WSL2 after Windows 11 Pro update (#11022), similarity score: 0.72
Closed similar issues:
- Cannot ping both from Windows host and WSL (#8462), similarity score: 0.73
- Networking mirrored (#10652), similarity score: 0.73
- .local names can only be resolved from wsl2 connected via Ethernet but not via WiFi (#5944), similarity score: 0.73
Note: You can give me feedback by thumbs upping or thumbs downing this comment.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Diagnostic information
Found '/emailed-logs', adding tag 'emailed-logs'
https://github.com/microsoft/WSL/issues/11022#issuecomment-1894612602 fixed mDNS in WSL2 for me.
@AnnAngela thanks for reporting the issue
to make sure I understand the issue correctly, does dig/nslookup foo.local work, but ping foo.local fails?
can you please collect logs using https://github.com/microsoft/WSL/blob/master/diagnostics/collect-networking-logs.ps1? start the script run ping foo.local stop the script
share the zip generated by the script (it will the name starting with "WslNetworkingLogs")
@AnnAngela thanks for reporting the issue
to make sure I understand the issue correctly, does dig/nslookup foo.local work, but ping foo.local fails?
can you please collect logs using
master/diagnostics/collect-networking-logs.ps1? start the script run ping foo.local stop the scriptshare the zip generated by the script (it will the name starting with "WslNetworkingLogs")
WslNetworkingLogs-2024-11-23_11-07-13.zip
Here the log.
Diagnostic information
.wslconfig found
Detected appx version: 2.3.24.0
optional-components.txt not found
Experiencing the same issues. It appears WSL2 is unable to reach 172.16.0.0/12 addresses.
Microsoft Windows 11 Pro 10.0.26200 Build 26200, WSL 2.6.1.0, Debian Forky.
WslNetworkingLogs-2025-11-05_10-05-15.zip
