spf-discuss
[Top] [All Lists]

Re: Re: DNS load research

2005-03-23 11:02:13


Michael Hammer wrote:
I wouldn't worry about the network latency issue specifically for SPF.
If there is that much of a problem generally (For whatever reason)
people will have much bigger fish to fry than SPF DNS lookups.
Remember, mail is an asymetrical transaction from the user point of
view.

Other aspects of latency might be of interest but are you really going
to go around telling people "improve your DNS server because my MTA is
slowing down waiting on you to return results"? I would simply focus
on the relative costs of different types of records/lookups and leave
it at that. As an old man in the corner I'd rather be approximately
right than absolutely wrong.

Since it's an academic exercise :) I would look at all the involved variables and only discard some after they prove to have a negligible effect on the final result. That's how academia works. ;)

Besides, it would be network latency, and thre's nothing the DNS server can do to lower it. The only solution is to sprinkle your NS servers around the world so there's always one close by.




<snip>
The other problem with the DDOS attack I described earlier is that when
the internet is congested with something or other, say with the next
version of MyDoom, the likelyhood of UDP packets dropped will be much
higher than normal, so as MyDoom v2 is trying to spread from mail server
to mail server, the recipient MTAs will see more timeouts because some
UDP packets are dropped.

The more queries we allow, the more likely it is that the MTA will time
out while receiving the MyDoom virus.

So, not only are the recipients MTA have much more mail to recieve, but
they spend more time on each message because of the DNS timeouts.
Meanwhile, the sending MTA's can't get the virus out fast enough, so
they queue, and queue and queue.


Well, why would I care if an MTA sending the virus can't get the virus
out? That would be a good thing <G>.

:) Right. But the good mail gets backed up in the queue too, and that is not a Good Thing ;)

Besides, the next version might quote text found in the mailbox, or even in mailing list archives on the internet, and make up legitimate looking emails of variable length, so it won't be so easy to filter out of the outgoing/incoming mail queue.


I remember that last time, we dealt with the first wave of MyDoom by
getting the MTA's to temporarily reject messages around a certain size.

The next time it happens, we'll do that again (I think we the earthlings
are very resistant to learning, but that's a runt for another list).
Also you bet that SPF checking will be disabled for a day. And since it
will be (rightfully) perceived to have exacerbated the problem greatly,
it will take some time before it will be turned back on, if the
confidence in it ever comes back. And confidence will be hard to regain,
unless something is fixed about it.


So basically, if you want to get your spam through using forgery,
trash DNS lookups so that people will turn off SPF? It doesn't matter
what limits I set for lookups in this case. If the lookup fails and I
SPF fail the inbound connection does it matter whether I am trying to
do 1 lookup, 5 lookups or 100 lookups? Fail is fail regardless. It's
the nature of the beast.

In the case of the virus, it might be an indiscriminate forging of addresses, though it might be a more evil virus that only picks on domains with big SPF records. So not only do MTA's everywhere do SPF checks, but also the virus will do SPF checks while looking for expensive ones. And there are a lot more client machines on the net than there are MTA machines. So way more sources of DNS queries.

Last time we had a significant virus, the whole internet slowed down. Now the virus would have even more leverage, if it was an SPF virus.

I hope that you virus writers out there don't get any ideas, because I have a baseball bat your your name on it.

In the context of the virus, the other important thing to realize is that never before have we made it so easy to find the hostnames under a domain name. The megapathdsl record lists ten hosts within their domain.

DNS servers disable listing a domain's hosts on purpose, because it's a security hazard. It is a security hazard because if someone scans all the hosts found with "A" lookups, the DNS server cannot ignore them, it has to respond. This is double the traffic compared to queries for inexistent domains, which could be dropped.

But SPF practically undoes that security feature (DNS denying listing). It also adds powerful macros.

It looks like a nightmare, but it's gotta be an interesting problem to
look into for a network engineer.

Isn't the internet a "self healing" network? <G>

:) Oh, it will survive and get stronger. but in the meanwhile I think it will experience 'the plague'. I don't wish to imply that SPF is a plague, far from it, it's very useful, but it does have some serious problem that most people are happy to overlook, in the hopes that when we have to deal with them. Hope is not a method! ;)

The question to ask is whether the risk is specific to SPF or is it a
general risk that can be related to SPF. If the former than time
should be spent examining it in detail. If the latter then it should

In the case of a virus, the risk is related to SPF. But without SPF it would not have been possible. So, doesn't that put the risk squarely on SPF's shoulders? SPF is just leverage in the virus case.

I'm sure that old man in the corner is reading this and thinking,
"You're right, Sunny, I told them that we should add authentication when
we invented SMTP, but they said - Ahh... SMTP will never be abused, it's
too cool of a protocol for that!"


Well, I said we really needed SSMTP ( Smoke Signal Mail Transport
Protocol) but they said that went out with Custer.

LOL :)

As usual, just my 2 cents.

They are much appreciated.

Thanks,
Radu.


<Prev in Thread] Current Thread [Next in Thread>