Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net: don't keep reading from UDP resolver after truncated packet #23873

Open
ianlancetaylor opened this Issue Feb 16, 2018 · 4 comments

Comments

Projects
None yet
2 participants
@ianlancetaylor
Copy link
Contributor

ianlancetaylor commented Feb 16, 2018

When the host or dig programs see a malformed packet from a resolver when using UDP, they fall back to using TCP. The net package resolver does not do this; it simply ignores the malformed packet (in (*dnsPacketConn).dnsRoundTrip in net/dnsclient_unix.go). This was done for #13281. I suggest that we do the same.

This is showing up right now for me when I run go test -test.run=TestLookupLongTXT net. I see this:

--- FAIL: TestLookupLongTXT (10.00s)
	lookup_test.go:334: lookup golang.rsc.io on 127.0.0.1:53: read udp 127.0.0.1:39779->127.0.0.1:53: i/o timeout
FAIL
FAIL	net	10.023s

If I run dig -t txt golang.rsc.io the output starts with

;; Warning: Message parser reports malformed message packet.
;; Truncated, retrying in TCP mode.

I suggest that we keep the current behavior for the !resp.IsResponseTo(query) case but change the behavior for an Unpack failure to drop right back to TCP.

CC @mdempsky

@ianlancetaylor ianlancetaylor added this to the Go1.11 milestone Feb 16, 2018

@mikioh mikioh changed the title net: don't keep reading from UDP resolver after malformed packet net: don't keep reading from UDP resolver after truncated packet Feb 17, 2018

@ianlancetaylor ianlancetaylor modified the milestones: Go1.11, Go1.12 Jun 27, 2018

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor Author

ianlancetaylor commented Jun 27, 2018

This should be re-checked given the work done for #21160.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor Author

ianlancetaylor commented Dec 18, 2018

See also #22857.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor Author

ianlancetaylor commented Dec 18, 2018

@iangudger

This comment has been minimized.

Copy link
Contributor

iangudger commented Dec 18, 2018

With the new DNS client, the chances of truncated DNS messages causing problems is greatly reduced, not not eliminated. I believe that now in cases where not all answers are contained in the read UDP message we will either try another DNS server or error out. I agree that trying TCP would be better, but at least failing fast is better than waiting for a timeout.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.