WSLv1 DNS stopped working (maybe after some recent Windows update - maybe of Intel Chipset driver update)

[vadimkantorov]

Windows Version

Microsoft Windows [Version 10.0.26200.8037]

WSL Version

2.6.3.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

Linux version 4.4.0-26100-Microsoft (Microsoft@Microsoft.com) (gcc version 5.4.0 (GCC) ) #7920-Microsoft Fri Jan 01 08:00:00 PST 2016

Distro Version

24.04

Other Software

Repro Steps

For me this started today, maybe after installing the Intel driver update (but not completely sure of the reason):

$ nslookup
> google.com
;; communications error to 1.1.1.1#53: timed out

$ ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=59 time=3.15 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=3.57 ms

OP:

• No Internet on WSL #13114 (comment)

Expected Behavior

DNS works

Actual Behavior

nslookup in WSLv1 cannot reach 1.1.1.1 (despite ping works), and ping google.com does not work

ping works from cmd.exe

Diagnostic Logs

No response

[github-actions]

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-wsl-logs.ps1 -LogProfile networking instead, following the instructions in Collect WSL logs for networking issues

Once completed please upload the output files to this GitHub issue.

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

[github-actions]

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-wsl-logs.ps1 -LogProfile networking instead, following the instructions in Collect WSL logs for networking issues

Once completed please upload the output files to this GitHub issue.

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

[vadimkantorov]

Networking logs:

WslLogs-2026-04-05_16-49-47.zip

[github-actions]

The log file doesn't contain any WSL traces. Please make sure that you reproduced the issue while the log collection was running.

Diagnostic information

.wslconfig found
Detected appx version: 2.6.3.0
Found no WSL traces in the logs

[vadimkantorov]

/question Well, I followed the log collection instructions. I did run in a side PowerShell session:

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 -LogProfile networking

And then reproduced the issue in a WSLv1 session when the networking logs script asked to do the repro.

[github-actions]

Diagnostic information

Found '/question', adding tag 'question'

[benhillis]

Thanks for filing this. A few observations:

WSL1 uses the Windows networking stack directly — there's no VM, no DNS tunneling, and no NAT proxy involved. DNS requests from WSL1 are regular Windows socket calls, which means they're subject to Windows Firewall rules and any network filtering drivers on the host.

The symptom you're seeing — ICMP (ping 1.1.1.1) works but UDP/TCP port 53 (nslookup) times out — is a classic sign of firewall or network filter driver blocking DNS traffic for WSL1 (pico) processes.

Since you mentioned this started after an Intel driver update, that's likely the cause. A few things to try:

1. Check Windows Firewall for any rules blocking UDP/TCP port 53:

   Get-NetFirewallRule | Where-Object { $_.Enabled -eq 'True' -and $_.Direction -eq 'Outbound' -and $_.Action -eq 'Block' } | Get-NetFirewallPortFilter | Where-Object { $_.LocalPort -eq 53 -or $_.RemotePort -eq 53 }

2. Reset the Winsock catalog (run as Administrator):

   netsh winsock reset

   Then reboot.

3. Check for LSP/WFP filter drivers that the Intel update may have installed:

   netsh winsock show catalog

4. Try rolling back the Intel driver to confirm it's the cause.

Regarding logs: the networking log collector is designed for WSL2's VM networking, so it won't capture WSL1 traffic. For WSL1 DNS issues, a Windows-side packet capture (e.g., netsh trace start capture=yes) while reproducing the issue would be more useful.

[vadimkantorov]

I've found that DNS works again when I connect to some other Wi-Fi network - even with the updated driver. When I'm back on the "bad" Wi-Fi (or on mobile phone tethering), it stops working again

This is very strange, as I don't understand how Wi-Fi firewall can block (or even determine) DNS requests from pico processes.

Windows Update history does not offer rolling the driver install :(

For the network log collector being only useful for WSLv2, it would be great to reflect this in README/issue template and in the issue bot automated message