Skip to main content

Special Use TLD Problem Statement
draft-tldr-sutld-ps-00

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 "Replaced".
Authors Ted Lemon , Ralph Droms
Last updated 2016-04-05
Replaced by draft-ietf-dnsop-sutld-ps, draft-ietf-dnsop-sutld-ps, RFC 8244
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-tldr-sutld-ps-00
Network Working Group                                           T. Lemon
Internet-Draft                                             Nominum, Inc.
Intended status: Informational                                  R. Droms
Expires: October 7, 2016                                     Cisco, Inc.
                                                           April 5, 2016

                   Special Use TLD Problem Statement
                         draft-tldr-sutld-ps-00

Abstract

   The Special-Use Domain Names registration policy in RFC 6761 has been
   shown through experience to present unanticipated challenges.  This
   memo explores current IETF and non-IETF publications relating on
   special-use TLDs, describes the history of domain names, and
   enumerates some problems that have come up in connection with the
   Special-Use Domain Names allocation process specifically as it
   related to top-level domains.

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

Lemon & Droms            Expires October 7, 2016                [Page 1]
Internet-Draft           Special-use TLD Problem              April 2016

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  The Status Quo in the IETF regarding SUTLDs . . . . . . . . .   3
     2.1.  Primary SUTLD Documents . . . . . . . . . . . . . . . . .   3
       2.1.1.  IAB Technical Comment on the Unique DNS Root  . . . .   3
       2.1.2.  Special-Use Domain Names  . . . . . . . . . . . . . .   3
     2.2.  Secondary documents relating to the SUTLD question  . . .   4
       2.2.1.  The .onion Special-Use TLD  . . . . . . . . . . . . .   4
       2.2.2.  Locally Served DNS Zones  . . . . . . . . . . . . . .   4
       2.2.3.  Name Collision in the DNS . . . . . . . . . . . . . .   5
       2.2.4.  Discovery of the IPv6 Prefix Used for IPv6 Address
               Synthesis . . . . . . . . . . . . . . . . . . . . . .   5
       2.2.5.  Additional Reserved Top Level Domains . . . . . . . .   5
     2.3.  Observations based on reading these documents . . . . . .   5
   3.  History . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   4.  Problems with Special-Use TLDs and Their Allocation . . . . .   8
     4.1.  Purity of Domain Name Architecture Problem  . . . . . . .   8
       4.1.1.  Are Domain Names DNS Names? . . . . . . . . . . . . .   8
       4.1.2.  Does Every Domain Name Have The Same Meaning
               Everywhere? . . . . . . . . . . . . . . . . . . . . .   9
       4.1.3.  Protocol Switch Problem . . . . . . . . . . . . . . .   9
     4.2.  Land Rush Problem . . . . . . . . . . . . . . . . . . . .  10
     4.3.  IESG Getting Sued Problem . . . . . . . . . . . . . . . .  10
     4.4.  Warranted Allocation Problem  . . . . . . . . . . . . . .  11
     4.5.  Experimental Squatting Problem  . . . . . . . . . . . . .  11
     4.6.  Insecure Delegation Problem . . . . . . . . . . . . . . .  12
   5.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  12
   6.  Informative References  . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   At the time of this writing, the IETF has recently been asked to
   allocate several new special-use top-level domains (SUTLDs), and has
   experienced several different sorts of problems with the process as
   documented in Special-Use Domain Names [RFC6761].  Because of this,
   the IETF has decided to investigate the problem and decide if and how
   the RFC 6761 process can be improved, or whether it should be
   deprecated.

   In order to investigate this question, this document attempts first
   to summarize the status quo, then to briefly discuss the history of
   domain names, and finally to describe the set of problems that exist

Lemon & Droms            Expires October 7, 2016                [Page 2]
Internet-Draft           Special-use TLD Problem              April 2016

   as reported by various IETF participants with experience in the
   various aspects of the problem.

2.  The Status Quo in the IETF regarding SUTLDs

   There are two primary and several secondary documents to consider
   when thinking about the SUTLD process.

