John Levine wrote: > This note seems relevant to DKIM. This draft says, predictably, that > the way you add new data types to the DNS is with a new RR type, and > all other approaches are ill-advised. > > It also says that DNS tree climbing is always bad. We might want to > reconsider whether the small amount of tree climbing specified in -03 > is worth the hassle it will doubtless cause on the route from final > draft to RFC. >
The relevant section (4) of this document points out that by querying the parent domain, it "may lead to incorrect results and may also put security at risk," because the parent domain maybe under different administrative control. What we need to consider is whether the risk of undesired inheritance of an ASP from a parent domain is greater or less than the risk presented by other labels (hostnames, etc.) being used in From addresses without regard for the ASP of the domain they're in. Since the default ASP is "unknown", the risk presented by a separately-managed parent domain is that they will publish an ASP that is stronger than that desired by the child. This can be countered either by the parent publishing its record with the t=s flag that prevents its application to subdomains, or by the child domain publishing an explicit ASP of its own. Without the parent query, any label in the domain is potentially able to be used to circumvent the ASP record. Labels in the domain not having an explicit ASP record would be interpreted as "unknown", which might be looser than the ASP for the domain. I have spent considerable time with the DNS folks, including two of the editors of this draft, socializing what we are doing here. I believe that security is better served by doing the parent query. I would hate to compromise the effectiveness of ASP just to make it more expedient to get it to RFC. -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
