The “.onion” Special-Use Domain Name (2015)

[rektide]

FWIW this came after a long long period of the DNSOP working group throwing hate and venom on this form of hithertofore non-normative DNS use cases. This was a very hot topic and it seemed like absolutely no progress was going to be made making this happen for a long time due to the DNSOPS wg.

I don't have good citations- would love to gather them again- but it was only after other IETF members started questioning the absurd rejectionist behavior of the DNSOP working group that this changed, and the .onion draft was allowed to get due status.

I can't think of any case in IETF history of a draft being so hotly denied and rejected. Very interesting story, look forward to someone telling it better than I.

[mastax]

> I don't have good citations- would love to gather them again

Here's a good place to start for anyone interested:

https://mailarchive.ietf.org/arch/search/?email_list=dnsop&q...

[wereHamster]

Who are the people in the DNSOP WG? Which companies do they work for? And why do these companies reject the RFC?

[canndrew2016]

Also, they were originally trying to get several already-in-use psuedo-TLDs recognized including .onion, .i2p, .bit and .gns, but they had to compromise.

[eriknstr]

About time (even though it was in 2015). I was afraid that someone was going to buy .onion and use it to deanonymize people who thought they were on TOR when they were not.

[vortico]

THIS is the important point of this post. It might be "cool" that they now recognize the TLD now, but I can't imagine the chaos it would cause if .onion was purchased.

[agildehaus]

Many web browsers have predictive services built-in to the address bar. Some are even enabled by default. Google has undoubtedly seen .onion addresses submitted.

[wccrawford]

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.

[belorn]

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.

[AndyMcConachie]

A couple of things you may be interested in reading.

http://www.verisign.com/assets/labs/Measuring-the-Leakage-of...

https://www.icann.org/en/system/files/files/sac-090-en.pdf

[drvdevd]

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?

[robert_foss]

Bundled with the .onion application was originally .i2p and .gnu applications as well.

Only after the Tor project unbundled the non .onion TLDs was any progress made.

After the .onion TLD had been accepted the process by which these special (reserved TLDs) were registered at the IETF was removed. The IETF bent over backwards not to include anyone and when they did they only allowed for a single TLD to be reserved before closing the special (reserved) TLD application process. Mind you that .gnu and .i2p applied on the exact same grounds and even on the exact same application originally.

I have never been in contact with a more dysfunctional and bureaucratic organization.

[nerdponx]

Why are they so hostile to these requests?

[TeMPOraL]

  Applications that do not implement the Tor
  protocol SHOULD generate an error upon the use of .onion and
  SHOULD NOT perform a DNS lookup.

Wait, does this mean that all my applications that deal with URLs now have to check for and reject entries that use .onion domain?

[andreareina]

Abstractly something on layer 7 of the OSI model shouldn't care exactly how the data is being routed, but the security considerations of using TOR breaks the abstraction. A naïve client could be made to leak identifying information through any number of side-channels. Since the lower layers can't have a whitelist of acceptable applications to connect to .onion addresses, the applications themselves must voluntarily refrain from connecting.

This is like the prevailing wisdom to check malloc's return value, not storing passwords in the database, not rolling your own crypto, etc. except that in this case it actually got included in the standard. Unfortunately like all those other things, there's nothing that actually prevents a programmer from breaking the rules.

[jdiez17]

Only applications that actually access URLs would need to generate an error. In practice, your code doesn't need to know about .onion domains - but network libraries like libcurl do.

[dheera]

What is this nonsense? A domain iooks up to an IP address (and some other things). DNS does not and should not care about what protocols are going to be used with said IP address.

I can use an .onion domain for unencrypted Telnet as root with no password if I want. It's stupid but that's not something that should be restricted at a DNS level.

[Jarwain]

I'd think, for the most part, it would act like using a typical invalid URL and throw an error. Special cases would be, say, Chrome rejecting .onions instead of doing a search

[jstanley]

You don't have to.

The reason to do so is to protect your user's privacy (i.e. so that their DNS server doesn't see what onion addresses they were trying to visit).

[cmrx64]

I'm curious why they decided on a "special-use domain name" instead of something like "onion://hash".

[zrm]

Because https://*.onion and ftps://*.onion are different. And it lets you do things like tor2web by just appending a DNS domain to the end of the onion domain, without requiring any special client support. And more things break on unexpected protocols than unexpected names.

[vortico]

This committee recognizes what already exists. onion://hash is not used because .onion domains are not different protocols (they're still http) but are a specially allocated space of hostnames representing the "addresses" of Tor servers.

[chungy]

It is extremely useful for an onion address to just define a plain old TCP socket, rather than imply HTTP. An onion address is just that... an anonymous connection to some server, somewhere in the world. While you might be unaware of where the service is operated from, it could be the exact opposite: maybe you just started an ssh server on your desktop and would like to access it remotely where ssh might be monitored or blocked -- despite ssh itself being encrypted, making a connection and the lifespan of the connection tell quite a lot about your habits. Or maybe you decide to visit China for a weekend... Hell, or maybe you're buried behind multiple NATs/firewalls and just need an easy way to poke from the outside (I've done this, in corporate environments where you can run your own VMs and such)

[AgentME]

Onion addresses describe a host that can be talked to via TCP, not just HTTP.

[eriknstr]

It was a long time ago that TOR chose to do so. I also think TLD makes sense anyway. TOR is a network and the protocol of the traffic that is relayed through it is independent of the transport.

[avar]

Relevant: A draft RFC for an X.alt tld, so in the future the next thing like the next X.onion would be X.onion.alt instead, with X.oninon not expected to change due to backwards compatibility: https://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-00

[stretchwithme]

I thought for sure that was going to be a TLD devoted to satire :-)

[prewett]

I figured "special-use" meant that only one domain name would be valid. Namely, "the".

[johnhenry]

In some ways, it is...

[hobarrera]

This is really cool, and I really hope that resolvers adopt this --- which basically means dropping any queries for `.onion` to avoid leaking that a client attempted to resolve such a domain.

[hackuser]

From 2015

[superkuh]

Yep. The author, Appelbaum, is no longer with Tor after falling victim to one of the many successful culture-based attacks on privacy and free software groups in 2015/2016.