2.1.  Primary SUTLD Documents

2.1.1.  IAB Technical Comment on the Unique DNS Root

   At present there are two primary documents to be aware of that
   address the topic of SUTLDs.  The first is the IAB Technical Comment
   on the Unique DNS Root [RFC2826].  This document is not an IETF
   consensus document, and appears to have bee written to address a
   different problem than the SUTLD problem.  However, it speaks
   directly to several of the key issues that must be considered, and of
   course coming as it does from the IAB, it is rightly treated with a
   great deal of authority despite not being an IETF consensus document.
   This document should be considered required reading for IETF
   participants who wish to express an informed opinion on the topic of
   SUTLDs.

2.1.2.  Special-Use Domain Names

   The second important document is Special-Use Domain Names [RFC6761].
   RFC 6761 represents the current IETF consensus on designating and
   recording SUTLDs.  The IETF has experienced problems with the
   designation process described in RFC 6761, which motivate this
   document.  Again, familiarity with this document is a prerequisite
   for having an informed opinion on the topic of SUTLDs.

   RFC 6761 defines two aspects of SUTLD: designating a domain name to
   have a special purpose and registering that special use in the
   Special-Use Domain Names registry.  The designation process is
   defined in a single sentence (RFC 6761, section 4):

      If it is determined that special handling of a name is required in
      order to implement some desired new functionality, then an IETF
      "Standards Action" or "IESG Approval" specification [RFC5226] MUST
      be published describing the new functionality.

   This sentence implies that the designation be subject to the same
   open review and consensus process as used to produce and publish all
   other IETF specifications.

Lemon & Droms            Expires October 7, 2016                [Page 3]
Internet-Draft           Special-use TLD Problem              April 2016

   The registration process is a purely mechanical process, in which the
   existence of the newly designated special use name is recorded, with
   a pointer to a section in the relevant specification document that
   defines the ways in which special handling is to be applied to the
   name.

   RFC 6761 provided the explicit designation and inclusion in the
   Special-Use Names registry for '.local' and for a set of names that
   had been previously used or defined to have special uses before the
   publication of RFC 6761.

2.2.  Secondary documents relating to the SUTLD question

   In addition to these documents, there are several others with which
   participants in this discussion should be familiar.

2.2.1.  The .onion Special-Use TLD

   The first of these is The .onion Special Use TLD [RFC7686].  This
   document is important because it is the most recent IETF action on
   the topic of SUTLDs; although it does not set new policy, the mere
   fact of its publication is worth thinking about.

   The two important points to consider about this document are that:

   o  The IETF gained consensus to publish it

   o  The situation was somewhat forced, both by the fact of its
      unilateral allocation by the TOR project without following the RFC
      6761 process, and because a deadline had been set by the CA/
      Browser Forum [SDO-CABF-INT] after which all .onion PKI
      certificates would expire and no new certificates would be issued,
      unless the .onion TLD were recognized by the IETF.

2.2.2.  Locally Served DNS Zones

   Locally Served DNS Zones [RFC6303] describes a particular use case
   for zones that exist by definition, and that are resolved using the
   DNS protocol, but that cannot have a global meaning, because the host
   IP addresses they reference are not unique.  This applies to a
   variety of addresses, including Private IPv4 addresses [RFC1918],
   Unique Local IPv6 Unicast Addresses [RFC4193] (in which this practice
   was first described) and IANA-Reserved IPv4 Prefix for Shared Address
   Space [RFC6598].

   This use case is distinct from the use-case for SUTLDs like '.local'
   and '.onion' in that the names are resolved using the DNS protocol,
   but shares the problem that such names cannot be assumed either to be

Lemon & Droms            Expires October 7, 2016                [Page 4]
Internet-Draft           Special-use TLD Problem              April 2016

   unique or to be functional in all contexts for all internet-connected
   hosts.

