Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE

["Murray S. Kucherawy" <[e-mail]>]

On Fri, Apr 26, 2013 at 6:41 AM, Ted Lemon <[e-mail]> wrote:

> 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.
>

RFC6686 never set out to make a conclusion about the RRtype question, but
rather to determine which of the four protocols MARID discussed appear to
have enough traction to warrant advancement along the standards track, thus
concluding "the experiment".  Accordingly, the abstract for that document
doesn't say anything about this matter.

In the process of collecting data to answer that question, we realized that
the numbers also highlight the non-use of type 99 by both senders and
receivers.  We were very careful in our wording of RFC6686 to point out
that type 99, though supported both in protocol and software, is actually
not very useful, and said nothing at all about what we planned to do with
it.  RFC6686 provides supporting evidence for what the main spfbis draft is
doing, but does not itself introduce those actions.

I don't think there was process breakage here.


>
> It seems to me that the argument in favor of deprecating SPF is that
> nobody is publishing SPF records, despite widespread support in software.
> This results in unnecessary traffic, the elimination of which would have
> minimal impact.
>

That's not the complete argument I and others have been making.  Widespread
support in DNS software and SPF libraries exists, but there are also
existing components of the infrastructure that interfere with either
publication or handling of type 99 queries and replies, long after the type
was assigned.  RFC6686 calls this out.  The rejoinder we're hearing to this
is merely the gainsay of that position despite both anecdotal and empirical
evidence to the contrary.

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.
>

Moreover, parsing TXT records is not hard, nor is answering the question
"Does this one start with the string 'v=spf1'?".  We saw one case in our
survey of a zone that had 37 TXT records at the same query point; SPF code
is able to pull out the applicable one just fine.


>
> 2. Because TXT records aren't specific to SPF, a query for TXT records may
> return an unexpectedly large result set, requiring fallback to TCP.
> Rejoinder: doesn't seem to be an issue in practice.
>

That's not correct; there are still packet filters out there configured by
default to disallow TCP over port 53.  We discovered this during the
RFC6686 surveys.

-MSK