>James Craig Burley wrote:
>> (At least, I wouldn't describe DNS as "decentralized"; it's more like
>> a distributed data base with some degree of local control over
>> portions of the data base that provide local information to all users
>> of the data base.)
>
>Except that DNS _is_ decentralized in the very real sense that proper
>use of caching means that queries to authoritative servers will be
>vastly outnumbered by resolvers answering from their local cache. DNS
>is also decentralized in that anyone can decide to have as many
>authoritative servers as seems appropriate for their own traffic.
Do the local caches depend on locality of reference to achieve high
hit rates?
If so, can you be *sure* that all SPF lookups for incoming emails will
exhibit sufficient locality of reference to ensure those hit rates
remain high?
If not, can you be *sure* that latencies resulting from cache misses
will not, due to overloaded upstream DNS servers, result in email
deliveries being delayed or even failing due to persistent delays?
If not, what prevents spammers from targeting this weakness with an
attack that culminates in a victim site disabling SPF, just as they've
attacked system(s) offering C/R for popular mailhosting sites (like
hotmail.com)?
>> Instead, the problem occurs when an incoming email requires an SPF
>> (DNS) lookup for a *remote* site.
>
>I don't know about your setup, but in my configuration I am performing
>multiple DNS lookups for each and every e-mail that hits my port. Even
>if you aren't using blacklists or other DNS-based measures, every
>connection to port 25 on your server should trigger the single DNS
>lookup (peer IP address to name).
Nope. No need to do rDNS lookups to accept incoming emails. Since I
turned that (and IDENT) off, incoming bounces of joe jobs from, e.g.,
aol.com typically take less than one second from start to end of SMTP
connection. (AOL should love me for that, but they don't, since I'm
on a DUL; sheesh, they send me far more spurious bounces than I send
them emails of *any* type!! ;-/ )
My understanding is that DNS is designed to accommodate *outgoing*
lookups via its caches, the idea being that a given user population is
interested in a sufficiently localized region of the name space such
that local caching has utility.
As DNS is exploited to deal with *incoming* lookups -- all incoming
connections of a given type requiring lookups based on arbitrary data
provided by the (untrusted) clients on the other ends of those
connections -- the ability of local caches to cope will be reduced.
With rDNS lookups, the damage is limited due to the limited name space
of IP addresses.
With domain-name-based lookups for incoming connections ("reverse
lookups" in a real sense just like with rDNS, but based on arbitrary
domain names), there is no straightforward way to limit the damage,
since there is no useful limit on the size of that name space.
>> At that point, the fact that DNS is ultimately centralized and must be
>> queried in a manner that provides some degree of trustworthiness for
>> the resulting data implies a potentially fatal bottleneck for email
>> deliveries involving SPF (or DomainKeys) lookups.
>
>And here, you've completely lost me. _I_ control all DNS lookups for my
>domains, using the well established trust relationship between Root
>servers, TLD servers, and my directly controlled servers. If I choose
>to provide SPF records for my domains (check 'em out), they are just as
>trustworthy as my A or MX records.
Yes, that's true. So, assuming someone trusts every connection
between Root and your particular place in the heirarchy, they can
trust you and your SPF records.
But if they don't trust *any* connection in that chain, they must
*not* trust you or your SPF records.
That implies one cannot necessarily trust that an SPF lookup of an
arbitrary domain name is sufficient to accept that the results of the
lookup are useful.
Instead, one must determine the trustworthiness of each higher-level
domain name.
(That is, one cannot trust the SPF records for a.b.c.d.e if one cannot
trust c.d.e to publish proper and trustworthy DNS info for itself.)
>No one can forge an SPF record for
>my domains (short of a compromised caching server, which only affects
>people using that cache).
No, but they can forge SPF records for *arbitrary* domains that they
are able to control by having even a thin wedge of attack on any
"legit" domain be successful for a sufficiently long amount of time.
Put another way: are you sure you will be able to trust *all* SPF
records published in the .cn domain? The .ru domain? The .biz
domain?
Yet another way to view it: SPF, being dependent on domain *names*
rather than IPv4 *addresses*, is ultimately going to boil down to the
same sort of trust issues that IP-based black/white listing
involves...
...except, instead of a name space of less than 4 billion, domain
names have a name space that is, essentially, *infinite*.
Since one simply cannot cache any useful percentage of infinity, there
will need to be other ways to stop spammers from blowing out caches by
attacking SPF (or DomainKeys), as they have C/R and similar
heavyweight anti-UBM measures, by simply swamping victims of their
attacks with lots of slightly different emails.
You should be aware that I have made these arguments before, on other
forums, and have not gotten sufficiently clear responses to cause me
to withdraw my concerns.
However, that could be due to knowledgeable people simply not knowing
how (or caring) to understand or explain to me some fundamental
misunderstanding I might have about DNS or the Internet as a whole.
(That's happened to me before; a long time ago, I couldn't quite
understand or explain to an truly brilliant "geezer tech type" what
was wrong with his concerns about a technical design I was
proposing...until years later, when I finally realized what comprised
his fundamental misunderstanding of the underlying technologies, and
was able to point it out to him...sadly, too late to matter. So I
could be in *his* shoes *now*.)
Still, it worries me that when I point out these concerns, nobody
seems to be able to say "here's how DNS cache misses won't become a
problem in the face of an attack of this sort...".
I'm afraid it'll just be more effort put into fairly useless, if not
actually dangerous to "our side", weaponry in this arms race.
--
James Craig Burley
Software Craftsperson
<http://www.jcb-sc.com>