2.2.3.  Name Collision in the DNS

   Name Collision in the DNS [SDO-ICANN-COLL] is a study commissioned by
   ICANN that attempts to characterize the potential risk to the
   Internet of creating a registration process for new top-level domains
   that would allow corporations and persons to, for a fee, request a
   delegation for a particular top-level domain.  The document concludes
   that such allocations do present some risks, and mentions some
   specific top-level domains that present sufficient risk that they
   must never be allocated by ICANN.

2.2.4.  Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis

   Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis
   [RFC7050] is an example of a document that successfully used the RFC
   6761 process to designate '.ipv4only.arpa' as a special-use name; in
   this case the process worked smoothly and without controversy.

2.2.5.  Additional Reserved Top Level Domains

   Additional Reserved Top Level Domains
   [I-D.chapin-additional-reserved-tlds] is an example of a document
   that attempted to reserve several TLDS identified by ICANN as
   particularly at risk for collision as special-use domain names with
   no documented use.  This attempt failed, for better or for worse.

2.3.  Observations based on reading these documents

   Readers of this memo are strongly encouraged to familiarize
   themselves with the documents referenced above, and to draw their own
   conclusions.  However, for the sake of beginning the discussion, some
   observations are presented here.

   The IAB Technical note makes some important points:

   o  The Internet requires a globally unique namespace

   o  Private networks may operate private namespaces, but still require
      that names in the public namespace be globally unique.

   o  The Domain Name System [RFC1035] is not the only protocol that may
      be used for resolving domain names.

   o  Users cannot be assumed to know how to distinguish between symbols
      that have local meaning and symbols that have global meaning.

Lemon & Droms            Expires October 7, 2016                [Page 5]
Internet-Draft           Special-use TLD Problem              April 2016

      Users may therefore share symbols that incorporate domain names
      with no global meaning (for example, a URL of
      'http://mysite.example.corp', where 'example.corp' is a domain
      allocated privately and informally as described in
      [SDO-ICANN-COLL]).  Such symbols might refer to the object the
      user intends to share within that user's context, but either refer
      to some other object or objects in the recipients' context, or
      might not refer to any object at all in the recipients' context.
      The effect of this is that the user's intended communication will
      not be able to be understood by the recipients of the
      communication.  This same problem can also occur simply because a
      single user copies a name from one context in which it has one
      meaning, into a different context in which it has a different
      meaning-- for example copying a '.onion' URL out of an email
      message, where it has no meaning, into a TOR browser, where it
      does.

   There are several important conclusions that can be taken from this.
   First, domain names with unambiguous global meaning are preferable to
   domain names with local meaning which will be ambiguous.  Second, at
   least at the time of the writing of this document the IAB was of the
   opinion that there might well be more than one name resolution
   protocol used to resolve domain names.

   There are at least three important points to think of with respect to
   the RFC6761:

   o  A special-use name may be a name that should be resolved using the
      DNS protocol with no special handling.

   o  A special-use name may be a name that should be resolved using the
      DNS protocol, but requires special handling in the resolver.

   o  A special-use name may be a TLD like '.local' which acts as a
      signal to indicate that the local stub resolver should use a non-
      DNS protocol for name resolution.

   o  The current IETF consensus (from a process perspective, not
      necessarily from the perspective of what would be consensus if the
      IETF were to attempt to produce a new consensus document) is that
      both of these applications for special-use names are valid.

   It should be noted also that RFC6761 does not limit special-use names
   to TLDs.  However, at present, all special-use names registered in
   the IANA Special-Use Domain Names registry [SDO-IANA-SUDR] are either
   intended to be resolved using the DNS protocol, or are top-level
   domains, or both.  That is, at present there is no protocol switch

