spf-discuss
[Top] [All Lists]

Re: DNS Loading Comparison

2005-04-13 11:17:30
At 01:13 PM 4/13/2005 -0400, Todd Herr wrote:

On Wed, 13 Apr 2005, at 09:25, David MacQuigg wrote:

> Todd,
>
> Thanks for your very informative reply, and again, sorry for using rr.com
> as the hypothetical example.  You have one of the best setups I've seen for
> a large domain, so that is why I keep coming back to it.
>
> My scenarios below assume the perpetrator's objective is spamming, not
> DoS.  A DoS attack might be devilishly different.
>
> The one big departure from your current setup is my Scenario E2, which
> assumes you are using CSV, not SPF.  With CSV you must authorize each and
> every server with its own SRV record.  Hence, my assumption of 1000 unique
> DNS records filling the cache at each of 150,000 MTAs (including negative
> responses).  I have also assumed that a query for SRV records from a
> purported server like serv138.austin.rr.com would be handled by a slave at
> rr.com, or the number of queries would actually be even larger.

Okay, in your CSV example then, you'd have 100,000 domains
issuing 11,111,111.11 queries for non-existent records (we don't
publish SRV records) to each of our 18 authoritative servers
((2,000 zombies * 100,000 targets) / 18 authoritative servers) if
I read the CSV implementation bits correctly.  The DNS servers at
the 100,000 recipient domains would cache the NXDOMAIN answer for
however long they're configured to cache such answers, and would
provide subsequent answers to their local mail servers from their
caches, and the zombie attack would likely be over in short
order, given that any site requiring CSV would reject all email
from the zombies.

Let's call this scenario E2a, since we are moving beyond the original assumptions of E2. In E2a, rr.com does not publish SRV records for 1000 servers, but does have SPF records for each of 75 subdomains. We need to make some additional assumptions now, so I will define E2a1.

In E2a1, the queries all have valid third-level subdomains, like austin.rr.com. serv138.austin.rr.com is fake, but it takes two queries to find that out, one to rr.com, and another to austin.rr.com (actually more if we include the redirects and mx queries currently in the records). Assuming we still have 1000 unique fake names (scenario E2), then the number of queries and cached records for each MTA is 1075.

There are maybe a dozen or more interesting scenarios we could discuss. Let's be real careful not to mix assumptions between them. I'll keep an up-to-date outline at http://purl.net/net/macquigg/email - Spam Scenarios.htm.

--
Dave
************************************************************     *
* David MacQuigg, PhD      email:  dmquigg-spf at yahoo.com      *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                   9320 East Mikelyn Lane     * * *
* VRS Consulting, P.C.              Tucson, Arizona 85710        *
************************************************************ *


<Prev in Thread] Current Thread [Next in Thread>