>On 3 Jun 2004, at 21:27, James Craig Burley wrote: > >> A spammer uses a large number of zombie machines to inject emails into >> your system. Each email is forged such that your system has to >> continuously perform SPF lookups for nonexistent or irrelevant domain >> names. The spammer thus attacks your DNS cache and/or lookup >> latencies. > >This shows a major misunderstanding of how the process works. A DNS >lookup is practically zero cost. You fire off a query and then you wait >until the response comes back. Meanwhile your processor can do other >things - it's not doing anything during that "wait".
No, my explanation doesn't show a major misunderstanding -- you simply misunderstood what I was saying. I'm describing how the entire *system* works, including DNS caches (which are typically on a different system, connected via LAN) and upstream DNS caches and servers (on different networks, connected via WAN). It's kinda like I was describing the pitfalls of designing a number-crunching program around an algorithm that might require too large a working-set size to fit in L1 or L2 caches of typical workstations, and you chime in with "you don't understand, a memory fetch is practically zero cost -- the CPU fires off a query and then it waits until the response comes back; meanwhile, the CPU can do other things". That's not the point; it's the *overall* cost of having to fire off the query, and wait for it, not only to the system doing the query, but to the upstream cache(s) and memories that have to fulfill those requests. Going back to my earlier questions, which I'll rephrase and ask you: Does DNS rely on local caching to avoid latencies related to network topology and potential problems with overloaded or unreachable Root servers? Does the local caching rely on locality of reference over the set of lookups performed? Are SPF-based DNS lookups under the control of a local user population, or of external, potentially hostile, entities? Are SPF-based DNS lookups likely to exhibit sufficient locality of reference? During this entire discussion, nobody has yet provided a definitive answer contradicting *my* answers to these questions, which are: Yes. Yes. Under the control of external entities. No. Instead, there's been substantial hand-waving about how the problems I see just won't be problems after all. They will. Spammers will exploit SPF once they determine that they will have better results by attacking SPF-dependent systems than by simply focusing on other systems -- a "tipping point" for SPF, if you will -- and their attacks won't have to be "ordinary" dDOS attacks, since all they have to do is convince sysadmins that, to continue receiving incoming email, they need only disable SPF. >From a logistical and tactical point of view, SPF is an overreaction to an arbitrary external stimulus. Therefore it can be exploited by an attacker, as can any such predictable overreaction. (As an aside, I imagine this is why some animals, such as rabbits and some goats, are genetically programmed to go dormant or unconscious under stress, such as during an attack: while the odds of this response leading to the animal being caught and killed may be higher than if they employed a fight or flight response, the dormancy response has the advantage of consuming far less energy and being, for a typical predator, quite unpredictable.) And since it is a defensive component, likely to be used in lieu of other more practical defenses (in isolation or overall), an attacker has plenty of incentive to tailor his attack such that it overcomes SPF without destroying the attacker's true target -- in this case, the users to whom the attacker wants to successfully send his spam. That makes dDOS attacks targeting SPF much more likely, and more useful to spammers, than ordinary dDOS attacks. >Now there is a minor issue with the design of qpsmtpd in that it forks, >so there is a potential for too many processes running, causing load >averages to rise, but that's a rather major DOS attack occurring just >to achieve that situation, and it exists in almost every major SMTP >server that's doing any kind of lookups. I'm not concerned with qpsmtpd per se. Here's what it comes down to: say that, in a couple of years, you have become substantially dependent upon SPF to "vet" all incoming emails, however you're doing that. Your system comes under a modest form of dDOS attack that triggers so many SPF lookups that you can no longer process legitimate incoming email, or in some cases distinguish it (non-forged email) from forged email. Do you disable your incoming email entirely? Or do you disable just your SPF lookups? SPF allows attackers to force you to make that choice. (Traditional dDOS or DOS attacks generally just try to disable your entire *system*. Spammers have little or no interest in doing that; they don't profit from it.) Regardless of how spammers behave *now*, by the time SPF is rolled out sufficiently to be useful in the anti-UBM wars (and it certainly is *not* a sufficiently precise guide to whether an email has been forged to do much else), they will long since have adapted, coming up with new strategies and tactics in order to target and eliminate its usefulness. -- James Craig Burley Software Craftsperson <http://www.jcb-sc.com>
