4 ms·

The idea that we're treating name resolution differently by different applications is... Crazy. I can't even begin to imagine all the ways that is going to fa

The idea that we're treating name resolution differently by different applications is... Crazy. I can't even begin to imagine all the ways that is going to fail. The idea that users would have to be careful not to enter a .onion domain into non-TOR software is also crazy. Of course they're going to do this, and they're going to do it often. And relying on applications not to asking publicly for resolution for .onion domains is laughable. It's going to happen a lot. As others have noted, they should have implemented new protocol names instead. All existing software that doesn't follow these rules would simply do nothing (or return an error, as is appropriate) and only applications with actual support would attempt to do anything.

AndyMcConachie 10y ago
A couple of things you may be interested in reading. http://www.verisign.com/assets/labs/Measuring-the-Leakage-of-Onion-at-the-Root.pdf http://www.verisign.com/assets/labs/Measuring-the-Leakage-of... https://www.icann.org/en/system/files/files/sac-090-en.pdf https://www.icann.org/en/system/files/files/sac-090-en.pdf
belorn 10y ago
There exist several other and older top level domains which should never be publicly resolved. .localhost, .example, .invalid, and .test are a few domains which most resolvers (and even operative systems) know to not try resolve. .local, is an new one which zeroconf is primary responsible to resolve. To go to the extreme of having no such reserved domains would be crazy and way too much existing software would break spectacularly if anyone tried. rfc6761 is simply an update to rfc2606, by extending the concept of the reserved names like .localhost to names like .local or .onion.
drvdevd 10y ago
Of course this sounds like the right engineering approach, but perhaps fitting that into the browser use case was not possible in a manner suitable for the Tor project? After all, the primary interface to the Tor network for most users is their browser. [edit] meant to add: of course you could add a new protocol, but then that would imply browser modifications, right?

AndyMcConachie 10y ago

A couple of things you may be interested in reading. http://www.verisign.com/assets/labs/Measuring-the-Leakage-of-Onion-at-the-Root.pdf http://www.verisign.com/assets/labs/Measuring-the-Leakage-of... https://www.icann.org/en/system/files/files/sac-090-en.pdf https://www.icann.org/en/system/files/files/sac-090-en.pdf

belorn 10y ago

There exist several other and older top level domains which should never be publicly resolved. .localhost, .example, .invalid, and .test are a few domains which most resolvers (and even operative systems) know to not try resolve. .local, is an new one which zeroconf is primary responsible to resolve. To go to the extreme of having no such reserved domains would be crazy and way too much existing software would break spectacularly if anyone tried. rfc6761 is simply an update to rfc2606, by extending the concept of the reserved names like .localhost to names like .local or .onion.

drvdevd 10y ago

Of course this sounds like the right engineering approach, but perhaps fitting that into the browser use case was not possible in a manner suitable for the Tor project? After all, the primary interface to the Tor network for most users is their browser. [edit] meant to add: of course you could add a new protocol, but then that would imply browser modifications, right?