This is a language quibble. I said ICANN had no mechanisms for specifying how a domain should be handled, and I would think a SHOULD specification is exactly that in formal language. ICANN has no good mechanism to make recommendations for DNS resolver behaviour of an undelegated domain, even minor ones. And FWIW, its not intended primarily as an optimisation in the sense of efficiency, rather its an attempt to mitigate a privacy leakage in the TOR system. Its certainly not as important as the reservation of the domain, but I don’t think avoiding the privacy issues associated with DNS resolution (as discussed in the recent helpful RFC 7626) is considered that minor in many Tor use cases, even for accidental misuse of .onion names.
David > On 1 Sep 2015, at 11:27 am, John R Levine <jo...@taugh.com> wrote: > >> I’d add that ICANN has no mechanism for specifying how a top level domain >> should be handled other than the simple delegation/non-delegation binary (it >> can specify how certain sub-domains should be handled as a condition of >> delegation). It cannot, as the .onion proposal does, specify that the domain >> be handled differently by resolvers without delegation. > > That's not what the draft says. It says that resolvers MUST (2026 language) > return NXDOMAIN for all .onion queries. > > Using Tor is entirely optional, and is handled by applications, not the DNS. > It encourages (SHOULD) applications that don't support Tor to fail .onion > lookups before passing them to the DNS, but that's a minor optimization. > > R's, > John_______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
