gabyhelp
commented
2 weeks ago Related Issues and Documentation
- net: dns lookup should retry on TCP for truncated response #5686 (closed)
- net: netgo dns resolver does not return addresses on TCP truncated responses #64896 (closed)
- net: BSD: DNS go resolver loses first UDP outbound packet if onlink target not in neighbor cache #43398
- net: issue with DNS response > 512 bytes (cannot unmarshal DNS message) #21160 (closed)
- net: EDNS(0) records may cause dns dropped by some gateway #65197 (closed)
- net: DNS Lookups Very Slow (netgo) #49253 (closed)
- affected/package: net #57506 (closed)
- net: netgo resolver cannot lookup 254 characters FQDN #54285 (closed)
- net: LookupCNAME returns empty string if entry from /etc/hosts is used #44741 (closed)
- net: go DNS resolver fails to connect to local DNS server #67925 (closed)
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)
mateusz834
LeeBrotherston
Go version
go version go1.23.1 darwin/arm64
Output of
go envin your module/workspace:What did you do?
Select a DNS query which will return a response larger than the current MTU on your default interface. To illustrate I am using
nat.travisci.netis it returns 79 A records, with a packet size of just over 1300.If you run the code snippet below, whilst connected via a standard ethernet connection (probably 1500 MTU), you should get 79 responses, which can be verified by comparing the output of the same query using
nslookup,host,dig, etc.If you now use a connection with a lower MTU, for example using a VPN lowers my MTU to 1280, and run the same tests you will see that the code snippet below only returns 29 results, while
nslookup,host,dig, etc still return the full set of results.If we use some sort of packetsniffer (e.g. wireshark, tcpdump, etc) to analyze the data on the wire, we can see that the response is fragmented due to being larger than the MTU, as we would expect. As far as I can tell the other tools successfully reconstruct the packet from the fragments, however go seems to truncate the response, presumably due to the fragmentation.
This seems to happen on Linux as well as macOS, with and without CGO.
Snippet for testing:
What did you see happen?
I saw the go lookup return truncated results whilst on a lower MTU connection, while nslookup, etc continued to return the full results.
What did you expect to see?
I expected to see the same results between the sample code and nslookup, etc no matter which connection I was using.