WSL Internet Connection Sharing DNS resolver does not adhere to 512 byte UDP limit #7642
Comments
|
Likely related: golang/go#44135 For Go developers on WSL2 stumbling on this bug from elsewhere; you need to force CGO for dns resolution. (e.g. GODEBUG=netdns=cgo or override the resolver -- see the gist above ) Edit: A mitigation to grow the default packet buffer size from 512 bytes to 1232 bytes introduced in Go 1.18 and backported 1.17 and 1.16. Recommend using 1.18.0+, 1.17.8+ or 1.16.15+ to compile your Go programs that are impacted by this issue. |
|
I'm getting this error when doing docker/podman pull from corporate Artifactory, getting DNS response bigger than 512 bytes (in my case 678 bytes). Running wsl-vnpkit (https://github.com/sakai135/wsl-vpnkit), lowers the DNS response size to 197, overcoming the problem with DNS issue and allowing image pull to work again. |
|
Our Terraform deployments suddenly fail with "cannot unmarshal DNS message" for calls to "management.azure.com". |
|
A mitigation to grow the default packet buffer size from 512 bytes to 1232 bytes introduced in Go 1.18 and backported 1.17 and 1.16. Recommend using 1.18.0+, 1.17.8+ or 1.16.15+ to compile your Go programs that are impacted by this issue. See also golang/go#51127 |
|
This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request. Thank you! |
Version
Microsoft Windows [Version 10.0.22000.282]
WSL Version
Kernel Version
5.10.60.1
Distro Version
Ubuntu 20.04
Other Software
Go programs using the Go dns resolver.
Repro Steps
In a WSL2 terminal, capture DNS UDP traces. These can also be saved to disk and viewed in wireshark later. You could also use the very old (but still working) Microsoft Network Monitor 3.4.
This isn't a new issue as I've observed it intermittently for a year+. I just finally dug into it and (I think) root caused it. I've been having intermittent issues with certain Go programs failing with "cannot unmarshal DNS message". This appears related to the ICS dns resolver sending > 512 byte packets. The Go language strictly adheres to the 512 byte packet limit when using the netgo dns resolver.
Edit: Go versions 1.18.0+, 1.17.8+ or 1.16.15+ now accept a packet size of 1232 bytes.
Also note that I repro'd this on a non-corporate machine (no VPNs or firewalls) and verified with TCPView that the only dns listener on udp port 53 is the ICS SharedAccess service.
Capture DNS packet traces for later analysis; add "-w out.pcap" to capture a file.
Repro -> Run a
digcommand without the edns option (DNS 512 byte packet limit should be observed)Run a
digcommand with the edns option (large packets are expected; not a bug)Per https://docs.microsoft.com/en-us/windows/wsl/troubleshooting Internet Connection Sharing (ICS) is a required component of WSL 2. It is the default DNS resolver for an out-of-the-box setup.
Expected Behavior
The dig utility doesn't fail, but an equivalent Go program which adheres to the RFC will fail. The ICS DNS resolver should adhere to DNS RFC spec when requests do not support large UDP packets (e.g. no EDNS option).
This particular host name happens to exhibit the issue given how long the CNAMEs are and the lack of message compression.
Actual Behavior
Failing example. Note the lack of an EDNS option, yet the packet returned is greater than the allowable size. This interacts w/ the Go resolver that truncates the packet to 512 bytes.
Diagnostic Logs
PCAP File w/ the two 'dig' examples https://1drv.ms/u/s!At9UHnuKzNw8rnz4ZsJekezwP64p?e=TNHJ4t
Gist of a minimal Go program that will also repro: https://gist.github.com/jboelter/3dfbc449c873186bc26488a8600cac74
The text was updated successfully, but these errors were encountered: