Guidelines for Use of the Special Use Names Registry
draft-stw-6761ext-00

Network Working Group                                           S. Woolf
Internet-Draft                                          October 22, 2018
Intended status: Informational
Expires: April 25, 2019

          Guidelines for Use of the Special Use Names Registry
                          draft-stw-6761ext-00

Abstract

   RFC 6761 requires that proponents document how a specific name is to
   be treated within the DNS protocol, public database, and
   administrative infrastructure, but doesn't provide any guidance to
   help the community figure out whether a particular registration is
   otherwise beneficial.  This limited guidance in RFC 6761 provides
   flexibility in a difficult area-- the use of domain names in the
   modern Internet outside of conventional DNS protocol or the public
   DNS database-- which has been useful from time to time but has also
   caused significant confusion (see RFC 8244).

   This document attempts to define guidelines for the IESG and the IETF
   community on the interpretation of RFC 6761 and the use of the
   special use names registry.

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 https://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 April 25, 2019.

Copyright Notice

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

Woolf                    Expires April 25, 2019                 [Page 1]
Internet-Draft      Name Registraqtion Considerations       October 2018

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Specific guidelines . . . . . . . . . . . . . . . . . . . . .   5
   4.  More on Domain Name Hierarchy and the Special Case of Top-
       Level Domains . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Informative References  . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   From time to time, networking protocols need to be able to name
   things used within the protocol, and resolve the names created or
   referenced.  Such identifiers may also need to be persistent in time,
   across administrative and operational realms, or through other
   transformations.  Necessary operations tend to include creating,
   modifying, and deleting names, and accessing values and relationships
   that correspond to them.

   It's common for protocol designers to try to use domain names as the
   starting point for their systems of names, and the DNS as the
   starting point for name resolution.  This is completely
   understandable-- domain names, and DNS resolution, are well-
   established in the expectations of network users and developers.
   They're also well-supported by fielded software and a large public
   database of names and values, with many use cases already represented
   by example.

   However, there are some risks when the protocol designer attempts to
   re-use domain names and DNS, even (or especially) with modifications,
   to support a specific use case or protocol design or deployment
   constraint.  These have been touched upon in several RFCs, and in the
   evolution of DNS protocol itself and the use of domain names as new
   needs and constraints appear.  See in particular RFC 6055 ("IAB
   Thoughts on Encodings for Internationalized Domain Names"), RFC 6950
   ("Architectural Considerations on Application Features in the DNS"),

Woolf                    Expires April 25, 2019                 [Page 2]
Internet-Draft      Name Registraqtion Considerations       October 2018

   and RFC 6943 ("Issues in Identifier Comparison for Security
   Purposes").

   Most recently, some of these questions have become prominent in the
   course of requests for new entries in the special use names registry
   as established by RFC 6761 ("Special Use Domain Names").  The topic
   raises contention in a number of areas, including risks of collision
   between different authorities and different uses of names within the
   abstract domain namespace, which have been considered in the DNSOP WG
   over the last few years and are cataloged in RFC 8244 ("Special-Use
   Domain Names Problem Statement") at greater length than this document
   will do.

   There are compelling questions that a protocol designer or software
   developer should ask themselves about what behavior they want from
   the names they use in the context of a new protocol or scope for
   names.  However, rather than boiling that particular ocean, this
   document attempts the more practical task of of providing guidance to
   the IESG and the community to determine, in broad terms, the benefits
   and risks of a particular registration in the special use names
   registry.

   RFC 6761 establishes the use of domain names in ways that may be
   separate to their use in the DNS, but it's somewhat "DNS-centric," in
   that it doesn't discuss the use of domain names in the DNS or the
   default assumption that domain names and DNS-like semantics are
   desirable or even necessarily acceptable for new naming needs.  It's
   left to the protocol designer to decide whether this DNS-centric
   focus is appropriate for their use case.  So a proponent of a special
   use name might discover, in the course of review, that domain names
   will not meet the constraints at hand.  But even if domain names seem
   like a good fit for the problem, there's also no guidance in RFC 6761
   to deciding what names might or might not be appropriate for the
   particular need.

   The broader discussion of the general applicability of domain names
   to new needs is useful to consider, and owes a great deal to the RFCs
   already mentioned, especially RFC 6950, which "provides guidance to
   application designers and application protocol designers looking to
   use the DNS to support features in their applications."  The
   consideration there of how to structure domain names and associated
   data is invaluable.  For a different, and sometimes more
   comprehensive, view on some of the accumulated stresses on the DNS
   design, see also RFC 8324 ("DNS Privacy, Authorization, Special Uses,
   Encoding, Characters, Matching, and Root Structure: Time for Another
   Look?")

Woolf                    Expires April 25, 2019                 [Page 3]
Internet-Draft      Name Registraqtion Considerations       October 2018

   This document acknowledges that there may be a need to separate
   domain names from DNS protocol in the analysis of new protocol needs.
   RFC 6950 primarily assumes that the namespace, the database of
   instantiated names, and the protocol for lookup and retrieval are all
   of a piece, while it's become the case recently that people are
   attempting to separate the namespace from specific resolution
   protocol or even a specific instance of a database of names (namely,
   the global public Internet DNS), with varying degrees of drama and
   varying degrees of success.

   Recommended reading on the larger questions includes draft-lewis-
   domain-names.txt, [RFC1034], [RFC2826], [RFC2860], [RFC6950],
   [RFC6055], [RFC6943], [RFC6761], [RFC8244] and [RFC8324]However, this
   document will consider them out of scope for the immediate problem of
   providing guidance on the situation we're already in: RFC 6761 is an
   IETF standards-track document, the special use names registry has
   been defined, people want to use it, and some uses pose more risk to
   the interoperability of the Internet than others.

   This document is attempting to address the case where the protocol
   designer believes that something like a domain name is suitable for
   their protocol, but the use case can't be satisfied by "normal" DNS--
   the DNS wire protocol and globally-scoped domain names, resolvable in
   the public DNS database-- so some additional analysis and
   specification is needed.

2.  Use Cases

   Some specific use cases have arisen since the special use names
   registry was established:

   1.  Proponents wish to reserve a name to serve a specific purpose in
       an IETF protocol, discussed as part of protocol definition in an
       IETF working group.  Resolution of the name may be intended for a
       limited scope (homenet) or outside of the DNS altogether (mDNS,
       DNSSD)

   2.  Proponents wish to reserve a name as used in a protocol developed
       outside of the IETF, in order to avoid potential collisions with
       others uses of the namespace such as future IETF protocols or
       ICANN's policies for delegation of top-level domains. (.onion,
       RFC 7686)

   3.  Proponents wish to reserve a name from any use in the public DNS,
       in order to support interoperability and avoid collision or abuse
       ("localhost," or draft-chapin-additional-reserved-tlds)

Woolf                    Expires April 25, 2019                 [Page 4]
Internet-Draft      Name Registraqtion Considerations       October 2018

3.  Specific guidelines

   The use cases and constraints described suggest some specific
   guidelines for the IESG and the IETF community regarding the use of
   the special use names registry:

   1.  Location of a name in the namespace is a consideration.  A
       single-label name or "top level domain" can be attractive at
       first glance: they can be short and human-friendly, and there's
       no obvious need to coordinate the use of a top-level label with a
       TLD operator by, for example, purchasing the use of a second-
       level domain such as example.org.  But the reservation of a TLD
       also poses a unique challenge, whether the proponent is asking
       for it to be reserved from use in the DNS root zone, or asking
       for it to be added to the root zone: the IETF administers the
       special use name registry, but does not control the root zone.
       Under RFC 2860, ICANN has that authority.  More discussion on
       this point can be seen below, but for now the important
       observation is this: RFC 6761 claims that the registry is based
       on a "protocol rule" with unchallengeable precednce over ICANN
       policy.  However, it's not clear exactly what this means in
       practice.  There's no process for making such a request, and it
       seems likely that the effort of inventing one and coordinating it
       with ICANN would not be justified unless there was a compelling
       need that couldn't be met any other way.  IETF Working Groups
       should not make such requests, and the IESG should not advance
       them, without such a need.  (Case: home.arpa, RFC 8375)

       1.  Compatibility with an installed base *might* be a compelling
           need to reserve a specific string as a single label or TLD,
           but the bar should be *very* high, because of the imposed
           burden of coordination on ICANN, the IETF, and the IAB.
           There needs to be significant benefit to interoperability, at
           the very least.  (Case: .onion, .bit, etc.)

       2.  Preventing ICANN from delegating a name is *not*, by itself,
           a compelling reason to reserve it.  There's no written policy
           or agreement that says it would work, and ICANN may have no
           process or policy under which it could determine whether such
           a reservation should be granted.  Risking name collision
           under different policies fro different authorities seems
           unwise, but so does using standards action in one body to
           constrain policy in another.  (Case: home/corp/mail, draft-
           chapin-additional-tlds)

   2.  For names reserved as part of an IETF protocol, in a standards-
       track RFC coming out of an IETF WG, proponents should consider
       using .arpa (see the IAB note on home.arpa, and RFC 3172).  This

Woolf                    Expires April 25, 2019                 [Page 5]
Internet-Draft      Name Registraqtion Considerations       October 2018

       can work whether the name is supposed to be instantiated in the
       DNS or not, since the IAB sets policy for .arpa.  (Case:
       home.arpa)

   3.  Reserved domain names that aren't TLDs require less work for the
       community because they don't have to be coordinated with another
       body.  All such names, however, should be thought out as far as
       the characteristics discussed above: do they need to exist in the
       public DNS, or just be valid in a limited scope, or be reserved
       for another protocol? do they need to be human-friendly? etc.
       This may require adding some new questions to the RFC 6761 list,
       which talks about how the names are treated by DNS but otherwise
       not much about why they're being reserved or how they're being
       used.  (Case: home.arpa)

   4.  For names initially reserved or used outside of the IETF, for
       which a proponent wants to add a special use name registry entry,
       the bar should be just as high.  For single labels in particular,
       the IESG and the community should require both a stable
       specification and some assurance that a one-time delegation won't
       multiply as the protocol evolves or the community forks.  This
       may require a standards-track update to RFC 6761.

4.  More on Domain Name Hierarchy and the Special Case of Top-Level
    Domains

   One key question for all use cases is where in the domain name space
   a given name should go.  This is true regardless of whether the name
   is intended for resolution in the DNS or as a "protocol switch" to
   invoke another resolution mechanism.

   As noted above, all of the cases described in this document are more
   difficult if the proponents are attempting to reserve a single label
   domain name, or "TLD".  This is because the IETF delegated authority
   some time ago to ICANN for the contents of the root zone of the DNS
   (see RFC 2860).

   ICANN has its own community and its own mechanisms for deciding what
   names should be allowed (or not) in the DNS root zone, and with what
   constraints.  The IETF is not in a position to dictate ICANN's
   decisions about what names to delegate in the root zone, or even
   ICANN's policies on what names must not be delegated in the root
   zone.  It can be argued that while ICANN is not an SDO, its
   relationship to the IETF is not unlike that of an SDO with an
   overlapping interest in a protocol: while neither can dictate process
   or policy to the other, an accomodation can generally be found when
   potential conflicts appear.  In the case of the IETF and ICANN, there
   are several possible mechanisms.  The simplest is probably the IETF

Woolf                    Expires April 25, 2019                 [Page 6]
Internet-Draft      Name Registraqtion Considerations       October 2018

   liaison to the ICANN Board of Directors, for which the IAB appoints
   the liaison manager (https://www.iab.org/2018/02/07/call-for-
   nominations-ietf-liaison-to-icann-board-of-directors-2/).

   In the case of a TLD that the IETF wishes to reserve for "technical
   use" (per RFC 2860), there's no established guarantee that ICANN
   won't in the future delegate that name in the public root zone for
   the DNS.  Such a commitment could be requested by the IAB via the
   IETF liaison or some other means, but there's no assurance it would
   be obtained, or that the reserved name would be equally useful
   without such a commitment.

   It may also be the case that the IETF wishes ICANN to delegate a TLD
   in the root zone, with specific characteristics, for "technical use"
   within the DNS-- such as the requirement seen in discussion of
   home.arpa, originally specified as .home, that the name should exist
   in the root zone so that DNSSEC would work as expected in local
   environments.  Again, such a request could be made, but would place
   an even larger burden on ICANN's policies and processes than a
   request that they commit to not delegating a name at all.  There is
   no way to project how long it would take or whether it would
   ultimately succeed.

   For these reasons, the bar for the IESG and the IETF community to
   agree to request a TLD in the special use names registry-- either
   that it should never be delegated, or that it should be delegated
   accordingto conditions set by the IETF-- should be very high indeed.
   The IESG SHOULD NOT make such requests without a compelling reason
   that cannot, as a matter of technical necessity, be met by a special
   use name elsewhere in the domain name space.

5.  Acknowledgements

   This draft is the outcome of many conversations over many months,
   including discussions in the DNSOP WG, the IAB, and the ICANN SSAC.
   Particular thanks to Ed Lewis, Wendy Seltzer, Ralph Droms, Warren
   Kumari, Lyman Chapin, Dave Thaler, Brian Trammell, Ted Lemon, David
   Conrad, Andrew Sullivan, Ted Hardie, John Klensin, and everyone who's
   expressed exasperation to the author with respect to the issues
   discussed here.

6.  Informative References

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

Woolf                    Expires April 25, 2019                 [Page 7]
Internet-Draft      Name Registraqtion Considerations       October 2018

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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

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

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

   [RFC2870]  Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root
              Name Server Operational Requirements", RFC 2870,
              DOI 10.17487/RFC2870, June 2000,
              <https://www.rfc-editor.org/info/rfc2870>.

   [RFC6055]  Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on
              Encodings for Internationalized Domain Names", RFC 6055,
              DOI 10.17487/RFC6055, February 2011,
              <https://www.rfc-editor.org/info/rfc6055>.

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

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

   [RFC6943]  Thaler, D., Ed., "Issues in Identifier Comparison for
              Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May
              2013, <https://www.rfc-editor.org/info/rfc6943>.

   [RFC6950]  Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba,
              "Architectural Considerations on Application Features in
              the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013,
              <https://www.rfc-editor.org/info/rfc6950>.

Woolf                    Expires April 25, 2019                 [Page 8]
Internet-Draft      Name Registraqtion Considerations       October 2018

   [RFC7719]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
              Terminology", RFC 7719, DOI 10.17487/RFC7719, December
              2015, <https://www.rfc-editor.org/info/rfc7719>.

   [RFC8244]  Lemon, T., Droms, R., and W. Kumari, "Special-Use Domain
              Names Problem Statement", RFC 8244, DOI 10.17487/RFC8244,
              October 2017, <https://www.rfc-editor.org/info/rfc8244>.

   [RFC8324]  Klensin, J., "DNS Privacy, Authorization, Special Uses,
              Encoding, Characters, Matching, and Root Structure: Time
              for Another Look?", RFC 8324, DOI 10.17487/RFC8324,
              February 2018, <https://www.rfc-editor.org/info/rfc8324>.

Author's Address

   Suzanne Woolf
   39 Dodge St. #317
   Beverly, MA  01915
   USA

   Email: suzworldwide@gmail.com

Woolf                    Expires April 25, 2019                 [Page 9]