[dns-operations] creeping poorness of judgement
paul at redbarn.org
Sat Mar 14 08:50:43 UTC 2020
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
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.
More information about the dns-operations