[dns-operations] creeping poorness of judgement

[Paul Vixie]

On Saturday, 14 March 2020 22:50:19 UTC Viktor Dukhovni wrote:
> On Mar 14, 2020, at 4:00 AM, Mark Delany <b9w at charlie.emu.st> wrote:
> > 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.
> 
> I largely share the sentiment.  At this point it looks like the above
> interpretation would most closely conform to existing practice.
> 
> I know of no specifications that concatenate TXT RR strings with spaces.

and yet, RFC 1035 says this:

"<character-string> is expressed in one or two ways: as a contiguous set
of characters without interior spaces, or as a string beginning with a "
and ending with a ".  Inside a " delimited string any character can
occur, except for a " itself, which must be quoted using \ (back slash)."

ask yourself, if you were parsing a zone file, and you found a TXT RR, and it had spaces in 
it, what would you do? since the <character-string> cannot include interior spaces unless 
"quoted like this", what does <space> mean?

it means each word is a character string, or else, spaces are a syntax error unless they are 
quoted.

once that's decided, the ignorant wrongheadedness of the SPF interpretation becomes 
pretty egregious. if it went in as "TXT foo bar" then it should be treated as "foo bar" even 
if the wire encoding of "TXT foo bar" is in fact ( "foo" "bar" ).

i realize that SPF has a massive installed base, and that an installed base gives one great 
market power. but it's still wrong, and should still be fixed. (BIND 4 had a 100% market 
share, but got this wrong, and so, got fixed.)

> ...
> 
> So while I've found no existing practice of joining with spaces, there
> is it seems an expectation that the component substrings can be
> separately meaningful in some applications.
> 
> So my take is that applications that expect a single string per TXT
> record should just join without inserting spaces, while applications
> that expect multiple values can use the verbatim substrings without
> concatenation.

if we're going to write an RFC to clarify this, it could say almost that. but i think the 
robustness principle calls for something slightly more subtle, and it doesn't have to do 
with inserting spaces.

if a multi-segment string is encountered by a TXT-consuming application, and if that 
multi-segment string can be unambiguously interpreted by the application as some 
machine-form instruction by concatenating the segments, then this should be done. 
however, if such concatenation renders an ambiguous result (possibly meaningful but 
possibly erroneous) then the application should try to interpret each text segment as a 
separate word, that is, as if separated by whitespace characters. if the segments-as-words 
interpretation is less ambiguous or less erroneous, then this interpretation should prevail.

here's what i'm going with, by the way:

_spf                    TXT     ( 	v=spf1\032
/				/2001:4f8::/32\032
				2001:559:8000::/48\032
				149.20.56.0/24\032
				24.104.150.0/24\032
				~all )

but i'd like to be able to remove those \032 workarounds in ~10 years.

-- 
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20200314/11859857/attachment.html>