Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits

From: Arthur Thisell <[email-masked]>
Date: Tue, 6 Mar 2012 11:32:46 -0800 (PST)

> Be warned that "It hasn't happened yet" may not be a sufficient
> discussion.

This is true, Doug Otis promoting this attack for many years and yet nothing has happened.  This gives evidence that the threat of recursive nature of SPF evaluations causing the local recursive resolver to send too many queries to unrelated third parties may not be that useful.   Indeed, I have analyzed Doug's reports in the past and I found they miss a huge amount of work that the attacker has to do, thus greatly reducing the real amplification factor.

Recursion can be a problem, but notice that DNS uses recursive resolvers, and as William Leibzon pointed this out to this message to DNSOPS back in 2006: http://www.ietf.org/mail-archive/web/dnsop/current/msg04911.html 

As William explains, it is quite possible to generate larger amplification attacks using plain old DNS, in particular, the NS, MX, SRV, etc. records.   Unlike RFC 4408, the DNS RFCs don't have any limits on the recursion depth.   It is far easier for an attacker to trigger an NS lookup than it is to trigger an SPF evaluation.

You would think that if such attacks were useful, that in the many years that the NS record has been around, the easy of which it is to trigger an NS lookup, and the larger amplification than SPF, that it would have shown up.

Things like the "no data" limit are not complete fixes.  Domains that have wildcard MX records, for example, will return data.   Actually, someone being attacked can use this, by publishing wildcards, they can create a useful TTL time.   Or, the party being attacked can update their SOA record with a longer nTTL time.

This is a general problem with recursion and DNS.   The solution is likely to be best made in the resolver itself, maybe with an API extension letting the resolver know what certain DNS lookups are related.

I highly recommend going back an reading that thread from William to DNSOPS before charging off to find "solutions".

---

From: Arthur Thisell <[email-masked]>
Date: Tue, 6 Mar 2012 11:55:01 -0800 (PST)

> I suggest we consider "MAY" language here -- admitting that we can't
> know how this issue might play out over the next decade. Instead of
> trying for a maximum number of such queries, could we consider instead
> what the _minimum_ might be to accomplish identified valid usage, and
> specify MAY for any queries beyond that minimum?

I don't much like this kind of thing since it would mean that two different SPF implementations/users could evaluate the same SPF record and give different results.   The goal of keeping SPF evaluations consistent is also why all syntax errors MUST be detected, and why you don't have to implement the check_host() function exactly as laid out in RFC 4408, but the results MUST be the same.

---

From: Arthur Thisell <[email-masked]>
Date: Sat, 10 Mar 2012 06:08:17 -0800 (PST)

>> The current rules are:
>> 
>> No more than 10 terms that need DNS lookups
>> No more than 10 a lookups from an mx mechanism
>> No more than 10 a lookups from a PTR mechanism.
>> 
>> So there is currently a primary limit of 10 and a secondary limit
>> of 10 lookups per primary of a certain type.
>
> I'm unable to see the advantages of such a complicated structure.  I
> hope we are not going to mandate that.

The advantage, as I see it, is that it is easier for the publisher.  It is easy to count by hand, the number of mechanisms/modifiers.   It is easy to make sure (or verify) that your MX records don't have more than 10 hosts.

Trying to correctly count the number of DNS looku