Special-Use Domain Names for I2P

The Domain Name System (DNS) is primarily used to map human-memorable names to IP addresses, which are used for routing but generally not meaningful for humans. The Invisible Internet Project (I2P) Peer-to-Peer (P2P) system uses a specific decentralized mechanism to allocate, register, manage, and resolve names. The I2P Name System operates entirely outside of DNS, independently from the DNS root and delegation tree. As compatibility with applications using domain names is desired, the I2P overlay network defines an exclusive alternative Top-Level Domain to avoid conflict between the I2P namespace and the DNS hierarchy. In order to avoid interoperability issues with DNS as well as to address security and privacy concerns, this document registers the "I2P" Special-Use Domain Names for use with the I2P systems. I2P uses this pTLD to realize fully-decentralized and censorship-resistant naming.

Section 3 states: "[I]f a domain name has special properties that affect the way hardware and software implementations handle the name, that apply universally regardless of what network the implementation may be connected to, then that domain name may be a candidate for having the IETF declare it to be a Special-Use Domain Name and specify what special treatment implementations should give to that name. On the other hand, if declaring a given name to be special would result in no change to any implementations, then that suggests that the name may not be special in any material way, and it may be more appropriate to use the existing DNS mechanisms to provide the desired delegation, data, or lack-of-data, for the name in question. Where the desired behaviour can be achieved via the existing domain name registration processes, that process should be used. Reservation of a Special-Use Domain Name is not a mechanism for circumventing normal domain name registration processes." The Special-Use Domain Name for the I2P System (pTLDs) reserved by this document meets this requirement, as it has the following specificities: The "I2P" pTLD is not manageable by some designated administration. Instead, it is managed according to various alternate strategies as described in the I2P documentation. The "I2P" pTLD does not depend on the DNS context for its resolution. It uses I2P-specific logic for name resolution, covered by the respective system documentation. To resolve "I2P" names, the implementation MUST intercept queries for the pTLD to ensure I2P names cannot leak into the DNS. The appropriate resolution procedure can be implemented in existing software libraries and APIs to extend regular DNS operation and enable I2P name resolution. However, the default hierarchical DNS response to any request to any pTLD MUST be NXDOMAIN. Finally, in order to maximally protect the security and privacy expectation of I2P users, this document specifies desirable changes in existing DNS software and DNS operations.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . The word "peer" is used in the meaning of a individual system on the network. The abbreviation "pTLD" is used in this document to mean a pseudo Top-Level Domain, i.e., a Special-Use Domain Name per reserved to P2P Systems in this document. A pTLD is mentioned in capitals, and within double quotes to mark the difference with a regular DNS gTLD. In this document, ".tld" (lowercase, with quotes) means: any domain or hostname within the scope of a given pTLD, while .tld (lowercase, without quotes) refers to an adjective form. For example, a collection of ".i2p" peers in "I2P", but an .i2p URL. [TO REMOVE: in the IANA Considerations section, we use the simple .tld format to request TLD reservation for consistency with previous RFCs]. The word "NXDOMAIN" refers to an alternate expression for the "Name Error" RCODE as described in section 4.1.1 of . When referring to "NXDOMAIN" and negative caching response, this document means an authoritative (AA=1) name error (RCODE=3) response exclusively.

