idnits 2.17.1 draft-grothoff-iesg-special-use-p2p-names-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 03, 2014) is 3705 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 665, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 668, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C. Grothoff 3 Internet-Draft M. Wachs 4 Intended status: Informational TU Munich 5 Expires: September 4, 2014 H. Wolf, Ed. 6 GNU consensus 7 J. Appelbaum 8 Tor Project Inc. 9 March 03, 2014 11 Special-Use Domain Names of Peer-to-Peer Systems 12 draft-grothoff-iesg-special-use-p2p-names-02 14 Abstract 16 This is an IESG Approval document requesting the reservation of six 17 Top-Level Domains for special use, in conformance with the 18 registration procedure defined in RFC 6761, section 4. 20 Peer-to-Peer systems use specific decentralized mechanisms to 21 allocate, register, manage, and resolve names. Those mechanisms 22 operate entirely outside of DNS, independently from the DNS root and 23 delegation tree. In order to avoid interoperability issues with DNS 24 as well as to address security and privacy concerns, this document 25 describes six pseudo Top-Level Domain names (pTLDs), reserved for 26 special use. 28 The following six domains relate to security-focused peer-to-peer 29 systems. They are: ".gnu", ".zkey", ".onion", ".exit", ".i2p", and 30 ".bit". 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 4, 2014. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Terminology and Conventions Used in This Document . . . . . . 3 68 3. Description of Special-Use Domains in P2P Networks . . . . . 4 69 3.1. The ".gnu" Relative pTLD . . . . . . . . . . . . . . . . 4 70 3.2. The ".zkey" Compressed Public Key pTLD . . . . . . . . . 4 71 3.3. Geographically Anonymous pTLDs . . . . . . . . . . . . . 4 72 3.3.1. The ".onion" Hidden Service pTLD . . . . . . . . . . 4 73 3.3.2. The ".exit" Client Source Routing pTLD . . . . . . . 5 74 3.4. The ".i2p" Addressbook pTLD . . . . . . . . . . . . . . . 5 75 3.5. The ".bit" Timeline System pTLD . . . . . . . . . . . . . 6 76 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 78 5.1. Domain Name Reservation Considerations for ".gnu." . . . 7 79 5.2. Domain Name Reservation Considerations for ".zkey." . . . 8 80 5.3. Domain Name Reservation Considerations for ".onion." . . 10 81 5.4. Domain Name Reservation Considerations for ".exit." . . . 11 82 5.5. Domain Name Reservation Considerations for ".bit." . . . 13 83 5.6. Domain Name Reservation Considerations for ".i2p." . . . 14 84 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 7.1. Normative References . . . . . . . . . . . . . . . . . . 15 87 7.2. Informative References . . . . . . . . . . . . . . . . . 15 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 90 1. Introduction 92 Today, the Domain Name System (DNS) is a key service for the 93 Internet. DNS is primarily used to map human-memorable names to IP 94 addresses, which are used for routing but generally not meaningful 95 for humans. However, the hierarchical nature of DNS makes it 96 unsuitable for various Peer-to-Peer (P2P) Name Systems. As 97 compatibility with applications using domain names is desired, these 98 overlay networks often define exclusive alternative pseudo Top-Level 99 Domains (pTLDs) to avoid conflict between the P2P namespace and the 100 DNS hierarchy. 102 The purpose of this document is to inform the Internet community 103 about current practice of such pseudo-TLDs within peer-to-peer 104 systems, and to normalize their usage according to the rules of RFC 105 6761. Given their decentralized design, such P2P systems do not 106 require a central authority to register names nor do they belong to 107 the DNS resolution tree. 109 RFC 6761 defines a mechanism for reserving domain names for special 110 use. This document is an IESG Approval document requesting the 111 reservation of six pTLDs for special use: ".gnu", ".zkey", ".onion", 112 ".exit", ".i2p", and ".bit". 114 The GNU Name System (GNS) (".gnu", ".zkey"), the Tor network 115 (".onion", ".exit"), the Invisible Internet Project (".i2p"), and the 116 Dot-Bit Project (".bit") use these pseudo-Top-Level Domains (pTLDs) 117 to realize fully-decentralized and censorship-resistant secure 118 alternatives for DNS or, in the case of the ".exit" pTLD, to control 119 overlay routing and to securely specify path selection choices 120 [TOR-PATH]. 122 To facilitate integration with legacy applications, the overlay's 123 namespaces can be accessed from applications to resolve these special 124 TLDs, for example via specialized SOCKS proxies [RFC1928], 125 specialized DNS servers, or transparent name resolution and ephemeral 126 address mapping. 128 2. Terminology and Conventions Used in This Document 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC 2119. 134 The word "peer" is used in the meaning of a individual system on the 135 network. Thus, "local peer" means the localhost. 137 The acronym "pTLD" is used as a shortcut to mean a pseudo Top-Level 138 Domain, i.e., a name or label for a network not allocated using 139 common DNS procedures, and reserved with IANA for special use. 141 In this document, ".tld" (with quotes) means: any domain or hostname 142 within the scope of a given pTLD, while .tld (without quotes), or 143 dot-tld, both refer to an adjective form. For example, a collection 144 of ".gnu" peers, but an .onion URL. The pTLD itself is mentioned 145 with dot, and within double quotes, and usually followed by the word 146 pTLD. 148 The Tor-related names such as 'circuit', 'exit', 'node', 'relay', 149 'stream', and related Tor terms are described in [Dingledine2004] and 150 the Tor protocol specification [TOR-PROTOCOL]. 152 3. Description of Special-Use Domains in P2P Networks 154 3.1. The ".gnu" Relative pTLD 156 The ".gnu" pTLD is used to specify that a domain name should be 157 resolved using GNS instead of DNS. The GNS resolution process is 158 documented in [Schanzenbach2012]. As GNS users need to install a GNS 159 resolver on their individual system and as GNS resolution does not 160 depend on DNS, there are no considerations for DNS with respect to 161 the internals of the GNS resolution process itself. 163 3.2. The ".zkey" Compressed Public Key pTLD 165 The ".zkey" pTLD is used to signify that resolution of the given name 166 MUST be performed using a record signed by an authority that is in 167 possession of a particular public key. Names in ".zkey" MUST end 168 with a domain which is the compressed point representation from 169 [EdDSA] on [Curve25519] of the public key of the authority, encoded 170 using base32hex [RFC4648]. A GNS resolver uses the key to locate a 171 record signed by the respective authority. 173 The ".zkey" pTLD provides a (reverse) mapping from globally unique 174 hashes to public key, therefore names in ".zkey" are non-memorable, 175 and are expected to be hidden from the user [Schanzenbach2012]. 177 3.3. Geographically Anonymous pTLDs 179 The Tor anonymization network makes use of several special pTLD 180 labels, three of which have seen widespread usage to date 181 [TOR-ADDRESS]. 183 3.3.1. The ".onion" Hidden Service pTLD 185 The widely deployed ".onion" pTLD designates an anonymous Tor Hidden 186 Service reachable via the Tor network [Dingledine2004]. These .onion 187 URLs are self-authenticating addresses for use with any TCP service. 188 Such addresses are typically resolved, reached and authenticated 189 through transparent proxying or through a local SOCKS proxy running 190 on TCP port 9050, TCP port 9150 or another user selected TCP port. 191 The purpose of the Tor Hidden Services system is to provide 192 geographic anonymity for the .onion host and for all clients visiting 193 the hidden service as well as other purposes such as NAT traversal, 194 strong authentication, anonymity and censorship resistance. 196 Addresses in ".onion" are opaque, non-mnemonic, alpha-semi-numeric 197 hashes corresponding to an 80-bit truncated SHA1 hash over a given 198 Tor hidden service's public key. This hash can be made up of any 199 letter of the alphabet and decimal digits beginning with 2 and ending 200 with 7, thus representing a number in base32 [RFC4648]. Tor 201 generates this "Onion key" automatically when the hidden service is 202 configured. Tor clients use it following the Tor Rendezvous 203 specifications [TOR-RENDEZVOUS]. 205 3.3.2. The ".exit" Client Source Routing pTLD 207 The dot-exit suffix is used as an in-band source routing control 208 channel, usually for selection of a specific Tor relay during path 209 creation as the last node in the Tor circuit. 211 It may be used to access a DNS host via specific Torservers, in the 212 form "hostname.nickname-or-fingerprint.exit", where the "hostname" is 213 a valid hostname, and the "nickname-or-fingerprint" is either the 214 nickname of a Tor relay in the Tor network consensus, or the hex- 215 encoded SHA1 digest of the given node's public key (fingerprint). 217 For example, "gnu.org.noisetor.exit" will route the client to 218 "gnu.org" via the Tor node nicknamed "noisetor". Using the 219 fingerprint instead of the nickname ensures that the path selection 220 uses a specific Tor exit node, and is harder to remember: e.g., 221 "gnu.org.f97f3b153fed6604230cd497a3d1e9815b007637.exit". 223 When Tor sees an address in this format, it uses the specified 224 "nickname-or-fingerprint" as the exit node. If no "hostname" 225 component is given, Tor defaults to the published IPv4 address of the 226 Tor exit node [TOR-EXTSOCKS]. 228 Because "hostname" is allegedly valid, the total length of a dot-exit 229 construct may exceed the maximum length allowed for domain names. 230 Moreover, the resolution of "hostname" happens at the exit node. 231 Trying to resolve such invalid domain names, including chaining dot- 232 exit names will likely return a DNS lookup failure at the first exit 233 node. 235 3.4. The ".i2p" Addressbook pTLD 236 The ".i2p" pTLD provides accessibility to anonymous services 237 ("eepsites") within the I2P network. I2P is a scalable, self- 238 organizing, resilient packet switched anonymous network layer, upon 239 which any number of different anonymity or security-conscious 240 applications can operate. 242 The local I2P proxy resolves such names either by looking up a local 243 table called the addressbook, or by decoding Base32-encoded [RFC4648] 244 public keys and establishing a tunnel to the respective authority, 245 similar to contacting .onion hidden services. The details of I2P's 246 operation [I2P-NAMING] are outside of the scope of this document. 248 As the system is decentralized, "example.i2p" may also resolve 249 differently for different peers, depending on the state of their 250 respective addressbooks. 252 3.5. The ".bit" Timeline System pTLD 254 The ".bit" pTLD provides a name space where names are registered via 255 transactions in the Namecoin currency [Namecoin]. Like Bitcoins, 256 Namecoins are created using a proof-of-work calculation, which is 257 also used to establish a decentralized, multi-party consensus on the 258 valid transaction history, and thus the set of registered names and 259 their values [SquareZooko]. 261 The Namecoin used in a transaction to register a name in ".bit" is 262 lost. This is not a fundamental problem as more coins can be 263 generated via mining (proof-of-work calculations). The registration 264 cost is set to decrease over time, to prevent early adopters from 265 registering too many names. 267 The owner of a name can update the associated value by issuing an 268 update, which is a transaction that uses a special coin which is 269 generated as change during the registration operation. If a name is 270 not updated for a long time, the registration expires. 272 4. Security Considerations 274 Specific software performs the resolution of the six requested 275 Special-Use Domain Names presented in this document; this resolution 276 process happens outside of the scope of DNS. Leakage of requests to 277 such domains to the global operational DNS can cause interception of 278 traffic that might be misused to monitor, censor, or abuse the user's 279 trust, and lead to privacy issues with potentially dramatic 280 consequences for the user. 282 This RFC addresses another possible security concern, as the 283 reservation of several Top-Level Domain names for these purposes will 284 minimize the possibility of confusion and conflict, and especially 285 privacy risks for users. 287 5. IANA Considerations 289 The P2P Name Systems domains listed below, and any domains falling 290 within those domains are Special-Use Domain Names [RFC6761]: 292 gnu. 294 zkey. 296 onion. 298 exit. 300 i2p. 302 bit. 304 5.1. Domain Name Reservation Considerations for ".gnu." 306 The ".gnu." domain is special according to RFC 6761, section 5 307 [RFC6761], in the following ways: 309 1. Users MAY use these names as they would other domain names, 310 entering them anywhere that they would otherwise enter a 311 conventional DNS domain name. 313 Since there is no central authority responsible for assigning 314 dot-gnu names, and that specific domain is local to the local 315 peer, users SHOULD be aware of that specificity. 317 In any case, resolution in the dot-gnu pTLD returns DNS 318 compatible results, and thus SHOULD NOT affect normal usage of 319 most Internet applications. 321 2. Application Software MAY pass requests for dot-gnu domains for 322 normal DNS resolution. If available, the local resolver MUST 323 intercept such requests within the respective operating system 324 hooks and return DNS compatible results. However, GNS-aware 325 applications MAY choose to talk directly to the respective GNS 326 resolver, and use this to access additional record types (with 327 numbers above 65535) that are not defined in DNS. 329 As mentioned in points 4. and 5. below, regular DNS resolution is 330 expected to respond with NXDOMAIN. Therefore, if it can 331 differentiate between DNS and P2P name resolution, application 332 software MAY expect such a response, and MAY choose to treat 333 other responses from the DNS as errors. 335 3. For legacy applications and legacy name resolution APIs expecting 336 DNS resolution, no changes are required. 338 However, Name Resolution APIs and Libraries MAY choose to support 339 additional record types over time for the dot-gnu names. They 340 MAY choose to directly resolve those domains via appropriate APIs 341 or mechanisms such as the GNS-specific resolution protocol. 343 4. Caching DNS servers SHOULD recognize dot-gnu names as special and 344 SHOULD NOT, by default, attempt to look up NS records for them, 345 or otherwise query authoritative DNS servers in an attempt to 346 resolve dot-gnu names. Instead, caching DNS servers SHOULD, by 347 default, generate immediate negative responses for all such 348 queries. 350 5. Authoritative DNS Servers are not expected to treat dot-gnu 351 domain requests specially. In practice, they MUST answer with 352 NXDOMAIN, as dot-gnu is not available via global DNS resolution, 353 and not doing so MAY put users' privacy at risk, e.g., as 354 suggested in the next point. 356 6. DNS Server Operators SHOULD treat requests to the dot-gnu domain 357 as errors, for correct installations MUST NOT allow such requests 358 to escape to DNS. DNS operators MUST NOT choose to redirect such 359 requests to a site, not even to explain to the user that their 360 P2P resolver is missing or mis-configured as this MAY violate 361 privacy expectations of the user. 363 7. DNS Registries/Registrars 365 In order to avoid conflicts with the P2P namespaces [SAC45], IANA 366 reserves ".gnu." and thereby ensures that this label cannot be 367 registered within the DNS tree, nor their management delegated to 368 any particular organization. 370 5.2. Domain Name Reservation Considerations for ".zkey." 371 The ".zkey." domain is special according to RFC 6761, section 5 372 [RFC6761], in the following ways: 374 1. Users MAY use these names as they would other domain names, 375 entering them anywhere that they would otherwise enter a 376 conventional DNS domain name. 378 Since there is no central authority necessary or possible for 379 assigning dot-zkey names, and those names match cryptographic 380 keys, users SHOULD be aware that they do not belong to regular 381 DNS, but are still global in their scope. 383 In any case, resolution in the dot-zkey pTLD returns DNS 384 compatible results, and thus SHOULD NOT affect normal usage of 385 most Internet applications. 387 2. Application Software MAY pass requests for dot-zkey domains for 388 normal DNS resolution. If available, the local resolver MUST 389 intercept such requests within the respective operating system 390 hooks and return DNS compatible results. However, GNS-aware 391 applications MAY choose to talk directly to the respective GNS 392 resolver, and use this to access additional record types (with 393 numbers above 65535) that are not defined in DNS. 395 As mentioned in points 4. and 5. below, regular DNS resolution is 396 expected to respond with NXDOMAIN. Therefore, if it can 397 differentiate between DNS and P2P name resolution, application 398 software MAY expect such a response, and MAY choose to treat 399 other responses from the DNS as errors. 401 3. For legacy applications and legacy name resolution APIs expecting 402 DNS resolution, no changes are required. 404 However, Name Resolution APIs and Libraries MAY choose to support 405 additional record types over time for the dot-zkey names. They 406 MAY choose to directly resolve those domains via appropriate APIs 407 or mechanisms such as the GNS-specific resolution protocol. 409 4. Caching DNS servers SHOULD recognize dot-zkey names as special 410 and SHOULD NOT, by default, attempt to look up NS records for 411 them, or otherwise query authoritative DNS servers in an attempt 412 to resolve dot-zkey names. Instead, caching DNS servers SHOULD, 413 by default, generate immediate negative responses for all such 414 queries. 416 5. Authoritative DNS Servers are not expected to treat dot-zkey 417 domain requests specially. In practice, they MUST answer with 418 NXDOMAIN, as dot-zkey is not available via global DNS resolution, 419 and not doing so MAY put users' privacy at risk, e.g., as 420 suggested in the next point. 422 6. DNS Server Operators SHOULD treat requests to the dot-zkey domain 423 as errors, for correct installations MUST NOT allow such requests 424 to escape to DNS. DNS operators MUST NOT choose to redirect such 425 requests to a site, not even to explain to the user that their 426 P2P resolver is missing or mis-configured as this MAY violate 427 privacy expectations of the user. 429 7. DNS Registries/Registrars 431 In order to avoid conflicts with the P2P namespaces [SAC45], IANA 432 reserves ".zkey." and thereby ensures that this label cannot be 433 registered within the DNS tree, nor their management delegated to 434 any particular organization. 436 5.3. Domain Name Reservation Considerations for ".onion." 438 The ".onion." domain is special according to RFC 6761, section 5 439 [RFC6761], in the following ways: 441 1. Users MAY use these names as they would other domain names, 442 entering them anywhere that they would otherwise enter a 443 conventional DNS domain name. 445 Since there is no central authority necessary or possible for 446 assigning dot-onion names, and those names correspond to 447 cryptographic keys, users SHOULD be aware that they do not belong 448 to regular DNS, but are still global in their scope. 450 2. Application Software SHOULD NOT pass requests for dot-onion 451 domains for normal DNS resolution. 453 As mentioned in points 4. and 5. below, regular DNS resolution is 454 expected to respond with NXDOMAIN. Therefore, if it can 455 differentiate between DNS and P2P name resolution, application 456 software MAY expect such a response, and MAY choose to treat 457 other responses from the DNS as errors. 459 3. For legacy applications, the only way to resolve dot-onion 460 domains properly is via a SOCKS proxy. Using tools like 461 TorSocks, SOCKS support can be added to legacy applications 462 without changes to the application itself. 464 4. Caching DNS servers SHOULD recognize dot-onion names as special 465 and SHOULD NOT, by default, attempt to look up NS records for 466 them, or otherwise query authoritative DNS servers in an attempt 467 to resolve dot-onion names. Instead, caching DNS servers SHOULD, 468 by default, generate immediate negative responses for all such 469 queries. 471 5. Authoritative DNS Servers are not expected to treat dot-onion 472 domain requests specially. In practice, they MUST answer with 473 NXDOMAIN, as dot-onion is not available via global DNS 474 resolution, and not doing so MAY put users' privacy at risk, 475 e.g., as suggested in the next point. 477 6. DNS Server Operators SHOULD treat requests to the dot-onion 478 domain as errors, for correct installations MUST NOT allow such 479 requests to escape to DNS. DNS operators MUST NOT choose to 480 redirect such requests to a site, not even to explain to the user 481 that their P2P resolver is missing or mis-configured as this MAY 482 violate privacy expectations of the user. 484 7. DNS Registries/Registrars 486 In order to avoid conflicts with the P2P namespaces [SAC45], IANA 487 reserves ".onion." and thereby ensures that this label cannot be 488 registered within the DNS tree, nor their management delegated to 489 any particular organization. 491 5.4. Domain Name Reservation Considerations for ".exit." 493 The ".exit." domain is special according to RFC 6761, section 5 494 [RFC6761], in the following ways: 496 1. Users MAY use these names as they would other domain names, 497 entering them anywhere that they would otherwise enter a 498 conventional DNS domain name. 500 Since dot-exit names correspond to a Tor-specific routing 501 construct to reach target hosts via chosen Tor exit nodes, users 502 SHOULD be aware that they do not belong to regular DNS and that 503 the actual target precedes the second-level domain name. 505 2. Application Software SHOULD NOT pass requests for dot-exit 506 domains for normal DNS resolution. 508 As mentioned in points 4. and 5. below, regular DNS resolution is 509 expected to respond with NXDOMAIN. Therefore, if it can 510 differentiate between DNS and P2P name resolution, application 511 software MAY expect such a response, and MAY choose to treat 512 other responses from the DNS as errors. 514 3. For legacy applications, the only way to resolve dot-exit domains 515 properly is via a SOCKS proxy. Using tools like TorSocks, SOCKS 516 support can be added to legacy applications without changes to 517 the application itself. 519 4. Caching DNS servers SHOULD recognize dot-exit names as special 520 and SHOULD NOT, by default, attempt to look up NS records for 521 them, or otherwise query authoritative DNS servers in an attempt 522 to resolve dot-exit names. Instead, caching DNS servers SHOULD, 523 by default, generate immediate negative responses for all such 524 queries. 526 5. Authoritative DNS Servers are not expected to treat dot-exit 527 domain requests specially. In practice, they MUST answer with 528 NXDOMAIN, as dot-exit is not available via global DNS resolution, 529 and not doing so MAY put users' privacy at risk, e.g., as 530 suggested in the next point. 532 6. DNS Server Operators SHOULD treat requests to the dot-exit domain 533 as errors, for correct installations MUST NOT allow such requests 534 to escape to DNS. DNS operators MUST NOT choose to redirect such 535 requests to a site, not even to explain to the user that their 536 P2P resolver is missing or mis-configured as this MAY violate 537 privacy expectations of the user. 539 7. DNS Registries/Registrars 541 In order to avoid conflicts with the P2P namespaces [SAC45], IANA 542 reserves ".exit." and thereby ensures that this label cannot be 543 registered within the DNS tree, nor their management delegated to 544 any particular organization. 546 5.5. Domain Name Reservation Considerations for ".bit." 548 The ".bit." domain is special according to RFC 6761, section 5 549 [RFC6761], in the following ways: 551 1. Users MAY use these names as they would other domain names, 552 entering them anywhere that they would otherwise enter a 553 conventional DNS domain name. 555 From the user's perspective, the resolution of dot-bit pTLD is 556 similar to the normal DNS resolution, and thus SHOULD NOT affect 557 normal usage of most Internet applications. 559 2. Application Software MAY pass requests to the dot-bit pTLD for 560 normal DNS resolution if A/AAAA records are desired. If 561 available, the local resolver MUST intercept such requests within 562 the respective operating system hooks and return DNS compatible 563 results. However, NameCoin-aware applications MAY choose to talk 564 directly to the respective P2P resolver, and use this to access 565 additional record types that are not defined in DNS. 567 3. For legacy applications and legacy name resolution APIs expecting 568 DNS resolution, no changes are required. 570 However, Name Resolution APIs and Libraries MAY choose to support 571 additional record types over time for the dot-bit domain. They 572 MAY choose to directly resolve those domains via blockchain-based 573 resolution. 575 4. Caching DNS servers SHOULD recognize dot-bit names as special and 576 SHOULD NOT, by default, attempt to look up NS records for them, 577 or otherwise query authoritative DNS servers in an attempt to 578 resolve dot-bit names. Instead, caching DNS servers SHOULD, by 579 default, generate immediate negative responses for all such 580 queries. 582 Given that dot-bit users typically have no special privacy 583 expectations, and those names are globally unique, local caching 584 DNS servers MAY choose to treat them as regular domain names, and 585 cache the responses obtained from the Namecoin blockchain. In 586 that case however, NXDOMAIN results SHOULD NOT be cached, as new 587 dot-bit domains may become active at any time. 589 5. Authoritative DNS Servers are not expected to treat dot-bit 590 domain requests specially. In practice, they MUST answer with 591 NXDOMAIN, as dot-bit is not available via global DNS resolution. 593 6. DNS Server Operators SHOULD treat requests to the dot-bit domain 594 as errors, for correct installations SHOULD NOT allow such 595 requests to escape to DNS. 597 7. DNS Registries/Registrars 599 In order to avoid conflicts with the P2P namespaces [SAC45], IANA 600 reserves ".bit." and thereby ensures that this label cannot be 601 registered within the DNS tree, nor their management delegated to 602 any particular organization. 604 5.6. Domain Name Reservation Considerations for ".i2p." 606 The ".i2p." domain is special according to RFC 6761, section 5 607 [RFC6761], in the following ways: 609 1. Users MAY use these names as they would other domain names, 610 entering them anywhere that they would otherwise enter a 611 conventional DNS domain name. 613 Since there is no central authority responsible for assigning 614 dot-i2p names, and that the ultimate mapping is decided by the 615 local peer, users SHOULD be aware of that specificity. 617 2. Application Software SHOULD NOT pass requests for dot-i2p domains 618 for normal DNS resolution. 620 As mentioned in points 4. and 5. below, regular DNS resolution is 621 expected to respond with NXDOMAIN. Therefore, if it can 622 differentiate between DNS and P2P name resolution, application 623 software MAY expect such a response, and MAY choose to treat 624 other responses from the DNS as errors. 626 3. For legacy applications, the only way to resolve dot-i2p domains 627 properly is via a SOCKS proxy. 629 4. Caching DNS servers SHOULD recognize dot-i2p names as special and 630 SHOULD NOT, by default, attempt to look up NS records for them, 631 or otherwise query authoritative DNS servers in an attempt to 632 resolve dot-i2p names. Instead, caching DNS servers SHOULD, by 633 default, generate immediate negative responses for all such 634 queries. 636 5. Authoritative DNS Servers are not expected to treat dot-i2p 637 domain requests specially. In practice, they MUST answer with 638 NXDOMAIN, as dot-i2p is not available via global DNS resolution, 639 and not doing so MAY put users' privacy at risk, e.g., as 640 suggested in the next point. 642 6. DNS Server Operators SHOULD treat requests to the dot-i2p domain 643 as errors, for correct installations MUST NOT allow such requests 644 to escape to DNS. DNS operators MUST NOT choose to redirect such 645 requests to a site, not even to explain to the user that their 646 P2P resolver is missing or mis-configured as this MAY violate 647 privacy expectations of the user. 649 7. DNS Registries/Registrars 651 In order to avoid conflicts with the P2P namespaces [SAC45], IANA 652 reserves ".i2p." and thereby ensures that this label cannot be 653 registered within the DNS tree, nor their management delegated to 654 any particular organization. 656 6. Acknowledgements 658 The authors thank the I2P developers for their constructive feedback, 659 and Leif Ryge for his proof-reading and valuable feedback. 661 7. References 663 7.1. Normative References 665 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 666 Requirement Levels", BCP 14, RFC 2119, March 1997. 668 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 669 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 670 May 2008. 672 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 673 RFC 6761, February 2013. 675 7.2. Informative References 677 [Curve25519] 678 Bernstein, D., "Curve25519: new Diffie-Hellman speed 679 record", February 2006, 680 . 682 [Dingledine2004] 683 Dingledine, R., Mathewson, N., and P. Syverson, "Tor: the 684 second-generation onion router", 2004, . 687 [EdDSA] Bernstein, D., Duif, N., Lange, T., Schwabe, P., and Y. 688 Yang, "High-speed, high-security signatures", September 689 2011, . 691 [I2P-NAMING] 692 Random, J., "Naming in I2P and Addressbook", 2003, 693 . 695 [Namecoin] 696 The .bit Project, "Namecoin DNS - DotBIT Project", 2013, 697 . 699 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 700 L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 701 1996. 703 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 704 Encodings", RFC 4648, October 2006. 706 [SAC45] ICANN Security and Stability Advisory Committee, "Invalid 707 Top Level Domain Queries at the Root Level of the Domain 708 Name System", November 2010, . 711 [Schanzenbach2012] 712 Schanzenbach, M., "Design and Implementation of a 713 Censorship Resistant and Fully Decentralized Name System", 714 September 2012. 716 [SquareZooko] 717 Swartz, A., "Squaring the Triangle: Secure, Decentralized, 718 Human-Readable Names", 2011, 719 . 721 [TOR-ADDRESS] 722 Mathewson, N. and R. Dingledine, "Special Hostnames in 723 Tor", September 2011, . 726 [TOR-EXTSOCKS] 727 Mathewson, N. and R. Dingledine, "Tor's extensions to the 728 SOCKS protocol", September 2011, . 732 [TOR-PATH] 733 Mathewson, N. and R. Dingledine, "Tor Path Specification", 734 April 2013, . 737 [TOR-PROTOCOL] 738 Dingledine, R. and N. Mathewson, "Tor Protocol 739 Specification", November 2013, . 743 [TOR-RENDEZVOUS] 744 Mathewson, N. and R. Dingledine, "Tor Rendezvous 745 Specification", September 2013, . 749 Authors' Addresses 751 Christian Grothoff 752 TU Munich 753 Free Secure Network Systems Group 754 Lehrstuhl fuer Netzarchitekturen und Netzdienste 755 Boltzmannstrasse 3 756 Technische Universitaet Muenchen 757 Garching bei Muenchen, Bayern D-85748 758 DE 760 Email: christian@grothoff.org 762 Matthias Wachs 763 TU Munich 764 Free Secure Network Systems Group 765 Lehrstuhl fuer Netzarchitekturen und Netzdienste 766 Boltzmannstrasse 3 767 Technische Universitaet Muenchen 768 Garching bei Muenchen, Bayern D-85748 769 DE 771 Email: wachs@net.in.tum.de 772 Hellekin O. Wolf (editor) 773 GNU consensus 775 Email: hellekin@gnu.org 777 Jacob Appelbaum 778 Tor Project Inc. 780 Email: jacob@appelbaum.net