Lemon & Droms            Expires October 7, 2016                [Page 6]
Internet-Draft           Special-use TLD Problem              April 2016

   required by RFC6761 for names other than at the top level of the
   naming hierarchy.

   However, the obvious corrollary to this is that at present, RFC6761
   does require that stub resolvers for hosts that participate in mDNS
   [RFC6762] service discovery [RFC6763] or name resolution to use the
   presence of a special label, '.local', to indicate that mDNS, rather
   than DNS, be used to resolve names under that label.

   Neither RFC 6761 nor RFC 7686 require any kind of delegation for
   '.onion' or '.local'.  At least in the case of '.onion', it might be
   better if there were a delegation in order to limit the scope of
   leakage of '.onion' queries made to resolvers that do not know how to
   resolve '.onion' names.  However, the DNS protocol does not currently
   provide a mechanism for signaling that a particular name is not
   intended to be resolved using the DNS protocol, and it might be
   better to address that problem before defining a delegation for
   '.onion'.

3.  History

   Newcomers to the problem of resolving domain names may be under the
   mistaken impression that the DNS sprang, like the greek legend of
   Athena, directly from Paul Mockapetris' forehead.  This is not the
   case.  At the time of the writing of the IAB technical document,
   memories would have been fresh of the evolutionary process that led
   to the DNS' dominance as a protocol for domain name resolution.

   In fact, in the early days of the Internet, hostnames were resolved
   using a text file, HOSTS.TXT, which was maintained by a central
   authority, the Network Information Center, and distributed to all
   hosts on the internet using the File Transfer Protocol (FTP)
   [RFC0959].  The inefficiency of this process is cited as a reason for
   the development of the DNS [RFC1034] in 1983.

   However, the transition from HOSTS.TXT to the DNS was not smooth.
   For example, Sun Microsystems's Network Information System
   [CORP-SUN-NIS], at the time known as Yellow Pages, was an active
   competitor to the DNS, although it failed to provide a complete
   solution to the global naming problem.

   Most modern operating systems can still use the '/etc/hosts' file for
   name resolution.  Many still have a name service switch that can be
   configured on the host to resolve some domains using NIS.  Most have
   the capability to resolve names using mDNS by recognizing the special
   meaning of the '.local' SUTLD.

Lemon & Droms            Expires October 7, 2016                [Page 7]
Internet-Draft           Special-use TLD Problem              April 2016

   The Sun Microsystems model of having private domains within a
   corporate site, while supporting the global domain name system for
   off-site persisted even after the NIS protocol fell into disuse.
   Microsoft used to recommend that site administrators allocate a
   "private" top-level domain for internal use, and this practice was
   very much a part of the zeitgeist at the time.  This attitude is the
   root of the widespread practice of simply picking an unused top-level
   domain and using it for experimental purposes, which persists even at
   the time of writing of this memo.

4.  Problems with Special-Use TLDs and Their Allocation

   RFC 6761 serves two purposes.  First, it enumerates a set of domain
   names that require special treatment either by stub resolvers or by
   authority and caching name servers.  Second, it establishes a
   registry for future such names, and in section 5 it describes
   considerations for deciding when such names should be allocated.
   This has been a success in the sense that this registry now exists
   and has been used, but the stated considerations don't work for all
   use cases, and there are questions about whether this is even the
   right approach.  This section attempts to enumerate these problems in
   no deliberate order.

4.1.  Purity of Domain Name Architecture Problem

   There is some question as to whether special-use TLDs may violate the
   Domain Name System Architecture.  Much discussion has centered around
   three aspects of this question.  There is, of course, no document
   titled "The Domain Name System Architecture," so we have to rely on
   the various documents referenced earlier to consider this question.
   RFC 2826 seems to speak most directly to it.

4.1.1.  Are Domain Names DNS Names?

   The first of the three aspects of the purity question is whether
   domain names are specific to the DNS protocol.  RFC 2826 appears to
   state unequivocally that they are not.  However, many people have
   expressed the opinion that they are.  This is a question that may
   need to be explored further through the IETF process.

   At present, there are three obvious exceptions to the use of the DNS
   protocol to resolve domain names: '.onion', '.local' and any name
   that appears in /etc/hosts or the equivalent.  If indeed DNS is the
   only protocol to be used for resolving domain names, these use cases
   would have to be deprecated.

Lemon & Droms            Expires October 7, 2016                [Page 8]
Internet-Draft           Special-use TLD Problem              April 2016

