DNS performance degradation: DnsQueryRaw bypasses Windows DNS cache, negative responses never cached by systemd-resolved

[syed-dawood]

Summary

WSL's DNS tunneling suffers from significant performance degradation because DnsQueryRaw bypasses the Windows DNS cache (by injecting DNS_QUERY_BYPASS_CACHE internally), and systemd-resolved — the only remaining caching layer — is compiled with Cache=no-negative on several major distros (Ubuntu 24.04, etc.). This means NODATA/NXDOMAIN responses (e.g., AAAA lookups for IPv4-only hosts) are never cached, causing every dual-stack lookup to pay a full DNS tunnel round-trip for the uncached negative response.

Reproduction Steps

1. Use WSL 2 with Ubuntu 24.04 (systemd 255)
2. Run resolvectl statistics to observe cache state
3. Run dig github.com multiple times
4. Observe that AAAA NODATA responses are never cached — cache misses remain high

Expected Behavior

Negative DNS responses (NODATA/NXDOMAIN) should be cached by systemd-resolved so that repeated lookups for the same hostname don't pay a full round-trip through the DNS tunnel each time.

Actual Behavior

Every AAAA lookup for an IPv4-only hostname results in a cache miss because systemd-resolved is configured (at compile time on Ubuntu) with Cache=no-negative, and since DnsQueryRaw bypasses the Windows DNS cache, there is no caching layer at all for these responses.

Benchmark Data (Ubuntu 24.04, systemd 255, WSL 2.7.1.0)

Metric	Cache=no-negative (default)	Cache=yes (fix)
Avg latency (10 queries)	24.0 ms	10.1 ms
Cache hits / misses	9 / 11	18 / 3
Cache entries	1 (A only)	2 (A + AAAA NODATA)

2.3× faster average, 9× fewer cache misses.

Root Cause Analysis

1. DnsResolver.cpp line 207 explicitly notes: "// N.B. All DNS requests will bypass the Windows DNS cache"
2. DnsQueryRaw injects DNS_QUERY_BYPASS_CACHE internally — this is documented Microsoft API behavior
3. Ubuntu 24.04 compiles systemd-resolved with Cache=no-negative (visible via resolvectl statistics)
4. With the Windows cache bypassed and negative caching disabled, every dual-stack lookup (A + AAAA) for an IPv4-only host sends the AAAA query through the full tunnel every time

Proposed Fix

Write a systemd-resolved drop-in configuration at /run/systemd/resolved.conf.d/wsl-dns-cache.conf with Cache=yes during GenerateSystemdUnits() in init.cpp. This:

• Uses the same UtilMkdirPath() + WriteToFile() pattern already used in HardenMirroredNetworkingSettingsAgainstSystemd()
• Is non-persistent (/run is tmpfs, cleared on reboot)
• Is non-fatal (failure to write is silently ignored)
• Is distro-agnostic (only affects distros using systemd-resolved)
• Has zero impact on distros that don't use systemd-resolved

Related Issues

• DNS resolver sets TTL for all answers to 0 #9423 — DNS resolution performance
• WSL DNS tunnel nameserver appends search suffixes to IPv6 queries for domains without AAAA records, causing timeouts and mismatches #13415 — DNS latency/timeout complaints

Environment

• WSL version: 2.7.1.0
• Windows version: Windows 11
• Distro: Ubuntu 24.04 (systemd 255)
• DNS tunneling: enabled (default)

[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'.

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any author activity for the past 7 days. If you're still experiencing this issue please re-file it as a new issue.

Thank you!