1. the users considerations pretend that users must use onion-aware software in order to access Onionspace, but I assert that you and I can use an ordinary Web browser, type in a .onion address, and access the requested service. Not only OnionTLD conflicts with P2PNames on that point, it also confuses users' awareness and application software responsibility (and possibly the scope of IANA Considerations' first question).
I've asked about this issue several times, and I keep getting different answers. What isn't clear to me is whether there is somewhere in the user's stack -- maybe it's the resolver, maybe it's the application, whatever -- that knows that onion is special and therefore shouldn't be looked up in the public DNS. I assume there has to be _somewhere_ that is special, or the alternative resolution obviously wouldn't work. I think that needs to be indicated somewhere, because this fact is what makes onion a candidate under 6761, I think. To put this to bed for Andrew’s benefit, I have uploaded a picture at: http://i.imgur.com/tvXrD8N.png The top is standard Firefox (for clarity it has also a BBC News tab open) The bottom is Tor Browser, which is Firefox hardwired to a Tor SOCKS daemon that performs resolution. On the Tor-enabled browser, you have access to extra sites in the “.onion” TLD, as illustrated. For clarity of my terminology, I “used" both browsers in the same way: pasted the URL “https://www.facebookcorewwwi.onion/“ into both, hit “return”, clicked the mouse, etc, the same way I would “use” most browsers. They are the same core codebase - Firefox - after all. One of them - the Tor Browser - is using a SOCKS daemon which knows that “.onion” is special and shouldn’t be looked up in the public DNS. The other has received NXDOMAIN from DNS. I believe that this demonstrates the condition you were looking for? The Tor browser also has special modifications (e.g.: plugins elided, features tweaked) to attempt to inhibit traffic ever hitting the internet except via the Tor SOCKS daemon, although these are more for privacy and consistency than for access. - alec
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