"I2P" provides accessibility to hidden services within the I2P network . I2P is a scalable, self-organizing, resilient packet switched anonymous network layer, upon which any number of different anonymity or security-conscious applications can operate, using any protocol. I2P hidden services and clients are identified by Destinations, anonymous analogues of IP addresses. The "I2P" pTLD, chosen in 2003 , houses two methods for looking up Destinations: A local table called the addressbook stores a map of .i2p addresses to Destinations. Each user maintains their own mappings that can be shared with others, allowing them to "discover" new names by importing published addressbooks of peers, and they can emulate traditional DNS by choosing to treat these peers as name servers. The comparison however stops here, as only local uniqueness is mandated. As the system is decentralized, "example.i2p" may resolve differently for different peers depending on the state of their respective addressbooks. To address globally unique names, the I2P developers dedicated the "B32.I2P" subdomain to hold Base32-encoded references to Destinations. Like .onion addresses, .b32.i2p addresses are self-authenticating. The details of the encoding are out of scope for this document, and documented in . The purpose of .b32.i2p addresses is similar to ".zkey", that is to enable (reverse) mapping for a globally unique hidden service that may not have a defined entry in the local addressbook. The "I2P" domain is special in the following ways: Users can use these names as they would other domain names, entering them anywhere that they would otherwise enter a conventional DNS domain name. Since there is no central authority responsible for assigning .i2p names, and that the ultimate mapping is decided by the local peer, users need to be aware of that specificity. Application software SHOULD recognize .i2p domains as special and SHOULD NOT use them as they would other domains. Applications SHOULD NOT pass requests for .i2p domains to DNS resolvers and libraries. As mentioned in points 4 and 5 below, regular DNS resolution is expected to respond with NXDOMAIN. Therefore, if it can differentiate between DNS and P2P name resolution, application software can expect such a response, and can choose to treat other responses from resolvers and libraries as errors. Name resolution APIs and libraries SHOULD either respond to requests for .i2p names by resolving them via the I2P protocol, or respond with NXDOMAIN. Caching DNS servers SHOULD recognize .i2p names as special and SHOULD NOT attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve .i2p names. Instead, caching DNS servers SHOULD generate immediate negative responses for all such queries. Authoritative DNS servers are not expected to treat .i2p domain requests specially. In practice, they MUST answer with NXDOMAIN, as "I2P" is not available via global DNS resolution, and not doing so MAY put users' privacy at risk (see item 6). DNS server operators SHOULD be aware that .i2p names are reserved for use with I2P, and MUST NOT override their resolution (e.g., to redirect users to another service or error information). DNS registries/registrars MUST NOT grant any request to register .i2p names. This helps avoid conflicts . These names are defined by the I2P protocol specification, and they fall outside the set of names available for allocation by registries/registrars.

Specific software performs the resolution of the I2P Special-Use Domain Names presented in this document; this resolution process happens outside of the scope of DNS. Leakage of requests to such domains to the global operational DNS can cause interception of traffic that might be misused to monitor, censor, or abuse the user's trust, and lead to privacy issues with potentially tragic consequences for the user. This document reserves these Top-Level Domain names to minimize the possibility of confusion, conflict, and especially privacy risks for users. In the introduction of this document, there's a requirement that DNS operators do not override resolution of the I2P Names. This is a regulatory measure and cannot prevent such malicious abuse in practice. Its purpose is to limit any information leak that would result from incorrectly configured systems, and to avoid that resolvers make unnecessary contact to the DNS Root Zone for such domains. Verisign, Inc., as well as several Internet service providers (ISPs) have notoriously abused their position to override NXDOMAIN responses to their customers in the past . For example, if a DNS operator would decide to override NXDOMAIN and send advertising to leaked .onion sites, the information leak to the DNS would extend to the advertising server, with unpredictable consequences. Thus, implementors should be aware that any positive response coming from DNS must be considered with extra care, as it suggests a leak to DNS has been made, contrary to user's privacy expectations. The reality of X.509 Certificate Authorities (CAs) creating misleading certificates for I2P pTLDs due to ignorance stresses the need to document their special use. Given the nature of "B32.I2P", X.509 Certificate Authorities MAY create certificates for such domains given CSRs signed with the respective private keys corresponding to the respective names.

The Internet Assigned Numbers Authority (IANA) reserved the following entries in the Special-Use Domain Names registry : .i2p [TO REMOVE: the assignement URL is https://www.iana.org/assignments/special-use-domain-names/ ]

The authors thank the I2P and Namecoin developers for their constructive feedback, as well as Mark Nottingham for his proof-reading and valuable feedback. The authors also thank the members of DNSOP WG for their critiques and suggestions.