RFC 7686 is a remarkably short document — barely five pages — that quietly did something unprecedented: it carved out a piece of the global DNS namespace specifically for a system that doesn't use DNS at all. It formalizes .onion as a Special-Use Domain Name, reserving it exclusively for Tor hidden services.

The problem it solves. Before this RFC, .onion was a de-facto convention baked into the Tor Browser. A user typing facebookcorewwwi.onion would have their browser recognize the suffix and route the request through the Tor overlay network. But nothing at the protocol layer prevented ICANN from selling .onion as a gTLD, and — more dangerously — nothing stopped a misconfigured or malicious application from leaking .onion lookups to the public DNS. Those leaks were a real deanonymization vector: a resolver logs at your ISP would happily record every hidden service you tried to visit.

Key design decisions. The RFC takes advantage of RFC 6761's Special-Use Domain Names registry, the same mechanism that reserves localhost, example, and invalid. It specifies seven behaviors for different actors:

• Users should treat .onion names as identifiers of Tor hidden services, not conventional hostnames.
• Application software that implements the Tor protocol must recognize .onion and route through Tor.
• Application software that does not implement Tor SHOULD generate an error and MUST NOT perform DNS lookups — this is the crucial anti-leak clause.
• Name resolution APIs and libraries MUST respond with NXDOMAIN for .onion.
• Caching DNS servers SHOULD NOT attempt to resolve them and SHOULD respond with NXDOMAIN.
• Authoritative servers should not answer for .onion.
• Registries and registrars must not register .onion names — closing the ICANN attack surface.

The backstory is genuinely weird. Getting this through the IETF was a political fight. RFC 6761 was intended as an engineering mechanism, but the ICANN/IETF boundary was contested — did the IETF have authority to unilaterally reserve TLDs? The .onion registration succeeded partly because CA/Browser Forum needed it: without a reserved TLD, certificate authorities couldn't legitimately issue EV certs for .onion sites. Facebook had already gotten a cert for facebookcorewwwi.onion in 2014 under a special exemption, and this RFC provided the durable basis.

Why it matters today. This RFC is the template for how any overlay-network namespace should be handled. GNS, Namecoin, and other decentralized naming systems have all cited RFC 7686 in their attempts to reserve TLDs like .gnu and .bit (mostly unsuccessfully — the IETF got much stricter after this one). More practically, if you write a resolver, a browser, a proxy, or anything that touches hostnames, you need to short-circuit .onion to avoid leaking sensitive queries. Systemd-resolved, dnsmasq, unbound, and most stubs now do this by default because of this document.

It also cemented the model that Tor v3 onion addresses adopted: those 56-character base32 blobs (public key hashes) still terminate in .onion, and the RFC's guarantees still hold.