No, my explanation doesn't show a major misunderstanding -- you simply
misunderstood what I was saying.
It does show a complete lake of experience in any kind of implementation
I'm describing how the entire *system* works, including DNS cachesRight, but if you have a server in production & a customer base you will not be using a 286/386. You aren't going to kill your pci bus with DNS.
(which are typically on a different system, connected via LAN) and
upstream DNS caches and servers (on different networks, connected via
WAN).
I am scared to ask how do you feal about running anti virus? Now that is a system work load. I am running f-prot on every email that gets past the spam stuff.
Being that I am processing 100k emails a day that takes a LOT of system resources. To the point that I limit incoming connections though iptables.
Compaired to anti-virus why would I care about DNS Lookup. & No I am not going to be DOS's because I have a perl script that monitors the incoming tcp 25 connections & if I start getting flooded from a /24 it drop the simo for just that /24 to 10. Till I time of X where I don't have that problem.
So this just MUST STOP. You can argue system resources all you want. But if you have the load you have the customers. If you have the cust then you can upgrade. It is that simple. & if you are in a LARGE production on a non-static ip. That tells me that you are to small to use a colo. Being that business is business I personally can't afford to have my customers down BC my DSL/Cable/T1 is out. If you can then you aren't in the same business I am. Which goes back to why this has to stop. You will understand if & when you go into production. If you don't have the resources to run SPF then don't. If you don't believe in SPF then good for you. If you don't trust DNS. Great, STOP using it. If you don't have a computer that can run what you want to do then either upgrade or what ever. One of the companies I work for provides 5MB of web space & email for $5. A month. With 200kb/s constant burstable 100Mb/s. If you don't have the resources @ hand then please get out of the game. We aren't the only ppl that offer it for that price. So pay the five bucks a month.
Sorry, to all But I really had to get that out.
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.
