]> APNIC

gih@apnic.net

DENIC eG

Kaiserstrasse 75-77 Frankfurt 60329 Germany pk@denic.de

ICANN

alain.durand@icann.org

Google

warren@kumari.net

The dominant protocol for name resolution on the Internet is the Domain Name System (DNS). However, other protocols exist that are fundamentally different from the DNS, and may or may not share the same namespace. When an end-user triggers resolution of a name on a system that supports multiple, different protocols or resolution mechanisms, it is desirable that the protocol used is unambiguous, and that requests intended for one protocol are not inadvertently answered using another protocol. RFC 6761 introduced a framework by which a particular domain name could be acknowledged as being special. Various challenges have become apparent with this application of the guidance provided in RFC 6761. This document aims to document those challenges in the form of a problem statement in order to facilitate further discussion of potential solutions.

For a very long time, "DNS" and "the name space" have been perceived as the same thing. However, this has not always been the case; in the past, other name resolution protocols (such as NIS, NIS+, host files, UUCP addresses, and others) were popular. Most of those have been obsoleted by the DNS in the late 1990s. More information on the history of names and namespaces can be found in . More recently, new name resolution protocols have been proposed, each addressing a particular need or a particular community. For example, the DONA handle system has been used by parts of the publication industry. The Apple "Bonjour" set of protocols, inspired by what was available on Appletalk networks, was developed to perform automatic name resolution on a local IP network. The TOR project is using the onion system to obfuscate communications, the GNU Name System (GNS) system is using block chains to build a decentralized name system to offer "privacy and censorship resistance". Many more name resolution protocols have been proposed. These alternate name resolution protocols do not exist in a vacuum. Application developers have expressed a strong desire to build their software to function in any of those universes with minimal changes. In order to do so, the software has to deterministically recognize what kind of name it is dealing with and associate it with the corresponding name resolution protocol. An algorithmic solution frequently chosen by application developers consists simply to use a special tag padded at the end of a name to indicate an alternate name resolution method. For example, if a name ends in .local, the software uses the Apple Bonjour protocol based on multicast DNS; if the name ends in .onion, it uses the TOR protocol; if the name ends in .gnu, it uses the GNS protocol, and so on. One noteworthy exception to this approach is the DONA system that has its own interoperability mechanism with the DNS. Another noteworthy exception is the Frogans technology which name space uses the character '*' to separate network names from site names and allow any character, including dots on either side of the '*'. A result of the above is that a number of applications have been developed (and massively distributed) that have encoded their favorite "tag" as a DNS TLD in a free-for-all, beginning their existence by squatting on that DNS space; .local, .gnu, .onion started out like that.

The IETF used a provision from the IETF/ICANN MoU section 4.3 that says that "(a) assignments of domain names for technical uses" is to be considered the purview of IETF (outside of the scope of ICANN) in order to create a way to reserve such names in a list of "special names". That process is documented in (which, however, does not directly refer the IETF/ICANN MoU). The process was first applied for .local, and the more recently for .onion. When the process was put in place, it was thought it would only be used a handful of times. However, a large number of applications have since been made to the IETF. The .onion evaluation took almost a year and has started a massive (and often heated) discussion in the IETF. This process to reserve special name has many issues. This document groups the issues that have been brought up in two general categories: Issues with itself, including issues discovered during the evaluation of .onion Issues regarding evaluating candidate strings and the relationship of this process with ICANN's processes

