Since the Chairs have ruled that this warrants yet further discussion... Dave Crocker wrote: > Folks, > > This issue encompasses some others, but I believe it is more basic and > therefore > informs the others and therefore needs to be resolved separately: > > There is a basic difference between trying to protect a single domain > name, > versus trying to protect an entire sub-tree. > Two comments:
(1) It's worth being careful about the word "protect"; the draft doesn't use it (except once, in a somewhat different context) and we should be careful about setting an expectation that publication of ADSP confers protection. There is benefit to the publisher that may be viewed as protection that comes from the use of ADSP information by verifiers, but it is indirect and only to the extent that ADSP records are retrieved and used. (2) ADSP does not publish information about entire subtrees, only about domains and labels within an immediate domain. > 1. The DNS was not designed with sub-tree operators. The wildcard mechanism > is > a very narrowly-defined capability and is useless in the face of > underscore-based naming, since the underscore node really defines an > attribute > of the domain name it is under, rather than defining a true "name". > > What this leaves us with is attempting to invent mechanisms that turn > out > to do only a partial job, at best. > Underscore-based names have no special standing within DNS (such as definition of attributes), other than the fact that they are illegal as hostnames but are legal for some other purposes. DNS wildcards are indeed useless in the face of name prefixes, which is why ADSP does not depend on nor use them. The mechanism described in the draft may be viewed as doing a "partial job" but we still need to consider whether what it does is useful. I believe it is. > > 2. Some of the sub-tree effort is for administrative convenience. Some is > for > expanded semantics. > > It's not clear that the specification is clear about this distinction. > > It is not clear that the specification is clear about the motivations > that > make it mandatory to add sub-tree mechanisms to the specification. > Again, I reject the premise that this a sub-tree mechanism. What are the "expanded semantics" to which you refer? > > 3. At least one of the sub-tree mechanisms is attempting to glean > information > from the absence of publisher action. Let me explain: > > I believe the desire with checking the A record is similar to the idea > behind having ADSP in the first space. > > That is: > > a) DKIM is for declaring the presence of an accountable identity. > If a > signature is present, you know something. If it is absent, you know nothing > extra. > > b) ADSP attempts to tell you something, in the absence of a > signature. > It does that by defining something else that must be present. If the ADSP > record is present, you know something. If it is absent, you know nothing > extra. > > c) Checking for the presence of an A record is intended to try tell > you > something in the absence of an explicit action by the domain owner. That's > it's > flaw: It is intuiting ADSP information from non-ADSP action. > > While there is nothing wrong with checking the A record, it's semantics > have literally nothing (directly) to do with ADSP. > ADSP is not checking the A record, as others have pointed out. -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
