If it turns out that SPF adoption leads to significant network harm,
then it would be possible to tweak it or replace it with
something more effective, with narrower scope, in particular CSV.
This is a valuable discussion.
Caller-Id required a single packet in each direction for the vase
majority of mail interactions.
Furthermore this data is cachable.
Based on an estimate of about 10 million active email domains
we have worst case a problem that is orders of magnitude less than
distributing alt.binaries over a flood fill routing algorithm
like NNTP.
Let's flesh out more your attack scenario, so we can be
proactive about this.
No, lets consign it to the bit bucket where it belongs. The
argument is nothing more than big numbers are scary.
Many MTAs are already performing multiple DNS queries per
email connection without significant impact on net performance,
the only threat here comes from the spam.
I could see SPF causing some free DNS providers to go belly
up.
I don't see how.
It seems that traditional BLs were near the tipping point- concerted
DDoS attacks brought down some BLs, but were unable to take down
others.
There is no issue here, a DDoS attack against WHAT?
Sure DDoS attacks against DNS happen. But what is the scenario being
suggested here? A DDoS attack against who?
Worst case is that the spammer takes out the DNS server of alice.com
and then sends impersonation spam from alice.com. Its hardly convincing,
bob.com can see that alice.com is unavailable so the forged messages
from the spammer get treated as suspect.
Sure its bad that alice.com can't send mail when there is a DDos
on its dns. So what? DDoS extortion is already a problem, alice.com
is probably a bit more worried about the web site being out of service
during this period than the fact that the email is being queued.
There is a real DDoS against DNS issue, this attack does not make it
any worse. If the problem is serious it should be addressed in its own
right.
It isa quite easy to deal with for MARID, just keep the last valid result
from any site irrespective of the cache status and reuse that in the case of
a system being unavailable.