At 03:57 PM 5/24/2006 -0400, Stuart D. Gathman wrote:
On Wed, 24 May 2006, David MacQuigg wrote:
> >We can put the CNAME loop in DNSLookup for the pydns driver.
>
> Like this?
> alist = [((a['name'], a['typename']), a['data']) for a in
resp.answers]
> ## if len(alist) > MAX_CNAME:
> ## raise DNS.DNSError, 'No %s record in first %s answers' % (qtype,
>
## MAX_CNAME)
> count = 0; blist = []
> for a in alist:
> if a[0][1] == qtype:
> blist.append(a)
> else:
> count += 1 # Ignore CNAME records
>
> if len(blist) == 0:
> raise DNS.DNSError, 'No %s record in %s answers' % (qtype, count)
> return blist
Close, but if after following the CNAME change there is more than one
answer (up to 10 are allowed), then the ## commented test gives
an error incorrectly.
> Would it be possible to leave out the MAX_CNAME test entirely, and just go
> with the default limit of 8? That seems to be the limit for both pydns
and
> dnspython.
Looking at the RFC (which I approved - but wasn't thinking about this
issue at the time, was this one of the changes that we need to get from
Wayne?), it seems that processing limits are much vaguer that what was
discussed. It seems to limit total DNS lookups to 10, regardless of mechanism
(which is OK, I guess):
SPF implementations MUST limit the number of mechanisms and modifiers
that do
DNS lookups to at most 10 per SPF check, including any lookups caused by the
use of the "include" mechanism or the "redirect" modifier. If this number is
exceeded during a check, a PermError MUST be returned. The "include", "a",
"mx", "ptr", and "exists" mechanisms as well as the "redirect" modifier do
count against this limit. The "all", "ip4", and "ip6" mechanisms do not
require DNS lookups and therefore do not count against this limit. The "exp"
modifier does not count against this limit because the DNS lookup to
fetch the
explanation string occurs after the SPF record has been evaluated.
It seems that the size of MX and PTR result sets are limited:
When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro, there MUST
be a limit of no more than 10 MX or PTR RRs looked up and checked.
But the size of A and CNAME result sets are not, except for the following:
SPF implementations SHOULD limit the total amount of data obtained from the
DNS queries. For example, when DNS over TCP or EDNS0 are available,
there may
need to be an explicit limit to how much data will be accepted to prevent
excessive bandwidth usage or memory usage and DoS attacks.
Which doesn't establish a fixed limit. It is not clear what the SPF result
should be if the number of records returned for an A record or the length
of a CNAME chain exceeds the implementation defined limit.
The CNAME and A record limits don't impact the number of queries, because
the answers are all packed in one response. So I would treat these limits
as independent of the number of queries, which must be limited to avoid
DoS. I would say the limit of 8 CNAMES, established by both DNS packages,
is more than any reasonable domain will need.
The result shouldn't be PermError, because that is supposed to be
determined by the RFC - not implementation defined. So I suppose
the best response for CNAME or A overflow would be TempError.
This seems reasonable. If you have a ridiculously long CNAME chain, some
implementations might accept it, while others return a TempError, but it
isn't a DoS issue. The question is do we want to modify these
well-established DNS packages just to accommodate more than 8 CNAMES. I
see very little benefit, and a maintenance problem with each update of the
DNS package.
There may be one problem with TempError. The sender will keep trying, when
he should immediately fix his DNS records.
-- Dave
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com