[dns-operations] creeping poorness of judgement

[Paul Vixie]

On Sunday, 15 March 2020 00:34:54 UTC Viktor Dukhovni wrote:
> On Sat, Mar 14, 2020 at 11:35:51PM +0000, Paul Vixie wrote:
> > > 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)."
> 
> This text merely explains a limitation on the unquoted syntax of
> *single* character strings in a TXT RR.  I says *nothing* about the
> interpretation of multiple substrings.

if i put something in that says

foo bar

and someone down the line interprets this as something other than

foo bar

then what we have here is a failure to communicate. rather than the rule of the 
strongest (code is law; look at the installed base) my reaction is to look at the 
specification, and the oldest implementations. the SPF authors looked at what their 
particular zone file parser did, which was to copy BIND 4.8's behaviour, and so they both 
referenced this and enshrined it. i call that lazy.



so, let's try that again:

> > 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 don't see anything to support that conclusion.  It went in as two
> separate character strings, there is no implied non-empty joiner.

did the sysadmin who edited that zone file realize this? (what does the law of least 
astonishment indicate here?) the fault was in BIND 4.8, which treated "TXT foo bar" as 
TXT "foo bar". if microsoft hadn't copied that in NT3, we would not now be having this 
conversation. is that how we want to evolve?

> > 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.
> 
> This is precisely the sort of ad-hoc complexity we must avoid.
> What happens if there are 8 inter-string breaks (9 strings).
> Do we now consider 256 possible ways to join the strings?

no, and that's not what the text you quoted advises.

> Do encoders need to look for spaces at which to break the strings, and
> failing to find spaces in a long run of non-spaces hope that the
> decoder on the other end will get it right?

no, and that's not what the text you quoted advises.

> Regrettably, despite the many other topics on which we agree, and the
> fantastic generous help you're giving me with the DANE survey, I'm going
> to side with the SPF approach on its merits.

i would never expect to be able to influence your agreement other than by arguing the 
merits.

> 
> > 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 )
> 
> Well, you'd be much better off with the more readable, and
> equally maintainable:
> 
>     @ TXT ( "v=spf1"
>             " ip6:2001:4f8::/32"
>             " ip6:2001:559:8000::/48"
>             " ip4:149.20.56.0/24"
>             " ip4:24.104.150.0/24"
>             " ~all" )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20200315/156ca0b8/attachment-0001.html>