ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] SSP issues

2007-05-31 07:10:23
william(at)elan.net wrote:

On Wed, 30 May 2007, Jim Fenton wrote:

(3) Upward query vs. wildcard publication.  27 messages in discussion
from 15 people.  Most of the discussion was a rehash of the idea of
associating semantics with DNS zone-cuts, which we had already
discussed and rejected.  I have also been trying to get an opinion
from DNSOP on the idea of a one-level upward search (which I think
solves 90% of the problem), but haven't gotten any response.

Dont do it. The issue is that you can not properly tell where zone
delegation starts. I know resourceful programmers (including me)
keep track of this data and know that for example ".com" is one
delegation but ".uk" is not and there you have ".co.uk". But the
list is actually rather large and for several ccTLDs you have both
use ".com.??" and ".??" as proper delegation zones. So getting
around this is just way too tricky and if you don't what you end
up doing is sending multitude of extra queries to ccTLD name servers.
This is not proper operational approach as extra load would not be
spread but directed towards several single points on the net.


The number of upward queries to TLDs and other "non-delegation zones"
would be limited by negative cacheing; each verifier should only be
making one such query per minimum TTL period.  I'm not sure how to
assess what would be an "acceptable" load, however, and in any case the
min TTL is sometimes rather short (15 minutes for .com, I see) so that
might not be enough help.

As for Doug's subsequent suggestion of publishing a list of such
non-delegation zones somewhere, we would need to normatively refer to
such a list, which means that it would need to be maintained by IANA or
a similar authority.  I don't see that as a likely possibility,
especially since the usage of ccTLDs is outside IANA's scope.

-Jim
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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