WSL DNS tunnel nameserver appends search suffixes to IPv6 queries for domains without AAAA records, causing timeouts and mismatches
- 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.
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.
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.
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
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