[dns-operations] creeping poorness of judgement
b9w at charlie.emu.st
Sat Mar 14 08:00:44 UTC 2020
On 14Mar20, Viktor Dukhovni allegedly wrote:
> On Mar 14, 2020, at 1:26 AM, Paul Vixie <paul at redbarn.org> wrote:
> > or else, only if the segment is the maximum size permitted by TXT RDATA formatting, should it be presumed to have been split from a larger string.
> Some web searches turn evidence of implementations that
> split long text strings into chunks where even the non-final
> chunks are shorter than 255 bytes. :-(
It's all very well complaining about applications which make different
interpretations of TXT, but perhaps the underlying issue is that TXT
semantics are sloppy to start with?
First off, why on earth does TXT even have substrings? What value do
they add and which applications are taking advantage of such value?
Was there some external limitation such as zone-file parsing that
introduced substrings in the first place? I mean, why do substrings
Second off, why an 8-bit length field? Why not a 16-bit or even a
32bit length field and eliminate substrings? Alternatively why not
some sort of end-of-RR sentinal or implicit length as occurs with all
other RRs? Are we all floundering around TXT processing due to a 1980s
premature optimization around a byte or two of payload?
The biggest problem with an 8-bit length is that you have no clue
whether the input string was split due to length limitations or
semantic requirements. This is where a lot of the hand-wringing seems
to come from.
Methinks the safest outcome is that TXT substrings should be treated
as an artifact of the limitations of TXT RRs or a side-effect of
serialization and should have no semantic value whatsoever.
Maybe a one-sentence RFC is in order?
More information about the dns-operations