From: Commerco WebMaster
Date: Tue Mar 22 2005 - 15:42:19 EST
I suggested a while back on the list that a trusted registry of SPF domain
adopters may be in order to solve some problems that I could envision
happening back then.
In this case, I think we could even avert some of Radu's and David's DNS
access concerns with such a registry because the registry itself could
serve as a caching center for first SPF requests as well as offer an
indication of the conditions an SPF checker could expect to encounter.
I like to think about far-out ideas like this. Even though there is little
chance they will be implemented, it helps to put in perspective what we are
trying to do with SPF on DNS. If SPF fails because of these DDoS tactics
(and I don't think it will), but if that were to happen, I can imagine
setting up a fast-response, widely-distributed registry, like you are
suggesting. Google would be happy to show us how, no doubt.
The reason I don't think it will come to this is I believe the SPF concept
is fundamentally strong, and the current implementation can be patched to
handle the DDoS problems we anticipate. Ultimately, it comes down to
making sure the receiver spends less than the sender in each failed attempt
to send spam. At that point, the scales tip the other way, and the
economic incentive for spam is gone.
It seems like that minimum cost for the sender is initiating a TCP
connection and an SMTP session. So far, the costs for sender and receiver
are even. Next, the receiver must do an SPF check on the sender. This is
where the sender has an advantage in the current setup. So let's think
about how we reduce that step to the absolute minimum.
What are we trying to do? We have an IP address and a domain name. We
need to verify that the name authorizes the IP, and we need to do it in the
fastest, most reliable, and least costly way possible. As impressive as
Google is, I think this rules out http. Even setting up a TCP connection
is too much overhead.
We need a database (registry?) that will respond quickly to a single packet
from the sender. That database needs to be widely distributed, with every
little domain having authority to make changes at its leaf in the domain
tree. It needs to be reasonably secure and very robust, with confidence
built over years of large-scale deployment. It needs a caching mechanism,
so repetitive queries can be answered without going all the way to the
original records each time. Does it sound like I'm describing something
that already exists? We just can't beat DNS for providing the underlying
machinery we need for the proposed "registry".
What I would like to see is the SPF community giving more thought to the
next move in this global chess game. What do we do if (heaven forbid) some
of these worries about DDoS attacks come true? Are we going to rush for a
last-minute patch, or will we have a plan in place that will ensure
ultimate victory at a reasonable cost? Are there any steps we need to take
now to avoid great cost later? Will switching to pre-compiled SPF records
be a simple upgrade with a smooth "migration" from the existing
system? Will that get us close enough to the ideal low-cost SPF check, or
will we need a little more help on the sender's side, providing an
immediate PASS/FAIL instead of a pile of IP addresses? Is there any
fundamental advantage to an extra layer (a registry?) on top of SPF?
-- Dave
************************************************************* *
* David MacQuigg, PhD * email: dmq'at'gci-net.com * *
* IC Design Engineer * phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* * 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. * Tucson, Arizona 85710 *
************************************************************* *