[dns-operations] creeping poorness of judgement

[Phil Pennock]

On 2020-03-13 at 21:07 -0700, Paul Vixie wrote:
> the concatenation of <character-strings> on 255-octet boundaries has never
> been specified in a DNS RFC, and if the DKIM and SPF specifications require
> this, they are legislating from the bench.

Isn't that one of the points of DNS: that semantics should be laid on by
applications above it, while RFC 2181 keeps the DNS itself much more
agnostic about such matters?

So you can have embedded NULs or whatever else takes your fancy in TXT
strings, and it's up to the application layer protocol to specify
constraints and interpretation.

I've successfully pushed back against DNS tooling behavior which says
"just join TXT strings together" and persuaded folks that this is
application specific, with that being one common behavior which it's
good to support.  In Exim's case, in those cases where folks have to
manually code DNS lookups with `${dnsdb ...}`, the TXT handling
explicitly allows for specifying how results from multiple strings, and
multiple records, should be handled.

I disagree with SPF as an approach but suck it up; but AFAICT both SPF
and DKIM are doing absolutely the right thing in specifying what their
applications require should be done with TXT strings, nailing down
ambiguities.

DKIM went one better though: the most common break is going to be inside
the base64string and the grammar explicitly allows for folding
whitespace there, so if some layer does join together DNS strings with
whitespace, DKIM parsers are required to just handle it and strip it
back out.  Now _that's_ a nice touch.  If someone is using bare strings
inside parens, then that's just added FWS on either side of a tag-spec,
and again ignored.

-Phil