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

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 standardizing the use of domain names in the modern Internet outside of conventional DNS protocol or the public DNS database. This flexibility 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 September 12, 2019.

Copyright Notice

Copyright (c) 2019 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 (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. Current SUNR Use Cases
• 3. Guidelines for Special Use Name registration
• 4. The Special Case of Top-Level Domains
• 5. Acknowledgements
• 6. Informative References
• Author's Address

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, with many advantages in deployment and operation. 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"), 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 (or SUNR) 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 possible confusion among different uses of names within the abstract domain namespace. Issues around the use of the abstract domain namespace 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 protocol designers or software developers 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 question the default assumption that domain names and DNS-like semantics are desirable or even necessarily acceptable for new naming needs. It also doesn't discuss how one might decide whether a particular string is appropriate for use as a domain name in a particular protocol. The only thing it really requires is a description of how the proposed reserved string should be treated as "special" by DNS resolvers, domain name registrars, and so on.

Primarily RFC 6761 discusses how to make domain names and DNS-like semantics for other networking protocols compatible with the global public DNS. It's left to the protocol designer to decide whether this DNS-centric focus is appropriate for their use case.

Trying to specify how special use domain names interact with the DNS is both necessary for interoperability and helpful in thinking through the proposed "special use". So a proponent of a special use name might discover, in the course of specifying the "special use" for the SUNR, 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?")

This document acknowledges that there may be a need to separate domain names from DNS protocol in the analysis of new protocol needs. For example, RFC 6950 primarily assumes that the namespace, the database of instantiated names, and the protocol for lookup and retrieval are inextricably linked. But more recently, some 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). This poses a lot of potential interoperability risk because assumptions about DNS and domain names are so deeply embedded in the internet infrastrcuture, and it's meeting 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. Current SUNR 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 other uses of the namespace. Possible sources of such collisions include 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)

3. Guidelines for Special Use Name registration

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 SUNR, but does not control the root zone. Under RFC 2860, ICANN has that authority. More discussion on this point can be seen below, but as a practical matter, IETF Working Groups should not make such requests without compelling justification, and the IESG should not advance them without asking what other options might be available to satisfy relevant technical requirements. (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. This does impose a burden of coordination on ICANN, the IETF, and the IAB, and adds to possible confusion for developers and operators across the wider internet, so the bar to proceeding in this way should be high. There should 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 in the SUNR. 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 from 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 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 carefully considered regarding 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 have semantic meaning outside of the specific protocol or scope? 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. 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).

RFC 6761 claims that the SUNR is based on a "protocol rule" with unchallengeable precedence over ICANN policy. However, it's not clear exactly what this means in practice. There's no process for making a request to ICANN to add a TLD to the root zone, or a string to the list of names ICANN commits won't be delegated, 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.

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 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 clear, mutual understanding of what it means. There's also 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 SUNR-- 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, Olaf Kolkman, 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

Author's Address