Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE

[Doug Barton <[e-mail]>]

On 04/25/2013 11:30 PM, Murray S. Kucherawy wrote:
> On Thu, Apr 25, 2013 at 11:05 PM, David Conrad <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>      > So how much energy are the DNS experts going to put into cleaning
>     up their house while demanding the mail people clean up theirs?
>
>     So, this is about revenge because it used to be hard to get RRtypes?
>
>
> Did I really come across as that petty?

Uncharitable interpretation of the current situation could come to that 
conclusion.

> No, what I'm saying is that the way things were ten years ago

As I (and others) have said many times, things were rough at the time 
SPF came to bloom. However, and this is really important to understand, 
it's not 10 years ago anymore.

I'm not being petty when I say that. It really is important to 
understand, the time is going to pass anyway. In the time period between 
then and now a LOT of things have happened in the DNS world, and the 
situation is dramatically different now than it was.

What is even more important to understand is that 10 years from now 10 
more years will have passed. We have a chance now to set in motion 
events that will continue to improve the situation, so that 10 years 
from now we can look back and laugh at the SPF TXT record, and have joy 
that things are so much better. Or, we can spend 10 more years with the 
same silly kludge, and not have made any progress at all. Either way, 
the next 10 years are going to pass.

> pushed the
> SPF community to the place it's in now, ugly as it is.  SPF, in the
> interim, has become very widely deployed.

And some of the software that handles SPF has already switched to 
querying SPF/99 first. There is no reason that the rest could not do 
that as well. Then by the time that the next version of SPF is released, 
it can be all SPF/99, and no TXT. Eventually the TXT record will die out 
altogether.

As I have mentioned previously, in the DNS world we have a LOT of 
experience dealing with issues EXACTLY like this. We know how it works, 
we know what long tails look like, and we know that as problems go it's 
a pretty easy problem to deal with.

> Suddenly now we have a few
> voices from the ivory tower asserting that the same community needs to
> go out and re-do things the way they should have been done in the first
> place, now that we finally have a somewhat more reasonable perspective,
> even though some of the vestiges of ten years ago are in fact still
> around.  My reaction to that is "You can't be serious."  That doesn't
> sound like revenge at all to me, just pragmatism.

Um, it's not "suddenly." The advice to do it right in the first place 
has been offered repeatedly, since the very beginning. That's why the 
code point was assigned in the first place.

There is no doubt that in the early days, prior to the widespread 
deployment of 3597, querying for SPF/99 could cause problems. But we're 
not in that world anymore. Thank DNSSEC and IPv6 for shaking things 
loose. There is currently no TECHNICAL reason that the change cannot be 
made NOW to query SPF/99 first. The only argument you (and others) have 
put forward so far is, "We have been using TXT, it works, so we want to 
keep using it." I understand why that course of action is attractive, 
but it's bad. And the right thing isn't hard to do.

>     The point is that it isn't just fine.  It does have operational
>     impacts, from potentially increased fragmentation/fallback to TCP to
>     increased complexity in TXT RR parsers that have to distinguish
>     between the myriad of crap that's residing at the zone apex TXT RR,
>     etc.  Of course, most of these negative impacts are hidden to the
>     folks who are putting the TXT RRs in the zone, so it's all good, right?
>
>      > Thus, I maintain that we take our licks on this one and just take
>     steps to ensure that nobody follows this path again.
>
>     And how do you propose that exactly, particularly given the
>     precedent set by SPFBIS?
>
>
> Someone else (Joe, I think) has already referred to other RFCs that talk
> about things like IAB advice about how [not] to put application data
> into the DNS.  Seems to me this is a perfectly good subject for another
> such project.  One may counter that by saying nobody will pay attention
> to such a document, but I submit that it's our primary mechanism for
> making sure mistakes aren't re-made, so that's the tool we have to use
> or not use.

But this mistake isn't carved in stone. It CAN be fixed. And the 
solution isn't difficult. Some minor changes are made to software, some 
docs are updated, and then time passes and the old way becomes obsolete.

> If we do the opposite and somehow compel SPFBIS to favour type 99 over
> TXT, then I still think we'll be shouting that to an audience that will
> think we're nuts and simply go about their business.

If that happens (and I personally don't think it will), it's not the 
IETF's problem. We don't (traditionally) write specs to accommodate the 
worst behavior we see in implementations. We write specs to describe how 
it should be done right, and do our best to support people who want to 
write software that does it right.

And I should emphasize again, "Mail::SPF (which is used by Spamassassin) 
checks for Type SPF first by default." So there is already a non-trivial 
implementation that is doing it right. The number of other 
implementations that need to be updated is not very large. Another case 
mentioned in the spfbis thread on "issue #9" was the python lib for spf, 
which already has the code to query SPF/99. It would be a 30 minute job 
to update that to query 99 first.

So if I'm missing some TECHNICAL reasons why this proposal isn't 
feasible, please enlighten me. But all I've seen so far is, "We don't 
want to do it," which I don't find particularly compelling.

Doug