On Wed, Apr 15, 2020 at 02:01:49PM -0400, Rich Felker wrote:
> I'd be interested in reading more on this if you know any references.
> Over 512 bytes of MX records seems like a lot, and seems like a really
> bad idea for a domain configuration since there have always been (as
> you noted, with qmail) compatibility problems with not all sites being
> able to resolve them.
We can discuss it till the cows come home, but at the end of the day a
truncated response, for whatever reason, is quite likely not the right
answer. No amount of repeating that not retrying over TCP is faster
changes the fact the truncated UDP answer is not correct.
It is easy to be fast when the answer does not have to be right, just
always return NODATA, and don't even send the UDP query.
By all means, get the right answer as efficiently as you can, but I have
no sympathy or patience for arguments that advocate not returning the
right answer because that saves time. Especially when there's no
additional cost for the majority of cases that don't yield truncated
responses.
Presently, the MUSL libc stub resolver is to anaemic for use-cases which
involve larger RRsets (SRV, highly-multi-homed hosts, ...) or where the
AD bit is required by the application.
The AD bit issue can be solved by implementing the "trust-ad" option, a
la Glibc.
Robust handling of larger responses requires TCP failover. So long as
MUSL libc punts on correctness it will remain a "toy" stub resolver, not
suitable for the full range of DNS applications.
--
Viktor.
