Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE

[Mark Andrews <[e-mail]>]

In message <CAL0qLwYzKnfRArQAVD1M=[e-mail]>, "Murray S. Kucherawy" writes:
> 
> On Thu, Apr 25, 2013 at 4:28 PM, Doug Barton <[e-mail]> wrote:
> 
> > Yep, been there, done that. It was a bad decision then, and it's still a
> > bad decision now. I realize that it's incredibly unpopular to bluntly call
> > bad decisions "bad decisions," but not doing so doesn't make them any less
> > bad. And, to make matters worse, not doing so has led to a non-trivial
> > number of those bad decisions becoming de facto standards. This has at
> > least 2 very bad side effects ... first, we have to live with the bad de
> > facto standards; but more importantly we are providing encouragement to
> > people who wish to make similar bad decisions down the road.
> >
> > The argument in 6686 boils down to, "We made a series of bad decisions,
> > which have led to a bad result. We now want to codify that bad result
> > instead of cleaning up our mess." I don't agree with that in principle, and
> > I don't agree with that in regards to this particular case.
> >
> > Further, while cleaning up the SPF mess would require nothing more than a
> > marginal amount of extra work now, plus the passage of time, there is no
> > reason not to actually clean up the mess.
> 
> 
> I think this continues to trivialize exactly what it means to migrate the
> enormous deployed base of SPF in the manner you're pushing. I fully agree
> with your premise that it should've been "done right" in the beginning and
> I lament that it was not, but I don't agree that fixing this now is worth
> moving a mountain, especially when I don't believe the people saying that
> here will be among the people doing even a fraction of the moving.

The installed base of SPF is miniscule.  As for moving it, you
really only need to update a couple MTA's to use the SPF libraries
that look for SPF first and let time pass.

If you want a hurry on one could add code to nameservers and zone
signers to detected TXT style spf records and add SPF records if
they are missing.

> At least half of the reason we landed here is because of an environment
> that was basically hostile to doing it right in the first place.  The rules
> for getting new RRtypes have been improved --

The rules were dead simple at the time, just nobody in the SPF camp
was willing to try to go down that route.  I know they were simple
because I used them at the time for another type.

> I think we all agree on that
> -- but, as you already conceded, there's still a large deployed base of
> faulty firewalls and DNS tools out there that don't exactly make use of
> uncommon RRtypes easy.  So how much energy are the DNS experts going to put
> into cleaning up their house while demanding the mail people clean up
> theirs?  I would even go so far as to say that the DNS part has to happen
> first, before any cleanup on the email side is practical to consider.

The DNS had deployed support for UNKNOWN RR types at the time.  Most
resolvers have been able to lookup unknown types since RFC 1034 was
published.  For most resolvers it was simply a matter of using 99
rather than a symbolic name.

> The deployed SPF base probably won't give a damn if the IETF suddenly
> releases an RFC that exclaims "Everybody migrate to type 99!"  From the
> perspective of large and small operators around the world, what's out there
> is working now, and messing with it is asking for pain; engineers' time to
> switch and debug costs a lot of money, so they have no incentive whatsoever
> to comply with a proposed change to "fix" a service that is philosophically
> broken but operationally just fine.
> 
> Thus, I maintain that we take our licks on this one and just take steps to
> ensure that nobody follows this path again.
> 
> -MSK
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]