On Tue, 22 Mar 2005 22:45:57 -0500, Radu Hociung <radu(_at_)ohmi(_dot_)org>
wrote:
For the latencies item, a record that points to 4 A records that are
served by a NS server on a cable modem would be more expensive than a
record with 4 A records hosted on an OC-48 line. It gets worse if the
records are under a different TLD, as the recursive lookups to find that
countries root servers would take longer, and the lookups to the NS
itself would take longer too, because with a distant geographical
location come multiple router hops and thus delays. Also, the further a
NS is, the more likely it becomes that some queries will time out.
Remeber that UDP is connectionless, send-and-forget, and when the packet
has to go through more networks, it has more opportunities to be dropped
because of congestion.
The _relative_ nature of this cost figure would mean that it can be used
to compare two SPF records, but that the figures would only make sense
if used at the same location.
Indeed, an SPF record in Canada might be cheaper than one in Hungary to
a host in the US, to a host in Poland, the Canadian SPF record would be
more expensive than the Hungarian one.
Indeed at different times of day different records will have different
costs, as the network adapts and re-routes in order to balance the load.
I can only imagine the magic that is going on as the different
time-zones start and end the work-days. For instance, Monday at 9AM, the
network between Florida and New York must be pretty busy, so the
backbone may find a cheaper route for some packets through San
Francisco, where it is 6AM, and most email-checking, internet-browsing
employees are still sleeping.
It's a more difficult problem than it appears.
I don't know exactly what the application for this would be, but I'm
willing to bet that whoever works on this problem will gain a great
amount of knowledge about how The Network operates.
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.
<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>.
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.
I don't know if there is a blow-up point, or congestion level at which
the congestion grows exponentially, but I think it can get ugly, and it
may be that the mail queues around the world will take a while to clear up.
Again, if it gets that ugly SPF will be an issue low down the priority
list. I think it was in 1996 or 1997 (first year it was ISPCON instead
of BBSCON) that ISPCON was held in San Francisco at the Hilton. MS was
providing connectivity and they had DNS problems. At the same time
there was the west coast blackout. It was kind of funny (in an ironic
sense) watching many of the attendees going.....hmmm, what was the IP
of <insert critical device name here>. Since seeing that, I memorize
critical device IP addresses and use those rather than names.
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>
I realize that I'm a little of a FUD salesman here, but it appears that
we're not giving the risk enough of a thought yet.
So far, I think SPF is at the risk phase. I don't want it to get to the
problem phase. In my engineering experience I learnt that the further
you allow a problem to propagate the more expensive it will be to fix,
and the cost increases exponentially.
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
be noted and considered part of the environment we have to live with
and work in. If you don't want DNS problems then don't use DNS. On the
other hand, memorizing all those IP addresses (especially IPv6) is
going to be a little tough.
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.
As usual, just my 2 cents.
Mike