On Tue, 2006-11-14 at 12:03 -0600, wayne wrote: > Anyway, as WilliamL said, there are a lot of assumptions in the SPF > DoS scenario that Doug presented that are, uh, "unlikely". I analyzed > the same attack that was presented at IETF67 back in early 2004, along > with about a half dozen others. I still believe that SPF is > relatively safe and the chances that anyone could regularly pull off > such a DoS attack are about the same as the chances of anyone > regularly winning the lottery.
Nothing suggests "chance" is involved with an attack enabled by SPF scripts. The example attack requires little knowledge of the victim. Using SPF to include local-part email-addresses in queries to an attacker's DNS permits canvassing when efficiency is desired. However, little of an attacker's resources are consumed when the repeat interval is not optimized. > There are some DNS operation issues that may be useful to consider for > SPF DoS attacks or the NS record DoS attack that William talked about. > > In both cases, there is a requirement that the nTTL of the victim's > zone be much much shorter than the TTL of the attacker's records. > Fairly obvious ways to stunt any attack that is in progress include > updating the victim's SOA record so that the nTTL is much longer, > publishing a wildcard record so that the victim's TTL is used, or > delegate the part of the victim's zone that is being attacked to a > very slow name server. Extending negative caching may not be controlled by the victim and could create problems during transitions. Many wrongly suggest turning off negative caching to avoid support issues. Even with the level of amplification reduced, the source of this attack remains hidden and can continue without recourse. > More general solutions are to make sure that all protocols that use > DNS records that allow for indirection (NS, MX, SPF, SRV, etc.) to > limit the number of records that they process. As William mentioned, > I put a limit of 10 in the SPF RFC. This may really be a DNSEXT > issue, I'm not certain. The limit of 10 is with respect to a "mechanism" where 10 is also suggested as a maximum number of host names resolved from the MX record transaction. Reducing the number of host names resolved creates intermittent problems when there are more published without truncation, but are ignored anyway by the script. > One suggestion, brought up by another person on the SPF lists, was that > SPF should also have a limit on the total number of "broken" indirects > before giving up. A small limit of 2 or 3 would completely defeat all > the SPF DoS scenarios that I know of. When will SPF routines be updated? Forcing this change requires modifying the version of the SPF record. There is still wildcard SPF RRs that can be randomized using local-part address macros. SPF still chains through 11 such resource records where this attack can be further amplified by the tricks suggested by William. Keep in mind these attacks are still free for the attacker, and are not a matter of chance. -Doug . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
