On 07/15/2015 09:42 AM, Edward Lewis wrote: > > The document defines the use of the name by referring to a couple of > references, none of which appears to be published in a way that can be > referenced except by URL. >
I agree that the URL could be use more foresight, e.g. https://torproject.org/spec/protocol, https://torproject.org/spec/naming, etc. I already suggested this form to the Tor people without response. That said, an URL is the right thing to do, as long as it does not change. Once the URL makes it to an RFC, it is the responsibility of the domain operators to keep it running. When the Tor specifications are updated to RFC status, then the .onion tld RFC can be updated as well to point to the new references. > > Drilling into the criteria that are presented. Not all of them. > > 1. Users. The draft states "human users are expected to recognize .on ion > names as..." How are users supposed to recognize them as (special)? In > as much as the document says nothing about evidence of deployment and > adoption, how can an expectation be developed? If I hadn't been readi ng > the thread on DNSOP, I wouldn't have thought "onion" was special - but I > live in a cave, so what I think isn't important. > The original P2PNames draft use: "Users can use these names as they would other domain names, entering them anywhere that they would otherwise enter a conventional DNS domain name. Since there is no central authority necessary or possible for assigning .onion names, and those names correspond to cryptographic keys, users need to be aware that they do not belong to regular DNS, but are still global in their scope." > 4. Caching DNS Servers and > 5. Authoritative DNS Servers > *** Well, isn't it the point of this draft that "as software matures onion names will not be in DNS queries"? These points are to minimize the consequences on privacy when misconfigured systems leak queries, and to minimize the number of bogus requests hitting the DNS tree. > 6. DNS Operators > *** Again, this is not about enforcing, but about establishing best practice. People can rely on RFC documentation and conscientious operators will apply what's written there. > 7. DNS Registrars/Registries > > This is the place where a case should be made for the registering "oni on" > as a Special Use Domain Name. Given the story to date, that "onion" i s > not to be in the DNS, then don't change the protocol (5,6 above) but t hen > set up barriers to putting it in the DNS (7 here). If you do that, th en > Name Resolution libraries (3 above) will return "name error" or NXDOMA IN > to all queries in the onion domain of names. I see this as where > registry policy documents can "point" (by reference) to a list of name s > that are specially reserved or restricted. > > My concern is that, if this application proceeds as documented, > the precedent being set could be regrettable. > *** Are you suggesting then that only 7. is kept? In any case I recommend reading the original proposal for .onion in the P2PNames draft 04 for an alternate view. Maybe some of the questions there can be useful here. https://tools.ietf.org/html/draft-grothoff-iesg-special-use-p2p-names-04 #section-4.3.1 == hk _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
