The ".onion" Special-Use Domain Name
Extracted elements (18)
.onion names functionally combine location and authentication: they are derived from the cryptographic keys used by the server, verified by the client during connection establishment, so they are self-authenticating without relying on a DNS hierarchy or central authority.
Ownership of a .onion name is derived solely from control of a public/private key pair corresponding to the algorithmic derivation of the name. Because the Tor network has no central controlling authority, .onion names cannot be registered, assigned, transferred, or revoked through any registry.
.onion names are required to conform to DNS name syntax as defined in RFC 1034 Section 3.5 and RFC 1123 Section 2.1 because they will still be exposed to DNS implementations.
Applications (including proxies) that implement the Tor protocol MUST recognize .onion names as special by either accessing them directly or using a proxy (e.g., SOCKS) to do so.
Applications that do not implement the Tor protocol SHOULD generate an error upon the use of .onion and SHOULD NOT perform a DNS lookup.
Authoritative DNS servers MUST respond to queries for .onion with NXDOMAIN.
Caching DNS servers not explicitly adapted to interoperate with Tor SHOULD NOT attempt to look up records for .onion names, and MUST generate NXDOMAIN for all such queries.
DNS registrars MUST NOT register .onion names; all such requests MUST be denied.
DNS server operators MUST NOT configure an authoritative DNS server to answer queries for .onion; if they do so, client software is likely to ignore any results.
Name resolution APIs and libraries MUST either respond to requests for .onion names by resolving them according to the Tor rendezvous specification or by responding with NXDOMAIN.
A legacy client may inadvertently resolve a .onion name through the DNS, disclosing that the client is attempting to use Tor to reach a specific service. Malicious resolvers could capture such leaks with very adverse consequences for user safety; mitigation requires updating client software or DNS handling to suppress .onion queries.
A .onion name's cryptographic label is constructed by applying a function to the server's public key; the output is rendered as a string and concatenated with '.onion'. The label is not intended to be human-meaningful.
Like top-level domain names, .onion names can have an arbitrary number of subdomain components. This subdomain information is not meaningful to the Tor protocol but can be used in application protocols such as HTTP.
This document registers '.onion' in the IANA Special-Use Domain Names registry defined by RFC 6761. The registration template is provided in Section 2.
Attackers may find keys that produce .onion service names that are visually or semantically similar to a desired service. This risk is magnified because .onion names are not human-meaningful and can be mitigated by generating human-meaningful names (at high computing cost) or by using bookmarks and trusted stores.
Depending on the hash function used to derive the cryptographic label, an attacker may find a key collision producing the same .onion name with substantially less work than a full-strength cryptographic attack, potentially enabling service impersonation.
The security properties of .onion names can be compromised if the server leaks its identity at the application layer, if the access protocol is implemented or deployed incorrectly, or if the access protocol itself has a flaw.
Users need to distinguish between a .onion name accessed directly via Tor-capable software versus .onion subdomains of other top-level domains (e.g., the difference between example.onion and example.onion.tld), as the latter do not provide Tor's security properties.