can be used to reserve any names, not just TLDs. For example, it could potentially be used to forbid a registrar to register specific names in any TLD. does not mention if the protocol using the reserved name should be published as an RFC document. Most applications have, so far, come from outside organizations, and the described protocols that have not been developed by the IETF. does not provide clear enough direction as to which group of people is responsible for carrying out the evaluation for inclusion in the registry. There are ambiguities and no formal criteria on how the IETF can (or even whether the IETF should) evaluate the merits of applicants to reservations. Section 5 of describes seven questions to be answered by an applicant for status. However, running this process for the .onion application showed that those seven questions are inadequate for making the determination for whether a particular strings qualifies for treatment. Placing a string in the registry does not guarantee that DNS queries for names within a reserved domain will not be sent over the Internet. As such, the applicant for status cannot be guaranteed that leakage will not occur and will need to take this into account in their protocol design. Useful reservations of top-level domains should be accompanied by documentation of realistic expectations of each of the seven audiences, and the evaluation of particular requests should consider the practical likelihood of those expectations being met and the implications if they are not. The registry lists the reserved names but does not include direct guidance, neither in free text form nor in machine readable instructions, for any of the seven audiences. Instead, the registry relies on a reference for each entry to the document that requested its insertion. Such documents could be difficult to read for many readers; for example, is a 70-page protocol specification which is not an effective way to set expectations of non-technical end-users. The intended usage or protocol for which the reservation is made may or may not be successful. In the case of failure of adoption, the reserved string would be wasted. Some organizations may want to experiment with a reserved name, but may or may not be ready (or willing) to go through a cumbersome process and find too difficult to deal with. They would like like a much simpler registration process, with limited or no burden to apply.

The IETF does not have process to evaluate candidate strings for issues such as trademark, name collision, and so on. Instead, the IETF relies on document reviews, working group and IETF-wide last call, and ultimately a decision is made by the IESG. That decision can be appealed, first to the IAB and second to the ISOC board of trusties. The IETF review process is not foolproof. describing the "home networking control protocol" was recently published. That document includes text instructing devices to use names terminating by default with the .home suffix. did not reference anywhere and had no IANA sections about this reservation. It was published without anyone noticing this during the entire review process. The issue was caught after the publication, and an errata was published. There exists now at least two streams to take strings out of the global namespace: the IETF's special-use domain names (described in ) and ICANN's gTLD program (described at ). reservations happen in a ad-hoc fashion at different times, while ICANN's gTLD delegations typically happen in batches. (The ICANN gTLD application process is described in the applicant guide book ). One should note that the current round of ICANN gTLD is closed to new applications, but not yet completed as some applications are still under consideration. One should note that discussions have started about forming the next round of ICANN gTLDs. There is a significant risk of conflict when both the IETF and ICANN want to register the same string, and also when they want to register similar strings. There currently is no defined mechanism for cooperation between ICANN and IETF to avoid these problems. There could be conflict if an IETF reservation were to be made during a possible future ICANN gTLD round. A hypothetical case for this would be somebody trying prevent a competitor from getting a gTLD by asking the IETF to reserve that string or a similar string.

This document aims to provide a problem statement that will inform future work. While security and privacy are fundamental considerations, this document expects that future work will include such analysis, and hence no attempt is made to do so here. See for further considerations. Reserving names has been presented as a way to prevent leakage into the DNS. However, instructing resolvers to not forward the queries (and/or by instructing authoritative servers not to respond) is not a guarantee that such leakage will be prevented. The security (or privacy) of an application MUST NOT rely on names not being exposed to the Internet DNS resolution system.

This document has no IANA actions.

Thanks to Paul Hoffman for a large amount of editing.

&rfc2860; &rfc6761; &rfc6762; &rfc7788; IANA &I-D.lewis-domain-names; DONA Frogans Technology ICANN APNIC ICANN ICANN Security and Stability Advisory Committee

This section (and sub-sections) to be removed prior to publication.

An appropriate forum for discussion of this draft is for now the DNSOP WG.

Initial draft circulated for comment.

[ RFC Editor: Please remove this section before publication] -05 to -04: Added two issues to the issue list: market failure and experimental use. -04 to -03: Minor edits to correct grammar, clarify that the current ICANN gTLD round is closed. -03 to -02: Significant readability changes to focus the discussion. -01 to -02: A very large number of readability / grammar / reference fixes from Paul Hoffman. -00 to -01: Significant readability changes. -00: Initial draft circulated for comment.