Re: Re: DNS lookup limit?

----- Original Message ----- 
From: "Radu Hociung" <radu(_at_)ohmi(_dot_)org>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Sunday, February 27, 2005 12:35 PM
Subject: Re: [spf-discuss] Re: DNS lookup limit?


> Frank Ellermann wrote:
> > Each mx / ptr / %p has its own limit of 10 MXs or 10 PTRs,
> > also a MUST.  If you _add_ all MX queries for different
> > mx mechanisms, you get completely different results.
> That is correct. Let's call the real limit of spf-classic-00
> *DoS limit*. For all practical purposes, it currently stands at 111.
> That's what the worst case SPF will cost: 111. I would think that
> as the SPF evaluation approaches 111 lookups, the probability of
> a PermError increases, so chances are good that 111 lookups will
> have been a waste of time and resources. This is why this limit
> is called a DoS limit.
>
> I'm going to look a little bit into the two limits I believe to
> be needed: the *DoS* limit, and the *reliability* limit.
>
> *About the DoS limit*
>
>   The large domains probably employ mail servers that have a
>   calculated load of around 50% resource utilization (a guess).
>   (I'm thinking of those with tens of primary MX's). As it is
>   now, those servers probably do about 3 DNS lookups for every
>   incoming email, give or take a couple of lookups: - A lookup on
>   the sender domain, to find fake domains - PTR lookup to see if
>   the IP is at least likely to be a legitimate mail sernder. - a
>   lookup to a RBL or something similar
>
>
>   If implementing SPF would require them to observe a 3700%
>   increase in maximum load of those machines, that would be a
What? Where are you getting this number? The DNS lookups is one of the 
lightest weight parts of the whole SMTP transaction. While the SPF lookup 
and processing are a real load, one can reasonably expect much of the DNS 
lookup space to be already cached locally. The bandwidth load of actually 
receiving and transmitting the message, and the CPU and disk loads of 
managing the received messages and delivering them, is far, far larger. 
Those dominate that "50% load", not the DNS transactions.
Some sites may have to increase their DNS capability to support the 
additional requests, but the DNS lookups will be mostly cached, and getting 
out from under some part of the email worm load, especially email worms 
allegedly sent from their own domain, will thoroughly justify the transfer 
of resources from mail server capacity to DNS server capacity.
And it gets better. If significant numbers of domains implement "-all" SPF 
records, we can expect to be able to drop all forged mail from those domains 
in the bitbucket at the early connect phase, before we've accepted the 
message and have to process it. Even if the only domain with "-all" records 
is the SMTP servers own domain, the drop in email worm traffic and having to 
process it more than pays for itself in reducing the load on the server.
>   major headache. In order to deliver the _same mail volume_,
>   they would need to grow their front-end infrastructure 37x.
>   This is because they would have to ensure the same level of
>   delivery even during a sustained DoS attack. Also this means
>   that on an average day without a major DoS attack, their mail
>   machines would run at 50%/37, or about a 1.35% utilization.
>   From a financial investment point of view this is likely not a
>   good value proposition.
See above. You've compared adding a triple tax  of a very tiny tax to 
tripling the price of the item sold, and it's not the same thing at all.