<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2860 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2860.xml">
<!ENTITY rfc6761 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6761.xml">
<!ENTITY rfc6762 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6762.xml">
<!ENTITY rfc7788 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7788.xml">
<!ENTITY I-D.lewis-domain-names PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.lewis-domain-names.xml">
]>
<rfc category="info" docName="draft-adpkja-dnsop-special-names-problem-06"
ipr="trust200902">
<?rfc toc="yes" ?>

<?rfc symrefs="yes" ?>

<?rfc sortrefs="yes"?>

<?rfc iprnotified="no" ?>

<?rfc strict="yes" ?>

<front>
<title abbrev="Special-Use Domain Names">Problem Statement for
the Reservation of Special-Use Domain Names using RFC6761</title>


<author fullname="Geoff Huston" initials="G." surname="Huston">
<organization>APNIC</organization>

<address>
<email>gih@apnic.net</email>
</address>
</author>
<author fullname="Peter Koch" initials="P." surname="Koch">
<organization>DENIC eG</organization>

<address>
<postal>
<street>Kaiserstrasse 75-77</street>
<city>Frankfurt</city>
<code>60329</code>
<country>Germany</country>
</postal>
<email>pk@denic.de</email>
</address>
</author>

<author fullname="Alain Durand" initials="A." surname="Durand">
<organization>ICANN</organization>

<address>
<email>alain.durand@icann.org</email>
</address>
</author>

<author fullname="Warren Kumari" initials="W." surname="Kumari">
<organization>Google</organization>

<address>
<email>warren@kumari.net</email>
</address>
</author>

<date day="10" month="September" year="2016"/>

<abstract>
<t>
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.     
</t>
<t>
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.     
</t>
<t>
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 focuses solely on documenting the specific challenges created by RFC 6761 in the form of a problem statement in order to facilitate further discussions of potential solutions. In particular, it refrains from proposing or promoting any solution. Also, the current document does not focus on other general issues related to the use of special use domain names.
</t>
</abstract>
</front>

<middle>
<section title="Introduction: DNS, Name Space or Name Spaces, Name Resolution Protocols">
<t>
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 <xref target="I-D.lewis-domain-names"/>.
</t>
<t>
More recently, new name resolution protocols have been proposed, each addressing a particular need or a particular community. For example, the DONA handle system <xref target="DONA"/> 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.
</t>
<t>
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 in using 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  <xref target="FROGANS"/> which name space uses the character '*' to separate network names from site names and allow any character, including dots on either side of the '*'.
</t>
<t>
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.
</t>
</section>

<section title="IETF RFC6761 Special Names">
<t>
The IETF used a provision from the IETF/ICANN MoU <xref target="RFC2860"/> 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 <xref target="RFC6761"/> (which, however, does not directly refer the IETF/ICANN MoU). The <xref target="RFC6761"/> process was first applied for .local, and the more recently for .onion.
</t>
<t>When the <xref target="RFC6761"/> process was put in place, many 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.</t>
<t>
<xref target="RFC6761"/> has a number of issues. This document groups those issues in several categories.
</t>
</section>

<section title="Issues with RFC 6761 process">
<t>
<list style="letters">
<t>
<xref target="RFC6761"/> does not mention if the protocol using the reserved name should be published as an RFC document.
<list style="empty">
<t>
Most applications have, so far, come from outside organizations, and the described protocols that have not been developed by the IETF.
</t>
</list>
</t>
<t>
<xref target="RFC6761"/> does not provide clear enough directions as to which group of people is responsible for carrying out the evaluation for inclusion in the registry.
<list style="empty">
<t>
There are ambiguities and no formal criteria on how the IETF can (or even whether the IETF should) evaluate the merits of applicants to <xref target="RFC6761"/> reservations.
</t>
</list>
</t>
<t>
The "seven questions" of <xref target="RFC6761"/> are inadequate for evaluating proposals.
<list style="empty">
<t>
Section 5 of <xref target="RFC6761"/> describes seven questions to be answered by an applicant for <xref target="RFC6761"/> status. However, running this process for the .onion application showed that those seven questions are inadequate for making the determination of whether a particular string qualifies for <xref target="RFC6761"/> treatment. 
</t>
</list>
</t>
<t>
Some organizations may want to experiment with a reserved name.
<list style="empty">
<t>
They may or may not be ready (or willing) to go through a cumbersome process and find <xref target="RFC6761"/> too difficult to deal with. They would like a much simpler registration process, with limited or no burden to apply.
</t>
</list>
</t>
<t>
The <xref target="RFC6761"/> process could be abused.
<list style="empty">
<t>
In particular, the process can be abused to reserve a specific string within an existing suffix (or set of suffixes using wildcards) not under the control of IETF.
</t>
</list>
</t>
<t>
<xref target="RFC6761"/> does not have provision for subsequent management of the registry, such as updates, deletions of entries, etc...
</t>
</list>
</t>
</section>

<section title="Issues with the RFC6761 registry">
<t>
<list style="letters">
<t>
The <xref target="RFC6761"/> registry lacks sufficient documentation supporting a registration.
<list style="empty">
<t>
The registry may point to the RFC creating the reservation, but not to the supporting materials.
</t>
</list>
</t>
<t>
The <xref target="RFC6761"/> registry lacks clear directions for applications to select which name resolution method to use upon seeing the special name.
<list style="empty">
<t>
In particular, it 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, <xref target="RFC6762"/> is a 70-page protocol specification which is not an effective way to set expectations of non-technical end-users.
</t>
</list>
</t>
<t>
Reserving a string in <xref target="RFC6761"/> does not guarantee queries will not leak in the DNS.
<list style="empty">
<t>
The applicants for <xref target="RFC6761"/> status cannot be guaranteed that leakage will not occur and will need to take this into account in their protocol design.
</t>
</list>
</t>
<t>
The intended usage or protocol for which the <xref target="RFC6761"/> reservation is made may or may not be successful.
<list style="empty">
<t>
In the case of failure of adoption, the reserved string would be wasted.
</t>
</list>
</t>
</list>
</t>
</section>

