.onion

.onion is a Special-Use Domain Name designating Tor onion services. It is not part of the public DNS root, being resolved inside the Tor network rather than via ordinary DNS queries. The designation gives Tor’s naming scheme an explicit place in the broader system of Internet identifiers without delegating a TLD in the ICANN-administered root zone.

Role in Tor Onion Services

Onion services (formerly called "hidden services") use .onion hostnames to provide end-to-end encrypted and anonymised connections in which both client and service locations are obscured by Tor’s onion routing protocol. An onion address is derived from the service’s public key; "version 3" addresses are 56-character base32 strings that encode a key plus checksum and version information.

Tor-aware applications, most notably the Tor Browser, treat .onion as belonging to a separate naming system, calling Tor’s rendezvous protocol, while other hostnames continue to be resolved via the local DNS resolver.

Registration as a Special-Use Domain

Before formal standardisation, .onion functioned as a de facto pseudo-TLD used only by Tor. RFC 7686 registers .onion in the IANA Special-Use Domain Names registry under the framework defined by RFC 6761, and specifies how software should treat it.

The RFC instructs DNS software not to forward .onion queries to the public DNS, and reserves the label from delegation in the DNS root. The goal is to reduce accidental leakage of onion addresses into the DNS infrastructure and to ensure that future new gTLD rounds cannot delegate .onion in a way that conflicts with Tor’s naming system.

ICANN material explaining the "dark web" therefore emphasises that .onion is reserved and was never delegated from the public DNS root, countering the recurring misconception that it is a normal gTLD.

HTTPS and Web PKI

Although Tor onion services are already authenticated at the protocol level (the hostname encodes the service’s key), some sites deploy HTTPS on top of Tor to integrate with the public Web PKI and to reuse browser security indicators.

Prior to RFC 7686 and related policy changes, certificate authorities could only issue certificates for .onion names as "internal names", and those certificates were subject to early expiry under CA/Browser Forum rules. After .onion was recognised as a special-use domain, CA/Browser Forum Ballot 144 added explicit validation rules for .onion names and permitted EV certificates for onion services under specific conditions.

Subsequent ballots and revisions created an explicit definition of an "Onion Domain Name" as any FQDN ending in the RFC 7686 .onion label and moved the validation rules into an Appendix that allows DV and OV certificates for version 3 onion addresses. In practice, Tor documentation notes that only a small number of CAs issue publicly trusted certificates for onion services, and that support is often manual and limited compared with ordinary DNS-based domains.

Internet Governance and Alternative Naming

From an Internet governance standpoint, .onion is a prominent example of an alternative naming system that coexists with the public DNS while sharing the same perceptive space. ICANN’s SSAC has repeatedly cited .onion when describing “uses of the shared global domain name space” by systems that are not part of DNS but still rely on familiar domain-name syntax. SAC123, on the evolution of the Internet name space, points to Tor’s use of .onion as an instance where an application-level naming system bypasses administrator-controlled DNS settings and may complicate efforts to maintain a single, coherent namespace.

These discussions place .onion alongside other alternative or non-DNS namespaces (such as .alt labels and blockchain-based naming) in debates about name collisions, user expectations, and the long-term stability of Internet identifiers. RFC 7686 and the corresponding IANA registry entry can be read as an attempt to document this reality and to provide minimal coordination between protocol design, certificate policy, and ICANN’s role in managing the public DNS root, without bringing onion services under ICANN’s contractual remit.

See Also

• Alternative roots

Top-Level Domain

Internet Assigned Numbers Authority

Request For Comments. Archival series dedicated to documenting Internet technical specifications, including general contributions from the Internet research and engineering community as well as standards documents (RFC Editor Model, Version 3).

Generic Top-level Domain

HTTP over Transport Layer Security (TLS), distinguishing secured traffic from insecure traffic by the use of a different server port (RFC 2818).

X.509 Public Key Infrastructure for the Internet (RFC 5280).

Security and Stability Advisory Committee. Advises the ICANN community and Board on matters relating to the security and integrity of the Internet's naming and address allocation systems (ICANN Bylaws).