ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] SSP issues

2007-05-30 16:33:58

On Wed, 30 May 2007, Douglas Otis wrote:

On May 30, 2007, at 4:54 PM, william(at)elan.net 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.

I would be happy to help co-author a draft that establishes a list of current domains levels used by registries which should be excluded from queries for DKIM related records.

That's not the way to do it. The list only provides info on current
moment where as technology should be general and should not restrain
or be restrained by policy issues (and deciding if they want or do not want to offer direct SLD for come ccTLD is a policy issue).

Besides that there are other issues with just doubling number of
queries for new record. The only case where I see it as acceptable
is for transition period (i.e. A & AAAA ; although clearly such
"trasition" periods can last very very long time...).

--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

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