7Internet Engineering Task Force (IETF) J. Appelbaum
8Request for Comments: 7686 The Tor Project, Inc.
9Category: Standards Track A. Muffett
10ISSN: 2070-1721 Facebook
14 The ".onion" Special-Use Domain Name
18 This document registers the ".onion" Special-Use Domain Name.
22 This is an Internet Standards Track document.
24 This document is a product of the Internet Engineering Task Force
25 (IETF). It represents the consensus of the IETF community. It has
26 received public review and has been approved for publication by the
27 Internet Engineering Steering Group (IESG). Further information on
28 Internet Standards is available in Section 2 of RFC 5741.
30 Information about the current status of this document, any errata,
31 and how to provide feedback on it may be obtained at
32 http://www.rfc-editor.org/info/rfc7686.
36 Copyright (c) 2015 IETF Trust and the persons identified as the
37 document authors. All rights reserved.
39 This document is subject to BCP 78 and the IETF Trust's Legal
40 Provisions Relating to IETF Documents
41 (http://trustee.ietf.org/license-info) in effect on the date of
42 publication of this document. Please review these documents
43 carefully, as they describe your rights and restrictions with respect
44 to this document. Code Components extracted from this document must
45 include Simplified BSD License text as described in Section 4.e of
46 the Trust Legal Provisions and are provided without warranty as
47 described in the Simplified BSD License.
58Appelbaum & Muffett Standards Track [Page 1]
60RFC 7686 .onion October 2015
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
66 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
67 2. The ".onion" Special-Use Domain Name . . . . . . . . . . . . 3
68 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
70 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
71 5.1. Normative References . . . . . . . . . . . . . . . . . . 5
72 5.2. Informative References . . . . . . . . . . . . . . . . . 6
73 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
78 The Tor network [Dingledine2004] has the ability to host network
79 services using the ".onion" Special-Use Top-Level Domain Name. Such
80 names can be used as other domain names would be (e.g., in URLs
81 [RFC3986]), but instead of using the DNS infrastructure, .onion names
82 functionally correspond to the identity of a given service, thereby
83 combining location and authentication.
85 .onion names are used to provide access to end to end encrypted,
86 secure, anonymized services; that is, the identity and location of
87 the server is obscured from the client. The location of the client
88 is obscured from the server. The identity of the client may or may
89 not be disclosed through an optional cryptographic authentication
92 .onion names are self-authenticating, in that they are derived from
93 the cryptographic keys used by the server in a client-verifiable
94 manner during connection establishment. As a result, the
95 cryptographic label component of a .onion name is not intended to be
98 The Tor network is designed to not be subject to any central
99 controlling authorities with regards to routing and service
100 publication, so .onion names cannot be registered, assigned,
101 transferred or revoked. "Ownership" of a .onion name is derived
102 solely from control of a public/private key pair that corresponds to
103 the algorithmic derivation of the name.
105 In this way, .onion names are "special" in the sense defined by
106 Section 3 of [RFC6761]; they require hardware and software
107 implementations to change their handling in order to achieve the
108 desired properties of the name (see Section 4). These differences
109 are listed in Section 2.
114Appelbaum & Muffett Standards Track [Page 2]
116RFC 7686 .onion October 2015
119 Like Top-Level Domain Names, .onion names can have an arbitrary
120 number of subdomain components. This information is not meaningful
121 to the Tor protocol, but can be used in application protocols like
124 Note that .onion names are required to conform with DNS name syntax
125 (as defined in Section 3.5 of [RFC1034] and Section 2.1 of
126 [RFC1123]), as they will still be exposed to DNS implementations.
128 See [tor-address] and [tor-rendezvous] for the details of the
129 creation and use of .onion names.
1311.1. Notational Conventions
133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
135 document are to be interpreted as described in [RFC2119].
1372. The ".onion" Special-Use Domain Name
139 These properties have the following effects upon parties using or
140 processing .onion names (as per [RFC6761]):
142 1. Users: Human users are expected to recognize .onion names as
143 having different security properties (see Section 1) and also as
144 being only available through software that is aware of .onion
147 2. Application Software: Applications (including proxies) that
148 implement the Tor protocol MUST recognize .onion names as special
149 by either accessing them directly or using a proxy (e.g., SOCKS
150 [RFC1928]) to do so. Applications that do not implement the Tor
151 protocol SHOULD generate an error upon the use of .onion and
152 SHOULD NOT perform a DNS lookup.
154 3. Name Resolution APIs and Libraries: Resolvers MUST either respond
155 to requests for .onion names by resolving them according to
156 [tor-rendezvous] or by responding with NXDOMAIN [RFC1035].
158 4. Caching DNS Servers: Caching servers, where not explicitly
159 adapted to interoperate with Tor, SHOULD NOT attempt to look up
160 records for .onion names. They MUST generate NXDOMAIN for all
163 5. Authoritative DNS Servers: Authoritative servers MUST respond to
164 queries for .onion with NXDOMAIN.
170Appelbaum & Muffett Standards Track [Page 3]
172RFC 7686 .onion October 2015
175 6. DNS Server Operators: Operators MUST NOT configure an
176 authoritative DNS server to answer queries for .onion. If they
177 do so, client software is likely to ignore any results (see
180 7. DNS Registries/Registrars: Registrars MUST NOT register .onion
181 names; all such requests MUST be denied.
183 Note that the restriction upon the registration of .onion names does
184 not prohibit IANA from inserting a record into the root zone database
187 Likewise, it does not prevent non-DNS service providers (such as
188 trust providers) from supporting .onion names in their applications.
1903. IANA Considerations
192 This document registers ".onion" in the registry of Special-Use
193 Domain Names [RFC6761]. See Section 2 for the registration template.
1954. Security Considerations
197 The security properties of .onion names can be compromised if, for
200 o The server "leaks" its identity in another way (e.g., in an
201 application-level message), or
203 o The access protocol is implemented or deployed incorrectly, or
205 o The access protocol itself is found to have a flaw.
207 Users must take special precautions to ensure that the .onion name
208 they are communicating with is the intended one, as attackers may be
209 able to find keys that produce service names that are visually or
210 semantically similar to the desired service. This risk is magnified
211 because .onion names are typically not human-meaningful. It can be
212 mitigated by generating human-meaningful .onion names (at
213 considerable computing expense) or through users using bookmarks and
214 other trusted stores when following links.
216 Also, users need to understand the difference between a .onion name
217 used and accessed directly via Tor-capable software, versus .onion
218 subdomains of other top-level domain names and providers (e.g., the
219 difference between example.onion and example.onion.tld).
226Appelbaum & Muffett Standards Track [Page 4]
228RFC 7686 .onion October 2015
231 The cryptographic label for a .onion name is constructed by applying
232 a function to the public key of the server, the output of which is
233 rendered as a string and concatenated with the string .onion.
234 Dependent upon the specifics of the function used, an attacker may be
235 able to find a key that produces a collision with the same .onion
236 name with substantially less work than a cryptographic attack on the
237 full strength key. If this is possible the attacker may be able to
238 impersonate the service on the network.
240 A legacy client may inadvertently attempt to resolve a .onion name
241 through the DNS. This causes a disclosure that the client is
242 attempting to use Tor to reach a specific service. Malicious
243 resolvers could be engineered to capture and record such leaks, which
244 might have very adverse consequences for the well-being of the user.
245 This issue is mitigated if the client's software is updated to not
246 leak such queries or updated to support [tor-rendezvous], or if the
247 client's DNS software is updated to drop any request to the .onion
248 special-use domain name.
2525.1. Normative References
255 Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The
256 Second-Generation Onion Router", August 2004,
257 <https://svn.torproject.org/svn/projects/design-paper/
260 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
261 Requirement Levels", BCP 14, RFC 2119,
262 DOI 10.17487/RFC2119, March 1997,
263 <http://www.rfc-editor.org/info/rfc2119>.
265 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
266 RFC 6761, DOI 10.17487/RFC6761, February 2013,
267 <http://www.rfc-editor.org/info/rfc6761>.
270 Mathewson, N. and The Tor Project, "Special Hostnames in
271 Tor", 2006, <https://spec.torproject.org/address-spec>.
274 The Tor Project, "Tor Rendezvous Specification", April
275 2014, <https://spec.torproject.org/rend-spec>.
282Appelbaum & Muffett Standards Track [Page 5]
284RFC 7686 .onion October 2015
2875.2. Informative References
289 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
290 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
291 <http://www.rfc-editor.org/info/rfc1034>.
293 [RFC1035] Mockapetris, P., "Domain names - implementation and
294 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
295 November 1987, <http://www.rfc-editor.org/info/rfc1035>.
297 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
298 Application and Support", STD 3, RFC 1123,
299 DOI 10.17487/RFC1123, October 1989,
300 <http://www.rfc-editor.org/info/rfc1123>.
302 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and
303 L. Jones, "SOCKS Protocol Version 5", RFC 1928,
304 DOI 10.17487/RFC1928, March 1996,
305 <http://www.rfc-editor.org/info/rfc1928>.
307 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
308 Resource Identifier (URI): Generic Syntax", STD 66,
309 RFC 3986, DOI 10.17487/RFC3986, January 2005,
310 <http://www.rfc-editor.org/info/rfc3986>.
312 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
313 Protocol (HTTP/1.1): Message Syntax and Routing",
314 RFC 7230, DOI 10.17487/RFC7230, June 2014,
315 <http://www.rfc-editor.org/info/rfc7230>.
319 Thanks to Roger Dingledine, Linus Nordberg, and Seth David Schoen for
320 their input and review.
322 This specification builds upon previous work by Christian Grothoff,
323 Matthias Wachs, Hellekin O. Wolf, Jacob Appelbaum, and Leif Ryge to
324 register .onion in conjunction with other, similar Special-Use Top-
338Appelbaum & Muffett Standards Track [Page 6]
340RFC 7686 .onion October 2015
346 The Tor Project, Inc. & Technische Universiteit Eindhoven
348 Email: jacob@appelbaum.net
394Appelbaum & Muffett Standards Track [Page 7]