Skip to main content

Problem Statement for the Reservation of Top-Level Domains in the Special-Use Domain Names Registry
draft-adpkja-dnsop-special-names-problem-05

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Geoff Huston , Peter Koch , Alain Durand , Warren "Ace" Kumari
Last updated 2016-06-29
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-adpkja-dnsop-special-names-problem-05
Network Working Group                                          G. Huston
Internet-Draft                                                     APNIC
Intended status: Informational                                   P. Koch
Expires: December 31, 2016                                      DENIC eG
                                                               A. Durand
                                                                   ICANN
                                                               W. Kumari
                                                                  Google
                                                           June 29, 2016

   Problem Statement for the Reservation of Top-Level Domains in the
                   Special-Use Domain Names Registry
              draft-adpkja-dnsop-special-names-problem-05

Abstract

   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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any

Huston, et al.          Expires December 31, 2016               [Page 1]
Internet-Draft     Top-Level/Special-Use Domain Names          June 2016

   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 31, 2016.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction: DNS, Name space or Name Spaces, Name Resolution
       Protocols . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  IETF RFC6761 Special Names  . . . . . . . . . . . . . . . . .   3
   3.  Issues with RFC 6761 Itself . . . . . . . . . . . . . . . . .   4
   4.  Issues with Evaluating Candidate String and Relationship to
       the ICANN Process . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Appendix A.  Editorial Notes  . . . . . . . . . . . . . . . . . .   8
     A.1.  Venue . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     A.2.  Change History  . . . . . . . . . . . . . . . . . . . . .   8
       A.2.1.  draft-adpkja-special-names-problem-00 . . . . . . . .   8
   Appendix B.  Change history . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction: DNS, Name space or Name Spaces, Name Resolution
    Protocols

   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

