[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Radu
Sent: Wednesday, March 23, 2005 1:02 PM
Subject: Re: [spf-discuss] Re: DNS load research
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
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.
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.
But checks of these expensive records couldn't cause more traffic than the
DNS servers that hosted the expensive records could put out. I can see
where, in theory, a hostile entity could find a variety of expensive records
and DDOS an individual site trying to swallow them all, but the attack
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.
Please don't say SPF virus. I don't think you've described any such thing.
If these records are so expensive, the serving DNS won't be able to send
them and the global congestion won't happen.
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.
Actually, it doesn't anymore. They are pretty responsive.
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.
I would put it differently, depending on how an SPF record is constructed,
it may disclose host names that were previously unavailable. So, domain
owners may choose to construct SPF records that disclose this information,
but SPF doesn't force them to.
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! ;)
Or perhaps not overlook, but came to a different conclusion than you. DNS
load, DDoS, and security have been regular topics of discussion for the year
I've been on this list. I think it's something we need to watch, but not
the potential disaster that you forsee.
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.
If the virus writer has access to enough zombied machines to do this DDoS
attack, there are other ways to do it too. I don't think SPF makes DDoS
significantly easier than it was before. That said, this discussion of how
to make it more effecient and reduce the risk is a good thing, but I don't
think the world is going to end if we change nothing.