Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE

[Ted Lemon <[e-mail]>]

On Apr 26, 2013, at 10:52 AM, Murray S. Kucherawy <[e-mail]<mailto:[e-mail]>> wrote:
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.

Okay, fair enough.   Please do note that I didn't say that there was process breakage—I said the process seemed to have been followed correctly, but produced a less than perfect outcome.

The sense in which I mean that with respect to RFC 6686 is that several people have mentioned the IETF last call on RFC 6686 as if it means that the IETF now has an opinion on whether to deprecate SPF.   It sounds like we both agree that it does not, so this wouldn't be an example of process breakage.   However, if people came to the conclusion that it did mean that, it's worth talking about.

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.

OK.   But presumably these parts of the internet are going to start really seriously breaking as IPv6 and DNSSEC deployment increase.   So this doesn't _seem_ like a long-term concern.   What am I missing?

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'?".

Sure, and a base-64 encoded string will never have an equals sign in that position, so we don't have to worry too much about a random collision.

  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.

These two points taken together seem like a pretty strong argument in favor of _not_ deprecating the SPF record; in this case, only the SPF record would have made it back to the MTA.