4.1.2.  Does Every Domain Name Have The Same Meaning Everywhere?

   The second aspect of the purity question is the question of whether
   at any particular time, every domain name refers to the same entity
   regardless of where the query comes from.

   It has been stated by various participants in this discussion that in
   fact they do.  RFC 2862 seems to make a very strong case that to the
   extent possible they should be, but does not go so far as to insist
   that in all cases they must be.  '.onion' actually should exhibit
   this property.  However, '.local' does not.

   There are other examples of domain names that cannot be assumed to
   have the same meaning everywhere.  For example, it is not
   unreasonable for a site that uses RFC 1918 addresses to populate the
   DNS reverse lookup tree for their copy of the address space.
   Fortunately, names of this sort are rarely seen by users who do not
   understand their limited scope of applicability, making this
   exception a violation in fact but not in spirit of this principle.

   There is the additional case of names that refer to different IP
   addresses depending on the location of the host that originates the
   query.  Although at first glance this appears to be an example of the
   problem, it really is not, because the entity to which the name
   refers is the same entity, cached in different locations.

   Something similar can be said about domain names that refer to
   objects that may be harmful to devices that access them.  A caching
   resolver may refuse to answer queries for such names, or may return
   answers that differ from the answer that the name server
   authoritative for that name is returning.  Again, although this seems
   like an exception, it probably is not, because in this case the user
   who is attempting to share a reference to the entity is either
   malicious or has been duped, and in either case a failure to
   successfully share the entity is, presumably, an intended outcome
   from the perspective of the recipient of the reference.

   If it were to be determined that the principle expressed in RFC 2862
   that domain names should always refer to the same object is too weak,
   this would necessitate changing the operational model of Multicast
   DNS, and would render the use of names derived from non-unique IP
   addresses at least in principle out of bounds.

4.1.3.  Protocol Switch Problem

   The third of the three aspects of the purity question is the problem
   that if we do not resolve all domains using the same protocol, there
   has to be a mechanism for determining which protocol to use to

Lemon & Droms            Expires October 7, 2016                [Page 9]
Internet-Draft           Special-use TLD Problem              April 2016

   resolve any particular name.  If the names that must be resolved
   using different protocols all exist directly under the root of the
   namespace, this determination is relatively simple, but clearly using
   the DNS protocol for all queries would be simpler.

   An additional consideration about this aspect of the question is
   whether future resolver implementations should be required to engage
   in any behavior to determine whether a particular TLD for which they
   have no special information is a SUTLD or a normal TLD.  Also, since
   there can be privacy implications to special-use TLD queries, does it
   make sense to require that all resolvers take some action to test the
   special-use-ness of each TLD for which they are asked to resolve
   queries before sending the complete query out over the wire using the
   DNS Protocol.

4.2.  Land Rush Problem

   The land rush problem refers to the concern that has been expressed
   that if the IETF is seen to be able to allocate TLDs outside of the
   ICANN process, persons and entities who might otherwise apply to
   ICANN for the use of a particular TLD might instead apply to the
   IETF.  The concern is that this could turn into a DoS attack on the
   IESG, particularly since one option for SUTLD allocation is "IESG
   Approval."

   It is therefore important to clarify what sorts of use cases make
   sense for both the "Standards Action" and "IESG Approval."  It seems
   clear that if there are good use cases for SUTLDs, they would be in
   the production of standards that the IETF considers important, not
   for the purpose of assigning domains for normal delegation in the
   DNS.

   It is not the case that all special-use TLDs can be expected to be
   non-DNS names; for example, the Homenet Working Group is likely to
   propose the use of a special-use TLD for use on the homenet in cases
   where the homenet does not have its own globally unique name
   allocated.  This would nevertheless be resolved in the same way as an
   RFC1918 reverse query, by sending a query to the local resolver using
   the DNS protocol.

