Network Working Group                                           J. Abley
Internet-Draft                                                 Dyn, Inc.
Intended status: Informational                                   P. Koch
Expires: April 21, 2016                                            DENIC
                                                               A. Durand
                                                        October 19, 2015

   Problem Statement for the Reservation of Top-Level Domains in the
                   Special-Use Domain Names Registry


   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, but which have syntactically-
   similar namespaces.

   When an end-user triggers resolution of a name on a system which
   supports multiple, different protocols for name resolution, it is
   desirable that the protocol to be used is unambiguous, and that
   requests intended for one protocol are not inadvertently addressed
   using another.

   [RFC6761] introduced a framework by which, under certain
   circumstances, a particular domain name could be acknowledged as
   being special.  This framework has been used to make top-level domain
   reservations, that is, particular top-level domains that should not
   be used within the DNS to accommodate parallel use of non-DNS name
   resolution protocols by end-users and avoid the possibility of
   namespace collisions.

   Various challenges have become apparent with this application of the
   guidance provided in [RFC6761].  This document aims to document those
   challenges in the form of a problem statement, 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

Abley, et al.            Expires April 21, 2016                 [Page 1]

Internet-Draft     Top-Level/Special-Use Domain Names       October 2015

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   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 April 21, 2016.

Copyright Notice

   Copyright (c) 2015 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
   ( 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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  RFC6761 . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Architectural considerations  . . . . . . . . . . . . . . . .   5
   5.  Technical considerations  . . . . . . . . . . . . . . . . . .   6
   6.  Organizational considerations . . . . . . . . . . . . . . . .   7
     6.1.  Non-exhaustive list of external organizational
           considerations  . . . . . . . . . . . . . . . . . . . . .   7
     6.2.  IETF Internal considerations  . . . . . . . . . . . . . .   8
       6.2.1.  Process . . . . . . . . . . . . . . . . . . . . . . .   8
       6.2.2.  Technical criteria  . . . . . . . . . . . . . . . . .   8
       6.2.3.  Name evaluation . . . . . . . . . . . . . . . . . . .   9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     10.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Appendix A.  Editorial Notes  . . . . . . . . . . . . . . . . . .  11
     A.1.  Venue . . . . . . . . . . . . . . . . . . . . . . . . . .  11
     A.2.  Pithy Quotes from History . . . . . . . . . . . . . . . .  11
     A.3.  Change History  . . . . . . . . . . . . . . . . . . . . .  12
       A.3.1.  draft-adpkja-special-names-problem-00 . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

Abley, et al.            Expires April 21, 2016                 [Page 2]

Internet-Draft     Top-Level/Special-Use Domain Names       October 2015

1.  Terminology

   Clear and unambiguous use of terminology is important for the clear
   formulation of any problem statement.  The DNS protocol suffers from
   imprecise and overloaded terminology (e.g. see
   [I-D.ietf-dnsop-dns-terminology]) without confusing matters further
   with terms and concepts from other naming systems that are similar,
   but different.

   In the interests of clarity, the following terms used in this
   document are to be interpreted as follows:

      Aardvark (n): a medium-sized, burrowing, nocturnal mammal native
      to Africa; the only living species of the order Tubulidentata.
      See <>.  This is a

      Registry (n): the Special-Use Domain Names Registry created by
      [RFC6761] and published at <

   [This section to be completed following review and refinement of the
   rest of the text.]

2.  Introduction

   In recent years, using the last label of a domain name (aka TLD) as
   switch to indicate how to treat name resolution has been experimented
   using the framework of [RFC6761].  Examples of such switches include:
   .example (don't resolve), .local (use mDNS), .onion (use tor), any
   TLD registered in IANA-maintained root-zone (use DNS).

   Such usage, which a few commenters have referred to as "protocol
   switching," is not limited to "protocol switch" in the strict sense
   of indicating specific protocols on the wire.  It could indicate to
   switch to another name space (eg .onion), use a different protocol
   (eg tor, or mdns), or indicate to use a local DNS scope by not using
   the DNS root for name resolution (eg .home in homenet) or something
   else altogether.

   This switch practice is not explicitly documented anywhere.  Indeed,
   the full semantics of domain names isn't really documented anywhere
   either, although [Ed Lewis domain-names draft] is a current attempt
   to catalog the precedents.

   [RFC6761] defines ways to reserve domain names and is now used to
   augment the technical exemption made in [RFC2860] (IETF-ICANN MoU):

Abley, et al.            Expires April 21, 2016                 [Page 3]

Internet-Draft     Top-Level/Special-Use Domain Names       October 2015

      "Note that (a) assignments of domain names for technical uses
      (such as domain names for inverse DNS lookup), (b) assignments of
      specialized address blocks (such as multicast or anycast blocks),
      and (c) experimental assignments are not considered to be policy
      issues, and shall remain subject to the provisions of this
      Section 4."

   The discussions in the DNSOP WG and the IETF Last Call processes
   about the .onion registration in the Special Use Domain Names
   registry (1,200 messages) have made it apparent that clarity about if
   and how to treat this "protocol switching" practice would help a lot
   in deciding the merit of future similar applications.  One possible
   outcome of the discussion would be to decline to recognize such usage
   of domain names in the architecture, another one is to formalize it
   and understand better the issues that come with it.

3.  RFC6761

   In Section 5, [RFC6761] describes seven questions to be answered in
   order to provide clear guidance about how and why a particular domain
   name is special.  These seven questions can be broadly categorized as

   1.  impact on end-users;

   2.  impact on applications;

   3.  impact on name resolution APIs and libraries;

   4.  impact on recursive resolvers;

   5.  impact on authoritative DNS servers;

   6.  impact on DNS server operators;

   7.  impact on DNS registries and registrars.

   Answers to these seven questions provide guidance to the
   corresponding seven audiences on how to handle a special-use domain
   name once it has been reserved by inclusion in the Registry.
   However, they are inadequate for making the determination whether a
   particular domain name qualifies as being special in the first place.

   This memo proposes to categorize considerations related to switches
   in 3 categories: Architectural, Technical and Organizational.  This
   memo then lists a number of questions to drive the discussion.  The
   list of issues discussed here is non-exhaustive.

Abley, et al.            Expires April 21, 2016                 [Page 4]

Internet-Draft     Top-Level/Special-Use Domain Names       October 2015

4.  Architectural considerations

   The first thing to consider in this discussion is that not all names
   (or domain names) are par of the Domain Name System.  See [ID-lewis-
   domain-names] for an in-depth discussion on this topic.

   At the time of writing, three top-level domain names reserved by
   inclusion in the Registry are used by name resolution protocols other
   than the DNS:

      LOCALHOST is used to refer to the host on which the name
      resolution takes place, without reference to the DNS;

      LOCAL is used by the Multicast DNS protocol specified in [RFC6762]
      which is similar in some respects to the DNS, but which uses
      different well-known port number and is limited to a particular
      multicast scope;

      ONION is used to construct names that designate anonymous hidden
      services reachable via the Tor network using onion routing.

   The three name resolution protocols described above are, to varying
   degrees, different from the DNS, and the namespaces used in each
   naming scheme are also different (albeit similar, in some cases).
   The top-level label is effectively being used as a name resolution
   protocol identifier.  The lack of a more elegant way to specify a
   name resolution protocol in (for example) a URI amounts to an
   architectural oversight.  However, it is not clear that this is still
   a problem that can be solved; it could be argued that in the absence
   of a more elegant alternative, a pragmatic choice to embed protocol
   selectors as namespace tokens has effectively already been made.  The
   running code and effective consensus in how it should be used by
   significant user bases should not be discounted.  Although the
   reservation of names in the DNS namespace can be made at any level,
   the three examples above demonstrate use-cases for reservation at the
   top-level, and hence that case must be considered.

   In [RFC2826] the IAB noted that

      "To remain a global network, the Internet requires the existence
      of a globally unique public name space.  The DNS name space is a
      hierarchical name space derived from a single, globally unique

      "Maintaining a globally-unique public namespace that supports
      different name resolution protocols is hence an architectural
      requirement, and some facility for reservation of top-level
      domains in the DNS is necessary."

Abley, et al.            Expires April 21, 2016                 [Page 5]

Internet-Draft     Top-Level/Special-Use Domain Names       October 2015

   If we accept the notion that the most significant label of a domain
   name is actually a protocol switch, it implies that we are actually
   building a catalog of all top level domains that explain which are
   are switches.  Note that such a catalog does not formally exist
   today.  It may remain a concept to guide this discussion or be
   implemented as an actual IANA registry.  In effect, it associates
   TLDs with indications on how applications and resolvers should treat

   It should also be noted that there are other choice than using the
   most significant label for a protocol switch.  In particular, a
   proposal to move those protocol switches under a specific top level
   domain has been discussed (.ALT).  If that architecture choice is
   made, some of the questions listed in the sections bellow would
   become moot.

   Note: [RFC6761] mentions the reserved names could be any label in any
   random string, not just the rightmost one (or ones).  However, this
   creates a number of complications and has not seen much support in
   the community as of now.

5.  Technical considerations

   Each of the seven questions posed by [RFC6761] has the potential to
   expose special handling of particular names in applications by a
   particular audience.  However, it is not clear what any of those
   audiences might reasonably expect as a result of a successful request
   to add a top-level domain to the Registry.

   For example, reservation of a top-level domain by the IETF does not
   guarantee that DNS queries for names within a reserved domain will
   not be sent over the Internet.  The requirements of the operators of
   recursive resolvers in the DNS cannot be relied upon to be
   implemented; the impact on the operators of DNS authoritative servers
   hence cannot be reliably assumed to be zero.  In the case of [I-
   D.ietf-dnsop-onion-tld], leakage of ONION queries on the Internet
   might lead to disclosure of private information that, in some cases,
   might pose a risk to the personal safety of end-users.

   At the time of writing, the [RFC6761] registry does not include
   direct guidance for any of the seven audiences, relying instead upon
   a reference for each entry in the Registry to the document that
   requested its insertion.  Such documents might well be opaque to many
   readers ([RFC6762] is a seventy-page protocol specification, for
   example, which is arguably not the most expressive way to set
   expectations of non-technical end-users).

Abley, et al.            Expires April 21, 2016                 [Page 6]

Internet-Draft     Top-Level/Special-Use Domain Names       October 2015

   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.

   Here is a non-exhaustive list of additional questions that have
   surfaced in discussion of requests for names to be added to the
   Special Use Names registry:

      What does it mean to have a "non-DNS" entry in the registry
      described above?

      Are applications supposed to check that registry to know what to

      Can/Should applications do this check dynamically?

      What if an application makes this dynamic check and realizes the
      name contains a switch it does not know how to treat?

   Similar questions applies to resolvers (DNS and non-DNS), what is the
   expected behavior?

6.  Organizational considerations

   Organizational considerations can be broken down in two categories,
   internal and external.

6.1.  Non-exhaustive list of external organizational considerations

   The policy surrounding the implementation and management of top-level
   domains in the DNS has been developed using a multi-stakeholder
   process convened by ICANN according to the MoU between ICANN and IETF

   Whilst discussing the particular attributes that make a domain name
   special, [RFC6761] notes that "the act of defining such a special
   name creates a higher-level protocol rule, above ICANN's management
   of allocatable names on the public Internet."

   Using top level domains as protocol switches blurs the line expressed
   in [RFC2860] between what is policy vs what is technical.  In
   particular, if the IETF formalizes this concept in the Internet
   architecture, coordination will be require between ICANN and IETF on
   such names.  Using the analogy described above of a catalog/registry
   of such switches, care must be applied to make sure we do not end up

Abley, et al.            Expires April 21, 2016                 [Page 7]

Internet-Draft     Top-Level/Special-Use Domain Names       October 2015

   with 2 process streams allowed to create entries without some form of

6.2.  IETF Internal considerations

6.2.1.  Process

   [RFC6761] specifies the way in which "an IETF 'Standards Action' or
   'IESG Approval' document" should present answers to the questions
   described above (see Section 2), but does not describe the process by
   which the answers to those questions should be evaluated.

   For example, it is not clear who is responsible for carrying out an
   evaluation.  A document which requests additions to the Registry
   might be performed by the IESG, by the IAB, by the DNSOP working
   group, by an ad-hoc working group, by expert review or any
   combination of those approaches.  [RFC6761] provides no direction.

   As an illustration of the inconsistency that has been observed
   already, [RFC6762] was published as an AD-sponsored individual
   submission in the INT area, and the IESG evaluation record does not
   reveal any discussion of the reservation of the LOCAL top-level
   domain in the DNS.  [I-D.ietf-dnsop-onion-tld], however, was
   published as a working group document through DNSOP, and an extensive
   discussion by both the participants of DNSOP and the IESG on the
   merits of the request took place.  The evaluation process, in the
   absence of clear direction, is demonstrably inconsistent.

   At the time of writing, the DNSOP working group charter does not
   clearly indicate that DNSOP is the proper venue for the evaluation to
   be carried out, although it also says that matters regarding the
   namespace are on topic.  Also, as pointed out in section 3.2), we are
   not dealing with a DNS-only issue, but also with an application
   issue.  It is not clear at all if a DNS-centric venue such as DNSop
   is the right one to examine the merits of [RFC6761] candidates.

6.2.2.  Technical criteria

   Regardless of the actual name being proposed as protocol switch, it
   is also not clear what technical criteria should the evaluation body
   use to examine the merit of an application for such a reserved name/
   protocol switch.  For example, is large scale prior deployment an
   acceptable criteria?

Abley, et al.            Expires April 21, 2016                 [Page 8]

Internet-Draft     Top-Level/Special-Use Domain Names       October 2015

6.2.3.  Name evaluation

   With regard to the actual choice of name, [RFC6761] is silent.  The
   answers to the seven questions are expected to tell how a name,
   presumably already chosen outside of the process, might be handled if
   it's determined to be a "special use" name but is silent on how to
   choose a name or how to evaluate a specific proposed name.

   Going back to the previous point of prior usage of the protocol, in
   the case of LOCALHOST, LOCAL and ONION, those particular domain names
   were already in use by a substantial population of end-users at the
   time they were requested to be added to the Registry.  Rightly or
   not, the practical cost of a transition was argued as a justification
   for their inclusion in the registry.  However, when formulating a
   general process for future such reservations, such prior use of
   particular names may or may not be the approach the IETF wants to

   The following questions should be discussed by the IETF:

      Is there a need to reserve any name, as long as it is unique, or
      is there any technical reason to reserve a particular name?

      Are non-technical reasons to reserve a "specific" name acceptable?

      Is demonstrated prior-usage of a specific name a valid rationale?

   When processing gTLD applications, ICANN has a process to review
   those to check if the proposed names are potentially offensive to
   certain communities, have political ramifications, etc.. It is worth
   asking if the IETF should have a similar process in place to evaluate
   specific proposed reserved names, and, if so, how such process would
   be implemented, and how appeals should be handled?

7.  Security Considerations

   This document aims to provide a problem statement that will inform
   future work.  Whilst security and privacy are fundamental
   considerations, this document expects that that future work will
   include such analysis, and hence no attempt is made to do so here.

8.  IANA Considerations

   This document has no IANA actions.

Abley, et al.            Expires April 21, 2016                 [Page 9]

Internet-Draft     Top-Level/Special-Use Domain Names       October 2015

9.  Acknowledgements

   Your name here, etc.

10.  References

10.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <>.

   [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,

   [RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
              RFC 6761, DOI 10.17487/RFC6761, February 2013,

10.2.  Informative References

              Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
              Terminology", draft-ietf-dnsop-dns-terminology-05 (work in
              progress), September 2015.

              Appelbaum, J. and A. Muffett, "The .onion Special-Use
              Domain Name", draft-ietf-dnsop-onion-tld-01 (work in
              progress), September 2015.

              Lewis, E., "Domain Names", draft-lewis-domain-names-01
              (work in progress), September 2015.

   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
              and E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,

Abley, et al.            Expires April 21, 2016                [Page 10]

Internet-Draft     Top-Level/Special-Use Domain Names       October 2015

   [RFC2826]  Internet Architecture Board, "IAB Technical Comment on the
              Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May
              2000, <>.

   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              DOI 10.17487/RFC6762, February 2013,

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 working group.

A.2.  Pithy Quotes from History

      The question has arisen as to how the toplevel naming authority
      decides who gets a toplevel name and who must get by with a non-
      toplevel name.  The suggestion was made by MOCKAPETRIS@USC-ISIF
      that perhaps the existing toplevel nameholders might vote on
      whether the applicant for a new toplevel name should be granted,
      with a majority needed for approval.  It seems to me this might
      produce a clique whereby whoever initially gains power will hold
      it and prevent its "enemies" from getting in too.  This will make
      the toplevel rather less than universal.

   (E-mail from Robert Elton Maas to the namedroppers mailing list on 9
   November 1983)

      My basic point is that as a world-wide network evolves it is
      ridiculous to force people to name resources in terms of one
      static hierarchy which very closely resembles the current
      internetwork topology (as the current scheme does).  What we are
      eventually going to require is a distributed expert for making
      sense out of a name someone hands it.  There will be no simple
      algorithm to be written on one page of an RFC that will suffice to
      resolve a name.  Rather, a number of heuristics will let a
      resolver make sense out of a given name by querying other experts
      which it suspects may be more knowledgeable about the name than it
      is, or by forwarding a piece of mail to an expert which is at
      least one level closer to the destination in some hierarchy.

   (E-mail from Peter Karp to the namedroppers mailing list on 8
   February 1984)

Abley, et al.            Expires April 21, 2016                [Page 11]

Internet-Draft     Top-Level/Special-Use Domain Names       October 2015

A.3.  Change History

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

   Initial draft circulated for comment.

Authors' Addresses

   Joe Abley
   Dyn, Inc.
   103-186 Albert Street
   London, ON  N6A 1M1

   Phone: +1 519 670 9327

   Peter Koch


   Alain Durand


Abley, et al.            Expires April 21, 2016                [Page 12]