[dns-operations] creeping poorness of judgement

[Paul Vixie]

Mark Delany wrote on 2020-03-14 01:00:
> ...
> 
> 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?

the <character-string> construct was needed for HINFO, so reused for TXT.

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

yes. this code had to run on a PDP-11.

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

that's differentially reasonable. in the oldest zone file parser known, 
the following were equivalent on the wire (two <character-string>'s):

foo IN TXT bar baz

foo IN TXT ( bar baz )

foo IN TXT ( bar
              baz )

whereas this would be a single <character-string>:

foo IN TXT "bar baz"

in my TXT-consuming work i have always treated each <character-string> 
as a word. in MIT HESIOD only one <character-string> was produced for 
each /etc/group or /etc/passwd entry thus encoded, so no argument arose.

> Maybe a one-sentence RFC is in order?
if it would take that little space, there would be need for it. BIND 4 
got this wrong (concatenating the zone file input into as few 
<character-string>'s as could accept the "rdata"). microsoft inherited 
this in NT3 and then copied it thereafter. djbdns copied it but used 
non-maximum-sized segments. BIND 4.9, 8 and 9 went back to 1035 style. 
as far as i know knot, nsd, and powerdns do what BIND has (since 1993) done.

DKIM is being liberal in what it accepts. SPF is not.
-- 
P Vixie