<section title="Issues Around the IETF Evaluation of Candidate Strings">
<t>
<list style="letters">
<t>
The IETF does not have a formal process to evaluate candidate strings for issues such as trademark infringement and name collisions.
<list style="empty">
<t>
This leads to concerns about liability risks incurred by adding a particular string to the <xref target="RFC6761"/> registry.
</t>
</list>
</t>
<t>
Submitting the application to IETF last call does not guarantee such issues will be always caught.
<list style="empty">
<t>
<xref target="RFC7788"/> 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. <xref target="RFC7788"/> did not reference <xref target="RFC6761"/> 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. 
</t>
</list>
</t>
</list>
</t>
</section>
<section title="Other Issues Related to RFC6761">
<t>
<xref target="RFC6761"/> does not include a mechanism to collaborate with ICANN.
<list style="empty">
<t>
The current round of ICANN gTLD (described at <xref target="NEW-GTLD"/>) is, as the time of this writing, closed to new applications. It is, however, not yet completed. Some applications are still under consideration.  There is a risk that, without proper collaboration between the IETF and ICANN, a new entry in the <xref target="RFC6761"/> registry could conflict with one of those applications still under review. It should also be noted that discussions have started about forming the next round of ICANN gTLDs, thus this issue will not go away at the conclusion of the current gTLD round.
</t>
</list>
</t>
</section>

<section title="Security Considerations">
<t>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 <xref
target="SAC-057"/> for further considerations.</t>

<t>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.</t>
</section>

<section title="IANA Considerations">
<t>This document has no IANA actions.</t>
</section>

<section title="Acknowledgements">
<t>Thanks to Paul Hoffman for a large amount of editing.</t>
</section>
</middle>

<back>
<references title="Normative References">
&rfc2860;

&rfc6761;

&rfc6762;

&rfc7788;

<reference anchor="IANA-SPECIAL-USE"
target="https://www.iana.org/assignments/special-use-domain-names">
<front>
<title>Special-Use Domain Names</title>

<author>
<organization>IANA</organization>
</author>

<date year="2016"/>
</front>
</reference>
</references>

<references title="Informative References">

&I-D.lewis-domain-names;

<reference anchor="DONA"
target="https://www.dona.net">
<front>
<title>DONA Foundation</title>

<author>
<organization>DONA</organization>
</author>

<date month="June" year="2016"/>
</front>
</reference>

<reference anchor="FROGANS"
target="https://www.frogans.org">
<front>
<title>Frogans Technology</title>

<author>
<organization>Frogans Technology</organization>
</author>

<date month="June" year="2016"/>
</front>
</reference>

<reference anchor="GUIDEBOOK"
target="https://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12-en.pdf">
<front>
<title>gTLD Application Guidebook</title>

<author>
<organization>ICANN</organization>
</author>

<date month="June" year="2012"/>
</front>
</reference>

<reference anchor="HUSTON"
target="http://www.circleid.com/posts/20151222_whats_in_a_name/">
<front>
<title>What's in a Name?</title>

<author fullname="Geoff Huston" initials="G." surname="Huston">
<organization>APNIC</organization>
</author>

<date month="December" year="2015"/>
</front>
</reference>

<reference anchor="NEW-GTLD" target="https://newgtlds.icann.org/">
<front>
<title>New Generic Top-Level Domains</title>

<author>
<organization>ICANN</organization>
</author>

<date year="2016"/>
</front>
</reference>

<reference anchor="SAC-057"
target="https://www.icann.org/en/system/files/files/sac-057-en.pdf">
<front>
<title>SSAC Advisory on Internal Name Certificates</title>

<author>
<organization>ICANN Security and Stability Advisory
Committee</organization>
</author>

<date month="March" year="2013"/>
</front>
</reference>
</references>

<section title="Editorial Notes">
<t>This section (and sub-sections) to be removed prior to
publication.</t>

<section title="Venue">
<t>An appropriate forum for discussion of this draft is, for now, the
DNSOP WG.</t>
</section>

<section title="Change History">
<section title="draft-adpkja-special-names-problem-00">
<t>Initial draft circulated for comment.</t>
</section>
</section>
</section>

<section title="Change history">
<t>[ RFC Editor: Please remove this section before publication]</t>

<t>-06 to -05:</t>

<t><list style="symbols">
<t>Clarify the sole focus of this draft is to document problems created by RFC6761, and not the larger issue of NON-DNS TLDs.</t>
<t>Split issue lists and rewrite some for clarity.</t>
</list></t>


<t>-05 to -04:</t>

<t><list style="symbols">
<t>Added two issues to the issue list: market failure and experimental use.</t>
</list></t>

<t>-04 to -03:</t>

<t><list style="symbols">
<t>Minor edits to correct grammar, clarify that the current ICANN gTLD round is closed.</t>
</list></t>

<t>-03 to -02:</t>

<t><list style="symbols">
<t>Significant readability changes to focus the discussion.</t>
</list></t>

<t>-01 to -02:</t>

<t><list style="symbols">
<t>A very large number of readability / grammar / reference fixes
from Paul Hoffman.</t>
</list></t>

<t>-00 to -01:</t>

<t><list style="symbols">
<t>Significant readability changes.</t>
</list></t>

<t>-00:<list style="symbols">
<t>Initial draft circulated for comment.</t>
</list></t>
</section>
</back>
</rfc>