4.3.  IESG Getting Sued Problem

   An additional serious problem in allocating SUTLDs is that it exposes
   the IETF to the risk of lawsuits from interested parties.  While this
   is obviously a real risk, it is not special to the SUTLD problem--the
   IETF is always potentially at risk of being sued.  However, ICANN has
   developed a process for evaluating the issues that might arise with
   respect to the allocation of a TLD.  The IETF could in principle take

Lemon & Droms            Expires October 7, 2016               [Page 10]
Internet-Draft           Special-use TLD Problem              April 2016

   advantage of this evaluation process through the agency of the IANA,
   which at present is a function managed by ICANN.

4.4.  Warranted Allocation Problem

   The issue here is similar to the Land Rush problem: the IETF is being
   asked to evaluate whether a particular protocol use of a SUTLD
   justifies the permanent sacrifice of that name in the registry, and
   the appearance of that name in the name service protocol switches of
   various stub resolver implementations.

   Several things could be considered here.  One is that there exist
   processes for other registries where names are temporarily reserved;
   if the protocol for which they were reserved turns out to be a
   success [RFC5218], then the reservation can be made permanent.  If
   not, it's deleted from the registry.

   A corrollary to this is that if a protocol is not a success, it
   likely will not be implemented in the protocol switches of mainstream
   host operating systems.  This mitigates this aspect of the damage
   that would be caused by a mistake here.

   The final point to be made about this concern is that it is not at
   all unique to SUTLDs.  The IETF frequently produces protocols that do
   not turn out to be successes by the criteria set forth in RFC5218.
   Each of these protocol efforts began with the IETF chartering
   process, the working group consensus process, and the IETF and IESG
   review processes.  These processes do not prevent unsuccessful
   protocols from being produced, but they do very much limit the rate
   at which they are produced, and, it is to be hoped, improve the ratio
   of failures to successes.  There is no reason to think that this
   particular IANA registry is special in this regard, nor to treat it
   specially simply because we are aware of this problem.

4.5.  Experimental Squatting Problem

   One of the problems with SUTLDs is that various protocol development
   efforts find it convenient to use SUTLDs as a name service protocol
   switch precisely because such switches exist in most popular
   operating systems.  So a project will allocate a name without going
   through the RFC 6761 process, and then later on will want that
   allocation to be made permanent.  Several organizations that have
   actually done this have indicated that they looked for a process they
   could use to get a name, found RFC6761, realized it wouldn't work for
   them, found nothing else, and then just unilaterally allocated the
   name.

Lemon & Droms            Expires October 7, 2016               [Page 11]
Internet-Draft           Special-use TLD Problem              April 2016

   Precisely because of the principle stated in RFC 2826, that names
   that do not consistently refer to the same object create problems for
   end users, this creates pressure once use of the protocol becomes
   somewhat widespread, yet not widespread enough or strategic enough to
   justify allocation by the IETF, for the organization that squatted on
   the name to try to get the IETF to formalize the allocation.

   Solutions have been proposed for this problem.  There already exists
   a TLD, '.test', under which such an allocation could in principle be
   made, but no RFC exists recommending this practice.  Furthermore, RFC
   6761 recommends resolving .test using the DNS, so this isn't exactly
   the right thing for a name service protocol switch.

   A draft exists to allocate a '.alt' TLD to address this need.  The
   draft as currently written attempts to solve the whole SUTLD problem,
   but fails to do so.  This draft could easily be restricted to simply
   defining a SUTLD under which new non-DNS resolution strategies could
   be tested, and this would likely resolve the bulk of the experimental
   squatting problems that might come up in the future.

4.6.  Insecure Delegation Problem

   At present RFC 6761 doesn't give specific advice about what
   delegation, if any, should appear for newly registered SUTLDs.  It
   may be worthwhile to make a default recommendation for this.  This
   may tie in with the idea that SUTLDs should have some signal in the
   DNS that tells the resolver not to try to use DNS to resolve names
   under that TLD, even if they don't have an alternative protocol to
   try.

