On 14Mar20, Viktor Dukhovni allegedly wrote: > On Mar 14, 2020, at 1:26 AM, Paul Vixie <[email protected]> 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 even exist? 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? Mark. _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
