resolving a big TXT record fails with "connection refused"

[dphi]

Submission type

• Bug report

systemd version the issue has been seen with

232-25+deb9u1

Used distribution

Debian Stretch

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.

[poettering]

So, you hit two issues here, and one is caused by the other:

1. The response to your query is larger in size to what classic DNS permits in UDP, (i.e. the response packet will be around 516 bytes, instead of 512 which are permitted). The usually way out with such size issues is to try again via TCP, which knows no such limit. The DNS stub in resolved actually implements that bit, too, but it is disabled by default (for the reasons see resolved: add an option to disable the stub resolver #4061), so the lookup will fail necessarily, unless DNSStubListener= is changed from "udp" to a simple "yes" in /etc/systemd/resolved.conf. And because the TCP doesn't work because disabled you see "Connection to 127.0.0.53#53(127.0.0.53) for kxkperm.ru failed: connection refused."

2. When the response doesn't fit in a DNS UDP packet we are supposed to truncate the datagram to be short enough, and set the TC ("truncation") bit in the header, and we do. However, we simply truncated in the middle of records, which most clients accept, but is not in full conformance with the RFC and causes the " Warning: Message parser reports malformed message packet." mesage. PR rework how resolved's dns stub deals with truncation #6988 fixes that bit.

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...

[poettering]

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 --port option in systemd-nspawn. Maybe we can build on that and make this fully automatic in systemd-resolved. This would leave binding to port 53 completely free for other implementations, and make things "just works"...

But than again, fiddling with the fw automatically in bg is pretty ugly...

[keszybz]

then install a firewall rule to redirect both UDP and TCP traffic on port 127.0.0.53:53

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.

[keszybz]

I'll close this, because resolution using EDNS works just fine.