Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE

[Barry Leiba <[e-mail]>]

> FWIW, and I do not intend this as a criticism of what you did, I just went back
> to the datatracker and looked at the text of the IETF last call.   There is nothing
> at all in this text that would indicate that the document said anything at all about
> the continued use of the SPF DNS RRtype.   I've also read the document, and
> even reading the conclusion of the document, there's very little there that would
> suggest to me that the spfbis working group was about to deprecate the use of
> the SPF DNS RRtype.

As Murray's already responded, the intent of the document that became
RFC 6686 was simply to report on the SPF/Sender-ID experiment.  That
document never meant to recommend a specific course, and didn't -- so
any cross-area review of that document wouldn't have been likely to
raise this discussion, and no text in that document relating to this
issue would have been appropriate.

That said, there is a general need for chairs, shepherds, and
responsible ADs to be aware of these sorts of things.
Chairs/shepherds need to make sure something about them gets put into
shepherd writeups, at least, and ideally gets sent out to relevant
lists earlier.  Best I can tell, there *was* a discussion of this
earlier, but it didn't get this level of attention.

It would also be good for ADs to put things into the last call
notices, pointing out things that participants in other areas might
want to look at.  We don't have a habit of doing that, and we should.
Even something like, "This specification involves aspects of
[technology X] and [technology Y]; experts in those technologies
should pay particular attention and provide reviews and comments,"
might make a big difference.

> On the other side, here are the arguments that I understand to have been made:
>
> 1. TXT records are not specific to SPF, thus we can't assume that any given TXT
> record is an SPF record.
>
> Rejoinder: doesn't seem to be an issue in practice—no other TXT records are
> needed on the names to which SPF TXT records are typically attached.

Right: the underscore-prefix technique has been vetted before, and as
far as I can tell this issue and its variants are settled.

> 3. Using TXT records is a bad idea.
>
> Rejoinder: this isn't really a technical argument; if there is a technical argument
> in here, it should be stated explicitly, but this argument per se will be ignored.

Actually, I don't agree that it's not a technical argument.  The
second part of that sentence is operative, and I want to drill down on
that: if there's a technical argument in here, let's tease out what it
is.

We really have two issues that really seem to matter here:

1. Should we be working on a transition to type=99 only, rather than
deprecating type=99?

2. Claim (quoting Måns here): overloading TXT is bad.

(1) is being adequately argued back and forth; I want to focus on (2):

Why, specifically, is it bad to use TXT records in an "_spf."
subdomain for this purpose?  What harm does it cause, specifically.
Let's bring that out clearly, and have that part of the discussion,
realizing that some possible arguments already have answers:

- It's not hard to parse these; there are many parsers out there that
work, and there are many text-based protocols that work.

- The "_spf." subdomain eliminates the issue of multi-use collisions
-- DKIM queries, for example, will go to "_dkim." subdomains, and
won't see SPF records in the responses.

What other issues does the use of TXT records in this context cause,
which would make it clear that migration away from them in SPF is
important to avoid damage to the Internet, or at least to the DNS
system?

Barry