>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. In any event, from the point of the DNS, a reservation that just says don't resolve .onion would be quite adequate. If someone else wanted to invent another software package that also squatted on .onion to do something else, it'd be confusing but it wouldn't cause new DNS stability problems. >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. R's, John _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