Huston, et al.          Expires December 31, 2016               [Page 2]
Internet-Draft     Top-Level/Special-Use Domain Names          June 2016

   been obsoleted by the DNS in the late 1990s.  More information on the
   history of names and namespaces can be found in
   [I-D.lewis-domain-names].

   More recently, new name resolution protocols have been proposed, each
   addressing a particular need or a particular community.  For example,
   the DONA handle system [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.

   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 [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 '*'.

   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.

2.  IETF RFC6761 Special Names

   The IETF used a provision from the IETF/ICANN MoU [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 [RFC6761] (which,
   however, does not directly refer the IETF/ICANN MoU).  The [RFC6761]

Huston, et al.          Expires December 31, 2016               [Page 3]
Internet-Draft     Top-Level/Special-Use Domain Names          June 2016

   process was first applied for .local, and the more recently for
   .onion.

   When the [RFC6761] 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 [RFC6761] process to reserve special name has many issues.  This
   document groups the issues that have been brought up in two general
   categories:

   o  Issues with [RFC6761] itself, including issues discovered during
      the evaluation of .onion

   o  Issues regarding evaluating candidate strings and the relationship
      of this process with ICANN's processes

3.  Issues with RFC 6761 Itself

   1.  [RFC6761] 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.

   2.  [RFC6761] 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.

   3.  [RFC6761] does not provide clear enough direction as to which
       group of people is responsible for carrying out the evaluation
       for inclusion in the registry.

   4.  There are ambiguities and no formal criteria on how the IETF can
       (or even whether the IETF should) evaluate the merits of
       applicants to [RFC6761] reservations.  Section 5 of [RFC6761]
       describes seven questions to be answered by an applicant for
       [RFC6761] 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 [RFC6761] treatment.

   5.  Placing a string in the [RFC6761] 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 [RFC6761]
       status cannot be guaranteed that leakage will not occur and will
       need to take this into account in their protocol design.  Useful

Huston, et al.          Expires December 31, 2016               [Page 4]
Internet-Draft     Top-Level/Special-Use Domain Names          June 2016

       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.

   6.  The [RFC6761] 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, [RFC6762] is a 70-page
       protocol specification which is not an effective way to set
       expectations of non-technical end-users.

   7.  The intended usage or protocol for which the [RFC6761]
       reservation is made may or may not be successful.  In the case of
       failure of adoption, the reserved string would be wasted.

   8.  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 [RFC6761] too difficult to deal with.
       They would like like a much simpler registration process, with
       limited or no burden to apply.

4.  Issues with Evaluating Candidate String and Relationship to the
    ICANN Process

   1.  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.

   2.  The IETF review process is not foolproof.  [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.  [RFC7788] did not
       reference [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.

   3.  There exists now at least two streams to take strings out of the
       global namespace: the IETF's special-use domain names (described
       in [RFC6761]) and ICANN's gTLD program (described at [NEW-GTLD]).
       [RFC6761] reservations happen in a ad-hoc fashion at different

Huston, et al.          Expires December 31, 2016               [Page 5]
Internet-Draft     Top-Level/Special-Use Domain Names          June 2016

       times, while ICANN's gTLD delegations typically happen in
       batches.  (The ICANN gTLD application process is described in the
       applicant guide book [GUIDEBOOK]).  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.

   4.  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.

   5.  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.

5.  Security Considerations

   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
   [SAC-057] 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.

6.  IANA Considerations

   This document has no IANA actions.

7.  Acknowledgements

   Thanks to Paul Hoffman for a large amount of editing.

8.  References

Huston, et al.          Expires December 31, 2016               [Page 6]
Internet-Draft     Top-Level/Special-Use Domain Names          June 2016

8.1.  Normative References

   [IANA-SPECIAL-USE]
              IANA, "Special-Use Domain Names", 2016,
              <https://www.iana.org/assignments/special-use-domain-
              names>.

   [RFC2860]  Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
              Understanding Concerning the Technical Work of the
              Internet Assigned Numbers Authority", RFC 2860,
              DOI 10.17487/RFC2860, June 2000,
              <http://www.rfc-editor.org/info/rfc2860>.

   [RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
              RFC 6761, DOI 10.17487/RFC6761, February 2013,
              <http://www.rfc-editor.org/info/rfc6761>.

   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              DOI 10.17487/RFC6762, February 2013,
              <http://www.rfc-editor.org/info/rfc6762>.

   [RFC7788]  Stenberg, M., Barth, S., and P. Pfister, "Home Networking
              Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
              2016, <http://www.rfc-editor.org/info/rfc7788>.

8.2.  Informative References

   [DONA]     DONA, "DONA Foundation", June 2016,
              <https://www.dona.net>.

   [FROGANS]  Frogans Technology, "Frogans Technology", June 2016,
              <https://www.frogans.org>.

   [GUIDEBOOK]
              ICANN, "gTLD Application Guidebook", June 2012,
              <https://newgtlds.icann.org/en/applicants/agb/guidebook-
              full-04jun12-en.pdf>.

   [HUSTON]   Huston, G., "What's in a Name?", December 2015,
              <http://www.circleid.com/posts/20151222_whats_in_a_name/>.

   [I-D.lewis-domain-names]
              Lewis, E., "Domain Names", draft-lewis-domain-names-02
              (work in progress), January 2016.

   [NEW-GTLD]
              ICANN, "New Generic Top-Level Domains", 2016,
              <https://newgtlds.icann.org/>.

Huston, et al.          Expires December 31, 2016               [Page 7]
Internet-Draft     Top-Level/Special-Use Domain Names          June 2016

   [SAC-057]  ICANN Security and Stability Advisory Committee, "SSAC
              Advisory on Internal Name Certificates", March 2013,
              <https://www.icann.org/en/system/files/files/sac-
              057-en.pdf>.

Appendix A.  Editorial Notes

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

A.1.  Venue

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

A.2.  Change History

A.2.1.  draft-adpkja-special-names-problem-00

   Initial draft circulated for comment.

Appendix B.  Change history

   [ RFC Editor: Please remove this section before publication]

   -05 to -04:

   o  Added two issues to the issue list: market failure and
      experimental use.

   -04 to -03:

   o  Minor edits to correct grammar, clarify that the current ICANN
      gTLD round is closed.

   -03 to -02:

   o  Significant readability changes to focus the discussion.

   -01 to -02:

   o  A very large number of readability / grammar / reference fixes
      from Paul Hoffman.

   -00 to -01:

   o  Significant readability changes.

   -00:

Huston, et al.          Expires December 31, 2016               [Page 8]
Internet-Draft     Top-Level/Special-Use Domain Names          June 2016

   o  Initial draft circulated for comment.

Authors' Addresses

   Geoff Huston
   APNIC

   Email: gih@apnic.net

   Peter Koch
   DENIC eG
   Kaiserstrasse 75-77
   Frankfurt  60329
   Germany

   Email: pk@denic.de

   Alain Durand
   ICANN

   Email: alain.durand@icann.org

   Warren Kumari
   Google

   Email: warren@kumari.net

Huston, et al.          Expires December 31, 2016               [Page 9]