> On 1 Sep 2015, at 10:35 pm, John Levine <jo...@taugh.com> wrote: > >> 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 vast sets of rules about how GTLDs are handled at the server > end. They have rules about DNSSEC and about server redundancy and > multiple layers of rules about what can and cannot be in the zone > files. Admittedly they're only binding on contracted parties, but if > you want rules, they got rules. There are also individual TLDs with > more specific rules, notably .TEL which mostly has NAPTR records.
But the point is they are binding only on contracted parties, and so
inappropriate for undelegated TLDs. ICANN enforces its rules via contact only.
So ICANN has no mechanism for specifying what happens to a non-delegated
domain. All I’m saying is that delegation isn’t always the desired outcome for
a special use domain, and the ability to specify how to handle the resolution
of a non-delegated special use domain is useful, and provides a justification
for using IETF rather than ICANN processes for such domains..
Whereas ICANN processes provide a lot of useful specification for
domains that are delegated, including many mechanisms (e.g. an ongoing
compliance monitoring process) that IETF is not in a position to provide.
> In any event, from the point of the DNS, a reservation that just says
> don't resolve .onion would be quite adequate.
You may consider the privacy leakage issues of no consequence. Others
do not.
>> And FWIW, [advice to reject .onion in applications is] not intended
>> primarily as an optimisation in the sense of efficiency, rather its an
>> attempt to mitigate a privacy leakage in the TOR system.
>
> If you implement what this draft says, your local DNS resolver library
> will reject .onion queries so there'll be no leakage. I suppose we
> might call it belt-and-suspenders.
Indeed. And I consider including that advice to thus serve a useful
purpose.
David
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
