On Jul 25, 2006, at 5:33 PM, Hallam-Baker, Phillip wrote:
The intent was to point to a general label where policy references
are found. Philip suggested this should point to an HTTP server.
HTTP is needed to support the size of an all encompassing policy
response.
No I did not make that suggestion.
What I did say is that we should not look to put more that the bare
essentials into the DNS system, that is the data that a client is
going to use to make a choice between services and to configure the
security context to connect to a service. If there is a need to go
beyond that we can link out to HTTP but that is not necessary for DKIM
My apologies. I see that you have suggested resource records located
at the underscore label will use protocol specific policy RR types to
avoid collision. Currently, this process requires an attempt to
directly obtain desired policy RR types at the underscore label. If
that fails, a transaction then obtains the prefix-wildcard RR
record. The content of the prefix-wildcard RR then locates the
desired policy RR type for one more transaction.
Of course, a script or complaint DNS server generates the added
wildcard records, but this may create issues related to revealing
nodes within a domain. Assuming this disclosure is not a problem,
automating this prefix-wildcard RR record would ideally always return
the desired policy RR on the first transaction "as if"
_policy.<subdomain.domain> contained the policy RRset. Specialized
handling for the prefix-wildcard RR in this case would conflict with
PTR definitions, however. As this scheme expects new and protocol
specific RR types, defining an RR to support the prefix-wildcard
seems appropriate as well.
Perhaps it could be defined as:
_policy.<domain> PWCARD <list-of-RR-types> <location-of-RR-types> ;no
need for the ** label as this would be keyed off of the PWCARD type.
The list of policy RR types might help handle policy RRset overflow
conditions. The list allows individual queries of the most
appropriate policy type without iterative queries to discover what is
available. This assumes policy structures may evolve, and that more
than one policy for a protocol might be published. If this approach
does become popular, it may not be possible to obtain the entire RRset.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html