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 2:43 PM
Subject: Re: [spf-discuss] Re: DNS lookup limit?


> Hi Nico,
>
> Nico Kadel-Garcia wrote:
> > >   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.
> Your assessment is largely correct for normal conditions. I should have 
> defined maximum load:
> The maximum load is that which under the worst case conditions can be 
> sustained due to input stimulus characteristics.
OK, this makes more sense. I suspect that any site pulling this would get 
noticed and slapped down pretty fast, but yeah, there's a potential 
manipulation of DNS structures and tables not previously done under SMTP but 
are done under SPF that could cause a DOS attack against the SMTP servers. 
Got it.

> Suppose the mailer receives an attack from the following worm routine:
>
> function attack(target)
>
>     for (i = 0 to 1,000,000)
>        sendmail(FROM: "hell" @ "a" i .iburnu.com"
>        TO:{(_dot_)(_dot_)(_dot_)(_at_)target})
>     end for
>
> end function
>
> suppose that the DNS of the attacker is organized like this:
>
> ouch.iburnu.com TXT "v=spf1 {expensive recursive lookup with many
> timeouts} -all"
>
> a0.iburnu.com TXT "v=spf1 redirect=ouch.%{2d}"
> a1.iburnu.com TXT "v=spf1 redirect=ouch.%{2d}"
> ...
> a1000000.iburnu.com TXT "v=spf1 redirect=ouch.%{2d}"
>
>
> For such an attack, the machine at the receiving end, which
> accepts up to say 100 concurent connections will have much memory
> tied up waiting for the recursive lookups with timeouts. Perhaps
> it will even start thrashing the swap space.
>
> If its resolver timeout is set to 2 seconds, it will be tied up
> about 222 seconds for each of the 1,000,000 mails the attack
> sends. Even with the fastest solid state disks, and fast CPU's
> the limit is still the amount of memory available in that
> machine. So the ouch.iburnu.com TXT will be in the cache, but
> does that help at all?
Yeah, I see it. Add to the brew that few systems can handle more than 1024 
simultaneous incoming TCP connections, and you have all sorts of potential 
issues.
> In this case, the a0,... a100000 will not even be blacklisted,
> since they all end with TempError. The maximum load is largely
> a memory load, not a disk or CPU load.
Hmm. That's where you wind up relying on the RBL style blacklists, to reduce 
the connection attempts from sites that might try to pull this kind of 
nonsense, but I see your point.
> You noticed correctly, both the mail and the DNS infrastructure
> will be upgraded to deal with this scenario.
Well, I think that the reduction of load from blocking email worms and 
forged spam will easily be preserved to handle this kind of abuse.
> I should mentioned that I'm not an expert in terror techniques,
> but I'm sure that an even more evil worm can be thought up, which
> neither requires many resources from the attacker, nor makes it
> easy to trace the attack back to an individual. I'm sad to say,
> but this is the awful truth of our internet.
Oh I wouldn't call it a terror attack. It need not have the political 
element necessary to a terror attack. It's vandalism.