Network Working Group G. Huston
Internet-Draft APNIC
Intended status: Informational P. Koch
Expires: March 14, 2017 DENIC eG
A. Durand
W. Kumari
September 10, 2016

Problem Statement for the Reservation of Special-Use Domain Names using RFC6761


The dominant protocol for name resolution on the Internet is the Domain Name System (DNS). However, other protocols exist that are fundamentally different from the DNS, and may or may not share the same namespace.

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

RFC 6761 introduced a framework by which a particular domain name could be acknowledged as being special. Various challenges have become apparent with this application of the guidance provided in RFC 6761. This document focuses solely on documenting the specific challenges created by RFC 6761 in the form of a problem statement in order to facilitate further discussions of potential solutions. In particular, it refrains from proposing or promoting any solution. Also, the current document does not focus on other general issues related to the use of special use domain names.

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

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 March 14, 2017.

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 ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

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

For a very long time, "DNS" and "the name space" have been perceived as the same thing. However, this has not always been the case; in the past, other name resolution protocols (such as NIS, NIS+, host files, UUCP addresses, and others) were popular. Most of those have been obsoleted by the DNS in the late 1990s. More information on the history of names and namespaces can be found in [I-D.lewis-domain-names].

More recently, new name resolution protocols have been proposed, each addressing a particular need or a particular community. For example, the DONA handle system [DONA] has been used by parts of the publication industry. The Apple "Bonjour" set of protocols, inspired by what was available on Appletalk networks, was developed to perform automatic name resolution on a local IP network. The TOR project is using the onion system to obfuscate communications, the GNU Name System (GNS) system is using block chains to build a decentralized name system to offer "privacy and censorship resistance". Many more name resolution protocols have been proposed.

These alternate name resolution protocols do not exist in a vacuum. Application developers have expressed a strong desire to build their software to function in any of those universes with minimal changes. In order to do so, the software has to deterministically recognize what kind of name it is dealing with and associate it with the corresponding name resolution protocol. An algorithmic solution frequently chosen by application developers consists simply in using a special tag padded at the end of a name to indicate an alternate name resolution method. For example, if a name ends in .local, the software uses the Apple Bonjour protocol based on multicast DNS; if the name ends in .onion, it uses the TOR protocol; if the name ends in .gnu, it uses the GNS protocol, and so on. One noteworthy exception to this approach is the DONA system that has its own interoperability mechanism with the DNS. Another noteworthy exception is the Frogans technology [FROGANS] which name space uses the character '*' to separate network names from site names and allow any character, including dots on either side of the '*'.

A result of the above is that a number of applications have been developed (and massively distributed) that have encoded their favorite "tag" as a DNS TLD in a free-for-all, beginning their existence by squatting on that DNS space; .local, .gnu, .onion started out like that.

2. IETF RFC6761 Special Names

The IETF used a provision from the IETF/ICANN MoU [RFC2860] section 4.3 that says that "(a) assignments of domain names for technical uses" is to be considered the purview of IETF (outside of the scope of ICANN) in order to create a way to reserve such names in a list of "special names". That process is documented in [RFC6761] (which, however, does not directly refer the IETF/ICANN MoU). The [RFC6761] process was first applied for .local, and the more recently for .onion.

When the [RFC6761] process was put in place, many thought it would only be used a handful of times. However, a large number of applications have since been made to the IETF. The .onion evaluation took almost a year and has started a massive (and often heated) discussion in the IETF.

[RFC6761] has a number of issues. This document groups those issues in several categories.

3. Issues with RFC 6761 process

  1. [RFC6761] does not mention if the protocol using the reserved name should be published as an RFC document.

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

  3. The "seven questions" of [RFC6761] are inadequate for evaluating proposals.

  4. Some organizations may want to experiment with a reserved name.

  5. The [RFC6761] process could be abused.

  6. [RFC6761] does not have provision for subsequent management of the registry, such as updates, deletions of entries, etc...

4. Issues with the RFC6761 registry

  1. The [RFC6761] registry lacks sufficient documentation supporting a registration.

  2. The [RFC6761] registry lacks clear directions for applications to select which name resolution method to use upon seeing the special name.

  3. Reserving a string in [RFC6761] does not guarantee queries will not leak in the DNS.

  4. The intended usage or protocol for which the [RFC6761] reservation is made may or may not be successful.

5. Issues Around the IETF Evaluation of Candidate Strings

  1. The IETF does not have a formal process to evaluate candidate strings for issues such as trademark infringement and name collisions.

  2. Submitting the application to IETF last call does not guarantee such issues will be always caught.

6. Other Issues Related to RFC6761

[RFC6761] does not include a mechanism to collaborate with ICANN.

7. Security Considerations

This document aims to provide a problem statement that will inform future work. While security and privacy are fundamental considerations, this document expects that future work will include such analysis, and hence no attempt is made to do so here. See [SAC-057] for further considerations.

Reserving names has been presented as a way to prevent leakage into the DNS. However, instructing resolvers to not forward the queries (and/or by instructing authoritative servers not to respond) is not a guarantee that such leakage will be prevented. The security (or privacy) of an application MUST NOT rely on names not being exposed to the Internet DNS resolution system.

8. IANA Considerations

This document has no IANA actions.

9. Acknowledgements

Thanks to Paul Hoffman for a large amount of editing.

10. References

10.1. Normative References

[IANA-SPECIAL-USE] IANA, "Special-Use Domain Names", 2016.
[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.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013.
[RFC7788] Stenberg, M., Barth, S. and P. Pfister, "Home Networking Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2016.

10.2. Informative References

[DONA] DONA, "DONA Foundation", June 2016.
[FROGANS] Frogans Technology, "Frogans Technology", June 2016.
[GUIDEBOOK] ICANN, "gTLD Application Guidebook", June 2012.
[HUSTON] Huston, G., "What's in a Name?", December 2015.
[I-D.lewis-domain-names] Lewis, E., "Domain Names", Internet-Draft draft-lewis-domain-names-03, June 2016.
[NEW-GTLD] ICANN, "New Generic Top-Level Domains", 2016.
[SAC-057] ICANN Security and Stability Advisory Committee, "SSAC Advisory on Internal Name Certificates", March 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 WG.

A.2. Change History

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

Initial draft circulated for comment.

Appendix B. Change history

[ RFC Editor: Please remove this section before publication]

-06 to -05:

-05 to -04:

-04 to -03:

-03 to -02:

-01 to -02:

-00 to -01:


Authors' Addresses

Geoff Huston APNIC EMail:
Peter Koch DENIC eG Kaiserstrasse 75-77 Frankfurt, 60329 Germany EMail:
Alain Durand ICANN EMail:
Warren Kumari Google EMail: