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 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.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
-------
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