-
Notifications
You must be signed in to change notification settings - Fork 18k
net: netgo dns resolver does not return addresses on TCP truncated responses #64896
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
Labels
Milestone
Comments
Change https://go.dev/cl/552418 mentions this issue: |
(attn @ianlancetaylor @neild) |
ezz-no
pushed a commit
to ezz-no/go-ezzno
that referenced
this issue
Feb 18, 2024
UDP messages may be truncated: https://www.rfc-editor.org/rfc/rfc1035#section-4.2.1 > Messages carried by UDP are restricted to 512 bytes (not counting > the IP or UDP headers). Longer messages are truncated and the TC > bit is set in the header. However, TCP also have a size limitation of 65535 bytes https://www.rfc-editor.org/rfc/rfc1035#section-4.2.2 > The message is prefixed with a two byte length field which gives the message length, excluding the two byte length field. These limitations makes that the maximum possible number of A records per RRSet is ~ 4090. There are environments like Kubernetes that may have larger number of records (5000+) that does not fit in a single message. In this cases, the DNS server sets the Truncated bit on the message to indicate that it could not send the full answer despite is using TCP. We should only retry when the TC bit is set and the connection is UDP, otherwise, we'll never being able to get an answer and the client will receive an errNoAnswerFromDNSServer, that is a different behavior than the existing in the glibc resolver, that returns all the existing addresses in the TCP truncated response. Fixes golang#64896 Signed-off-by: Antonio Ojea <[email protected]> Change-Id: I1bc2c85f67668765fa60b5c0378c9e1e1756dff2 Reviewed-on: https://go-review.googlesource.com/c/go/+/552418 Reviewed-by: Ian Lance Taylor <[email protected]> Reviewed-by: Ian Gudger <[email protected]> Auto-Submit: Ian Lance Taylor <[email protected]> Reviewed-by: Mateusz Poliwczak <[email protected]> Reviewed-by: Mauri de Souza Meneguzzo <[email protected]> Reviewed-by: Damien Neil <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
Long history: https://gist.github.com/aojea/32aeaa86aacebcdd93596ecb70fcba4f
DNS UDP messages may be truncated if there are many records,
https://www.rfc-editor.org/rfc/rfc1035#section-4.2.1
However, TCP also have a size limitation of 65535 bytes
https://www.rfc-editor.org/rfc/rfc1035#section-4.2.2
These limitations makes that the maximum possible number of A records per RRSet is ~ 4090.
There are environments like Kubernetes that may have larger number of records (5000+) that does not fit in a single message. In this cases, the DNS server sets the Truncated bit on the message to indicate that it could not send the full answer despite is using TCP, see coredns/coredns#3660 (comment)
The existing golang resolver returns
errNoAnswerFromDNSServer
if it receives a TCP response, discarding all the existing records in the response.On the contrary, the glibc resolver returns the existing records in the TCP response despite it has the truncated bit set.
We should have the same behaviour in both resolvers, and only retry when the TC bit is set and the connection is UDP,
otherwise, we'll never being able to get an answer and the client will receive an errNoAnswerFromDNSServer, that is not the same behavior as in the glibc resolver.
The text was updated successfully, but these errors were encountered: