-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
resolving a big TXT record fails with "connection refused" #6520
Comments
When we a reply message gets longer than the client supports we need to truncate the response and set the TC bit, and we already do that. However, we are not supposed to send incomplete RRs in that case, but instead truncate right at a record boundary. Do that. This fixes the "Message parser reports malformed message packet." warning the venerable "host" tool outputs when a very large response is requested. See: systemd#6520
So, you hit two issues here, and one is caused by the other:
Ideally we'd fix item 1 pointed out above somehow, but I am not sure how to do this best, without reopening the conflict situation with other DNS servers about who owns TCP port 53. Note that supporting TCP transport is optional according to the RFC, that's why we decided to go this way, feeling that we are in fact in-line with the RFC. But of course, not offering TCP means that legacy clients can't resolve large RRsets... Note that modern clients (such as dig) don't suffer by this limitation, as they support edns which supports larger datagrams, and resolved supports that too. In fact most clients which expect larger responses (i.e. more than a simple A/AAAA/PTR look-up) tend to use edns these days, hence one could also see this as a limitation of "host", that is easily fixable by switching to dig... It's a bit of a nasty situation. I'd love to fix this properly, but I really don't know how. Given that the impact is not too bad I'll drop this issue from the v235 milestone however, but I will leave this issue open for further discussion, and maybe we can find a way... |
So, one possible way out would be for resolved to listen on a different port than 53 altogether, and then install a firewall rule to redirect both UDP and TCP traffic on port 127.0.0.53:53 to it. Some firewall code exists already in systemd, due to the But than again, fiddling with the fw automatically in bg is pretty ugly... |
Let's not do this, unless absolutely necessary. There's always going to be corner cases, in particular somebody will start a service on that port and it'll not receive packets. Since the impact of this is minor, I think we should close this once #6988 is merged. It's OK that old tools get a failure in cases which they don't support, and which is supported by newer tools just fine. |
When we a reply message gets longer than the client supports we need to truncate the response and set the TC bit, and we already do that. However, we are not supposed to send incomplete RRs in that case, but instead truncate right at a record boundary. Do that. This fixes the "Message parser reports malformed message packet." warning the venerable "host" tool outputs when a very large response is requested. See: systemd#6520
I'll close this, because resolution using EDNS works just fine. |
Submission type
systemd version the issue has been seen with
Used distribution
In case of bug report: Expected behaviour you didn't see
$ host -t TXT kxkperm.ru 127.0.0.53
Using domain server:
Name: 127.0.0.53
Address: 127.0.0.53#53
Aliases:
kxkperm.ru descriptive text "v=spf1 redirect=mail.kxkperm.ru"
kxkperm.ru descriptive text "v=spf1 redirect=remote.kxkperm.ru"
kxkperm.ru descriptive text "v=spf1 mx ip4:92.53.116.0/22 ip4:92.53.96.0/22 ip4:92.53.112.0/22 ip4:92.53.104.0/22 ~all"
kxkperm.ru descriptive text "v=DKIM1; k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDFb+c2ujOSaxuqBCnwPet0Rw+qRi0B1LkGgH5TOaY0dVp2Tn0qUO5Z6XsCkZx+H2EVHlQDiD31YXsAAueGKyO6iFYugqzFAB+x++BTOuPehSMnMCvqzFHRoavWNGXU9FiLLXBxzjBQIvk9WdaJJvNWrrpV5QkIoZN22zMNt457VQIDAQAB"
kxkperm.ru descriptive text "v=spf1 redirect=_spf.yandex.ru"
In case of bug report: Unexpected behaviour you saw
$ host -t TXT kxkperm.ru
;; Warning: Message parser reports malformed message packet.
;; Connection to 127.0.0.53#53(127.0.0.53) for kxkperm.ru failed: connection refused.
Other records can be resolved without issues.
The text was updated successfully, but these errors were encountered: