microsoft / microsoft/WSL

WSL DNS tunnel nameserver appends search suffixes to IPv6 queries for domains without AAAA records, causing timeouts and mismatches

Open
#13,415 10 comments 5 reactions 0 assignees View on GitHub
network
Dominant language
C++
Stars
33.7k
Forks
1.8k
Avg merge
3d 17h
Merged PRs (30d)
116

Description

### Windows Version

Microsoft Windows 11 Pro [10.0.26100 Build 26100]

### WSL Version

2.3.26.0

### Are you using WSL 1 or WSL 2?

- [x] WSL 2
- [ ] WSL 1

### Kernel Version

5.15.167.4-1

### Distro Version

Ubuntu 24.04 and Debian 13

### Other Software

GitHub Copilot Chat runs in a timeout, likely because api.github.com hat no IPv6 and this bug causes slow DNS responses.

1. Other issues may be caused by this one, eg. https://github.com/microsoft/WSL/issues/13391

### Repro Steps

Be aware that the behavior may differ, if you have no DNS search suffix configured on your host. I could only test it with search suffixes. The behavior occurred on newly installed distros.

When running DNS queries in WSL (tested with Ubuntu and Debian), the virtual nameserver (eg. 10.255.255.254, DNS tunnel mode) appends Windows search suffixes to IPv6 (AAAA) queries for domains that only have IPv4 addresses (e.g., github.com, api.github.com, nbsp.de). This results in repeated, slow DNS requests and "question section mismatch" errors, as shown in the attached screenshots. The suffixes themselves are correct and match our company configuration.

Image

On native Windows (PowerShell), DNS queries for the same domains are fast and do not show mismatches. I tested ist with different Nameservers (public, company internal), result were always correct and quick.

Image

According to WSL documentation, the virtual nameserver should simply forward DNS requests to the Windows host DNS, but the behavior differs on host and in WSL: the latter appears to make separate queries for IPv4 and IPv6, appending suffixes to the IPv6 queries even when there is a valid IPv4-address for the domain, which makes no sense. With DNS tunneling active, the resolve.conf is generated on WSL start and contains the (virtual WSL) NS and the search suffixes. When I replaced the virtual WSL NS with a real one (1.1.1.1), everything worked correct, thus the WSL NS tunneling is the cause of the problem. When I removed the search suffixes from the resolv.conf the behavior was still the same, thus the Host DNS appended the suffixes when it was asked by the WSL tunnel. **General problem: when a domain (api.github.com) has a valid IPv4 but no IPv6, it makes no sense to add a suffix an look for an IPv6 on a different domain.**

### Steps to Reproduce:

1. Use WSL (Ubuntu or Debian default) with DNS tunneling enabled, `/etc/resolv.conf` is generated by WSL. The NS (eg. 10.255.255.254) is provided by the WSL framework.

Image

2. Run nslookup api.github.com, or dig api.github.com NS (Package dnsutils must be installed)
3. Observe slow response and "question section mismatch" errors for AAAA queries.
4. Compare with the same command in Windows PowerShell (fast, no mismatch).
5. Replace the nameserver in [resolv.conf](vscode-file://vscode-app/c:/Users/seethaler/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/home/sfdev/resolv.conf/vs/code/electron-browser/workbench/workbench.html) with a public DNS and observe correct behavior.

### Expected Behavior

DNS queries for domains without IPv6 records should return quickly, without unnecessary suffix appending or mismatch errors.

### Actual Behavior

WSL DNS tunnel nameserver appends suffixes to IPv6 queries, causing delays and mismatches.

### Diagnostic Logs

_No response_

Contributor guide

Open the contributing guide

Research direction

Reproduce the behavior in WSL 2 with DNS tunneling enabled, using the generated /etc/resolv.conf and nslookup or dig for api.github.com; compare the results with Windows PowerShell and a public nameserver. Trace the WSL virtual nameserver's handling of IPv6 queries and search suffixes, then verify that domains without AAAA records return promptly without question-section mismatches.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
networking, operating-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.