Response to DDoS using SPF

> > > The question to ask is whether the risk is specific to SPF or is it a
> > > general risk that can be related to SPF. If the former than time
> > > should be spent examining it in detail. If the latter then it should
> >
> > In the case of a virus, the risk is related to SPF. But without SPF it
> > would not have been possible. So, doesn't that put the risk squarely on
> > SPF's shoulders? SPF is just leverage in the virus case.
> >
> If the virus writer has access to enough zombied machines to do this DDoS
> attack, there are other ways to do it too.  I don't think SPF makes DDoS
> significantly easier than it was before.
The key issue is whether there is incentive to abuse SPF, even it is not 
the best way to generate DDoS attacks.
> That said, this discussion of how
> to make it more effecient and reduce the risk is a good thing, but I don't
> think the world is going to end if we change nothing.
The world won't end, but SPF might.  If it gets a bad reputation from some 
incident, and an alternative is being pushed by a well-oiled competitor, 
even one that is technically inferior, the decisions may well be in the 
hands of politicians by then.
I agree, continued discussion of what we should do is a good thing.  Let's 
assume, for just this one thread, that a DDoS attack will occur, and that 
costly SPF traffic will be a key part of it.  What are our possible 
responses?  What changes in current technology will be required?  Does it 
make sense to implement any of those changes now, even though they might 
not be needed until a year from now.
The responses I've seen suggested so far include:
1) Use of pre-compiled SPF records to avoid recursive lookups.
2) Responding to an authentication query with an immediate Pass or Fail, no 
lookups at all.
3) ???

The changes could include:
1) Running a daemon on DNS servers that would, maybe once per hour, 
re-compile the SPF record for the entire domain.
2) Adding an IP address to authentication queries, allowing *all* SPF 
processing to be done by the sender's domain.
3) ???

Whether any of these changes should be done now, depends on how difficult 
it is to implement a change.  I would like to see some discussion on that.
Whatever changes we make, they should be presented not as "Oops, we made a 
mistake." but rather, "Here is the next upgrade, just for those that need 
it.  If you are not sure you need it, don't worry, it will be easy to add 
later."  I think SPF is past the point where to get it accepted, absolutely 
nothing can be changed in the DNS servers.
-- Dave

*************************************************************     *
* David MacQuigg, PhD              * email:  dmq'at'gci-net.com   *  *
* IC Design Engineer               * phone:  USA 520-721-4583  *  *  *
* Analog Design Methodologies                                  *  *  *
*                                  * 9320 East Mikelyn Lane     * * *
* VRS Consulting, P.C.             * Tucson, Arizona 85710        *
*************************************************************     *