
The “.onion” Special-Use Domain Name (2015) - franze
https://tools.ietf.org/html/rfc7686
======
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.

~~~
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.

~~~
Tepix
Is someone working on getting .bit officially recognized by the IETF?

~~~
canndrew2016
Not that I know of now. Here's the original RFC that became the RFC which got
.onion recognized

[http://www.potaroo.net/ietf/idref/draft-grothoff-iesg-
specia...](http://www.potaroo.net/ietf/idref/draft-grothoff-iesg-special-
use-p2p-names/)

They were trying to get .gns, .zkey, .onion, .exit, .i2p and .bit recognized.

------
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.

~~~
sandworm101
There were plans for that contigency. Tor would have moved to some other tld
(ie .onionland). The tor browser bundle would update bookmarks and probably
issue a warning for .onion addresses. Annoyance but not chaos.

~~~
dawnerd
I think the fear would be from people not familiar enough with tor to think
any ol' .onion link was anonymous.

~~~
temprature
This can already happen with existing TLDs, for example:
[https://3g2upl4pq6kufc4m.onion.link](https://3g2upl4pq6kufc4m.onion.link)

DDG themselves used to link to that URL in thee instant answer box if you
searched for "duckduckgo onion", and I don't think anyone who isn't familiar
with TLDs and Tor would realise what is happening there.

------
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.

------
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?

~~~
gulaschbrot
I guess because you cannot make money selling reserved special use domain
names.

------
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?

~~~
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.

~~~
erydo
At first I agreed with you, but realized that my preferred solution was
essentially what they recommended and just with different wording. My thought
process was:

    
    
      - Absolutely, DNS resolvers should not care or have knowledge of the protocol that will be used to access that address.
      - What they *should* do is just say that normal DNS resolvers shouldn't ever resolve .onion addresses.
      - (And then Tor should include a special DNS resolver that does anyway.)
      - Oh, that's compatible with what they said.
    

I think some of the confusion comes from their use of "applications".

~~~
Ajedi32
The problem is that

> Tor should include a special DNS resolver that does anyway

Would be pointless, given that the spec says:

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

So according to this spec, even if you did implement a special DNS resolver,
only TOR-aware applications would be able to use it, and that's pointless
since TOR-aware applications can connect to `.onion` services without using
DNS at all.

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

~~~
zrm
Because [https://*.onion](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.

~~~
kaoD
Maybe https+onion://, ftps+onion://, etc.? .onion being a special-cased TLD is
calling for unexpected privacy leaks.

~~~
Ajedi32
As I understand it, currently _any_ protocol can be routed to a `.onion` TOR
hidden service using a SOCKS proxy. So services don't necessarily even need to
be aware of TOR, and can just use it as an underlying transport so long as
they're capable of routing traffic and DNS requests through SOCKS. You
wouldn't be able to do that if you just started making up protocol names like
that; your FTP client doesn't know how to handle the `ftps+onion://` protocol.
(But it can handle `ftps://somedomainhash.onion/` over a TOR-aware SOCKS proxy
just fine.)

This advantage is entirely negated though by this line in the new spec:
"Applications that do not implement the Tor protocol SHOULD generate an error
upon the use of .onion and SHOULD NOT perform a DNS lookup." So you definitely
have a valid point. If they don't want to allow applications that don't
explicitly support TOR to connect to `.onion` addresses, why not just make up
new protocols that existing applications don't support?

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

The RFC is still a "Proposed Standard" and that sentence is probably a
mistake.

Even applications that are _designed_ to use Tor like the Tor Browser don't
"implement the Tor protocol", tor implements the Tor protocol and other
applications use tor via SOCKS. Or not even that now that there are things
like torify.

The problem is there is a trade off between a) applications that know nothing
of Tor leaking the onion name lookups from people who actually need anonymity
into the public DNS when Tor is not installed or configured correctly, and b)
breaking things for people who want the widest variety of application support
via Tor, who aren't interested in anonymity and are only using it for e.g. NAT
traversal. (The Tor people like to encourage the second group because more
users improves overall anonymity.)

A possible solution is Tor providing a particular innocent name that will
resolve via Tor but not via public DNS, and then applications that can't
resolve that name should not try to resolve any other onion names, and DNS
caches like dnsmasq should by default return NXDOMAIN for that name without
forwarding the query.

------
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](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".

------
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.

~~~
nerdponx
You're gonna have to explain that a little.

~~~
loeg
Much of the context can be found here:
[http://jacobappelbaum.net/](http://jacobappelbaum.net/) and
[https://en.wikipedia.org/wiki/Jacob_Appelbaum#Allegations_of...](https://en.wikipedia.org/wiki/Jacob_Appelbaum#Allegations_of_sexual_misconduct)
.

~~~
Natsu
I don't know any of the people involved, but this part always struck me as
being pretty odd:

====

On 10 June, Jill Bähring, a woman whom three witnesses claimed to have seen
being abused,[92] flatly denied the abuse allegations.[101] In a statement
released by Gizmodo journalist William Turton, Bähring wrote: "Reading this
highly distorted version of my experience, which is being used as one of the
'bulletproof examples' of Jacob's alleged misbehavior, I can’t help but
wonder. Wonder about all the stories that have been published the last days.
Wonder not only about mob justice on twitter, caused by rumors and
speculation, but also about the accounts repeated by those who call themselves
journalists. Wonder about how many other stories have been willingly
misinterpreted. Wonder about the witnesses in all these stories, who
coincidentally always seem to consist of the same set of people. Wonder about
their motive to speak on my behalf without my consent."[102][103]

