Jim Fenton wrote:
Just for the record:
(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.
Issue#3: +1 - Define an upward query based approach to finding SSP
statements
Issue#3: -1 - Define a wildcard based approach to finding SSP
statemetns
+1
Rationale: Required to support TXT RR (what I think is what we'll end
up with). Even with a new RR, it avoids the need to publish an
additional new-RR record to go with every other label in the zone to
deal with the characteristics of DNS wildcarding.
+1, I was either way with this before, but now I agree with Jim.
I know this is obvious to many, but wildcarding is not about the client
issuing a wildcard request. It is a server-side setup. So I don't
think we have any control how a DNS administrator may or may not use
wildcards to describe his zone.
But that may depend on the syntax.
Currently Jim, SSP describes a syntax of:
_policy._domainkeys.<domain>
Based on my testing, I don't think this lends itself to a wildcard
preparation. Is this correct?
The exploration I did using a DMP (LMAP idea) approach with a sub-domain
zone cut off, does allow for a wildcard approach:
[subdomain]._policy._domainkeys.<main-domain>
where main-domain is where the DOMAIN ownership begins. I am not sure
how DNS administrators officially label the "main-domain" but the
problem seems to be that it is "impractical" for the client to determine
where the domain ownership begins without some additional lookups.
In any case, not ideal, but without a reliable gTLD/ccTLD detection
method, it seems we have no other choice but to use a sub-domain
traversal approach as currently described in SSP-03.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html