On Wednesday 24 May 2006 15:57, 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):
IIRC, when Stuart and I debated this issue last year, his interpretation of
the RFC that describes CNAMES (I don't recall which one, I'll look it up when
I have more time) was much more generous than mine. Now it was an
interpretation, so there is room for disagreement.
My reading of the RFC was that the CNAME record is supposed to point to the
canonical name. That is, CNAME chains are not allowed as pointing to CNAME
record to another CNAME record is NOT pointing to the actual canonical name.
So, by my interpretation, the correct number of CNAMES to follow is 1. I
don't see a significant risk is using a higher number, but that is what, I
think, the standards call for.
On a separate point, I would recommend that you don't patch pyDNS unless you
are willing to take over maintenance and packaging an create an actual fork
of the project. Today, when pointing to the correct sources.list, I can
apt-get install pydns. If you are going to use a non-standard version, I
think it would be better to either call it something different or take on
making sure the updates get into the same distribution channels that the
current pyDNS is in. This is why, in my opinion, Type 99 support is in pySPF
and not in pyDNS.
Scott K
-------
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