5.  Contributors

   This document came about as a result of conversations that occurred
   the weekend before IETF 95 in the lobby.  Stuart Cheshire, Mark
   Andrews, David Conrad, Paul Ebersman and Aaron Falk all made helpful
   and insightful observations or patiently answered questions.  This
   should not be taken as an indication that any of these folks actually
   agree with what the document says, but their generosity with time and
   thought are appreciated in any case.  Ralph started out as an
   innocent bystander, but discussion with him was the key motivating
   factor in the writing of this document, and he agreed to co-author it
   without too much arm-twisting.  And this document owes a great deal
   to Ed Lewis' excellent work on what a "domain name" is
   [I-D.lewis-domain-names].

Lemon & Droms            Expires October 7, 2016               [Page 12]
Internet-Draft           Special-use TLD Problem              April 2016

6.  Informative References

   [RFC0959]  Postel, J. and J. Reynolds, "File Transfer Protocol",
              STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985,
              <http://www.rfc-editor.org/info/rfc959>.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <http://www.rfc-editor.org/info/rfc1034>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <http://www.rfc-editor.org/info/rfc1035>.

   [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,
              <http://www.rfc-editor.org/info/rfc1918>.

   [RFC2826]  Internet Architecture Board, "IAB Technical Comment on the
              Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May
              2000, <http://www.rfc-editor.org/info/rfc2826>.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
              <http://www.rfc-editor.org/info/rfc4193>.

   [RFC5218]  Thaler, D. and B. Aboba, "What Makes For a Successful
              Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008,
              <http://www.rfc-editor.org/info/rfc5218>.

   [RFC6303]  Andrews, M., "Locally Served DNS Zones", BCP 163,
              RFC 6303, DOI 10.17487/RFC6303, July 2011,
              <http://www.rfc-editor.org/info/rfc6303>.

   [RFC6598]  Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
              M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
              Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April
              2012, <http://www.rfc-editor.org/info/rfc6598>.

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

Lemon & Droms            Expires October 7, 2016               [Page 13]
Internet-Draft           Special-use TLD Problem              April 2016

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
              <http://www.rfc-editor.org/info/rfc6763>.

   [RFC7050]  Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
              the IPv6 Prefix Used for IPv6 Address Synthesis",
              RFC 7050, DOI 10.17487/RFC7050, November 2013,
              <http://www.rfc-editor.org/info/rfc7050>.

   [RFC7686]  Appelbaum, J. and A. Muffett, "The ".onion" Special-Use
              Domain Name", RFC 7686, DOI 10.17487/RFC7686, October
              2015, <http://www.rfc-editor.org/info/rfc7686>.

   [I-D.chapin-additional-reserved-tlds]
              Chapin, L. and M. McFadden, "Additional Reserved Top Level
              Domains", draft-chapin-additional-reserved-tlds-02 (work
              in progress), March 2015.

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

   [SDO-CABF-INT]
              CA/Browser Forum, "Guidance on the Deprecation of Internal
              Server Names and Reserved IP Addresses", June 2012,
              <https://www.digicert.com/internal-names.htm>.

   [SDO-ICANN-COLL]
              Interisle Consulting Group, LLC, "Name Collisions in the
              DNS", August 2013,
              <https://www.icann.org/en/system/files/files/name-
              collision-02aug13-en.pdf>.

   [SDO-IANA-SUDR]
              Internet Assigned Numbers Authority, "Special-Use Domain
              Names registry", October 2015,
              <http://www.iana.org/assignments/special-use-domain-names/
              special-use-domain-names.xhtml>.

   [CORP-SUN-NIS]
              Sun Microsystems, "System and Network Administration",
              March 1990.

Authors' Addresses

Lemon & Droms            Expires October 7, 2016               [Page 14]
Internet-Draft           Special-use TLD Problem              April 2016

   Ted Lemon
   Nominum, Inc.
   800 Bridge Parkway
   Redwood City, California  94065
   United States of America

   Phone: +1 650 381 6000
   Email: ted.lemon@nominum.com

   Ralph Droms
   Cisco, Inc.

   Email: rdroms.ietf@gmail.com

Lemon & Droms            Expires October 7, 2016               [Page 15]