| Network Working Group | J. Abley |
| Internet-Draft | Dyn, Inc. |
| Intended status: Informational | P. Koch |
| Expires: September 9, 2016 | DENIC |
| A. Durand | |
| ICANN | |
| W. Kumari | |
| March 08, 2016 |
Problem Statement for the Reservation of Top-Level Domains in the Special-Use Domain Names Registry
draft-adpkja-dnsop-special-names-problem-01
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 which supports multiple, different protocols (or resolution mechanisms) for name resolution, it is desirable that the protocol used is unambiguous, and that requests intended for one protocol are not inadvertently answered 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 twice to reserve top-level domains (.local and .onion) that should not be used within the DNS to avoid the possibility of namespace collisions in parallel use of non-DNS name resolution protocols.
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.
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 September 9, 2016.
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 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.
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 RFC7719). The use of terms and concepts from other naming systems that are similar (but different) simply confuses matters further.
In the interests of clarity, the following terms used in this document are to be interpreted as follows:
[This section to be completed following review and refinement of the rest of the text.]
A number of systems use the last label in a name to act as a switch to a different, non-DNS resolution process - examples of such switches include: .local (use mDNS) and .onion (use Tor). This switch practice is not explicitly documented anywhere, and the method for accomplishing this varies by implementation. As an interesting aside, the full semantics of domain names isn't really documented anywhere either, although [Ed Lewis domain-names draft] is a current attempt to rectify this.
This technique of using the last label as a switch has a number of properties which make it attractive to people implementing alternate name resolution systems, including:
At this point, one should note RFC6303, which already defines "locally served zones", with the important difference that per RFC6303 the names get registered for special treatment if they are already special - they are not declared special by the registration.
[RFC6761] defines ways to reserve domain names and could be read to augment the technical exemption made in [RFC2860] (IETF-ICANN MoU):
The framework in [RFC6761]RFC6761 has recently been used to reserve the .onion label, allowing it to be used as a switch to the tor resolution process[RFC7686]. By the .onion label in the "Special-Use Domain Names" registry [TODO: WK - Link], The Tor Project can be assured that there will not be a .onion TLD created in the IANA rooted DNS, and thus the possibility of collisions in the namespace will be avoided.
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 better understand the issues that come with it.
An additional consideration is that names which follow the DNS syntax (including those which use alternate name resolutions processes to the DNS) are in the same namespace as names in the DNS. This means that currently both the IETF (through [RFC6761]) and ICANN are making allocations or reservations from a shared namespace. If this continues to be the case, in order to avoid conflict, close coordination is necessary.
In Section 5, [RFC6761] describes seven questions to be answered to justify how and why a particular domain name is special. These seven questions can be broadly categorized as follows:
The intent of those seven questions was originally to serve as the justifications for *why* the special-use registration should be granted, demonstrating that it (a) provides a result that the community judges to be good, and (b) the aforementioned good result cannot reasonably be achieved in another way. The rough consensus from significant discussion was that .onion did satisfy both (a) and (b), but this was not clearly demonstrated by the answers to the "seven questions". Furthermore, it is unclear if and how these questions could reliably and unambiguously be used to make the determination, leading to the conclusion that they are generally inadequate for making the determination whether a particular domain name qualifies as requiring special/different treatment. Applications which follow the [RFC6761] process are likely to devolve into a "beauty contest". More over, the answers to the seven questions are not available in a machine readable form to applications that want to follow [RFC6761].
So the answers to these seven questions can better be seen as providing 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, and not as entrance filters for inclusion in the registry.
They specify desired behavior in the internet for handling a particular domain name, not the basis for deciding whether the effort to implement special behavior across all of those audiences is worth the cost. This indifference to costs is not necessarily scalable.
The justification in [RFC6761] is concerned with the rationale of reserving a domain name that precludes its subsequent use as a generic top level domain name. However, the document fails to offer such a rationale, and instead requires the justification of the reserved name to include the provision of guidance to a number of audiences (users, application developers, DNS resolver applications, DNS resolution service operators, and name registries and registrars) as to how to handle names that are listed in this registry. But this guidance is not, in and of itself, an adequate rationale for the selection of a particular name value to be reserved in this registry.
What is missing in [RFC6761] is the consideration of the name itself. If one were to contrast the procedures relating to the admission of a name to the IETF Special Use Name registry to the processes associated with the New gTLD Program operated by ICANN, then it is evident that the IETF process does not admit many considerations which appear to be areas of evaluation in the new gTLD program. More on this in a subsequent section.
This memo proposes to categorize considerations related to the usage of RFC6761 registry for protocol 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.
However, some voices have noted that [RFC6761] describes other alternative special handling aside from protocol switches. That alternative special handling must be considered carefully at the time of publication of the defining RFC, regardless of the nature of the special use.
The first thing to consider in this discussion is that not all names (or domain names) are part of the Domain Name System. See [ID-lewis-domain-names] for an in-depth discussion on this topic.
At the time of writing, two top-level domain names reserved by inclusion in the Registry are used by name resolution protocols other than the DNS and went through the [RFC6761] process:
The two 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 the .local case). The top-level label is effectively being used as a name resolution protocol identifier. At the core of the issue is that different "strings" that look like "domain names" (i.e. are within the same name space) but are not DNS names are used interchangeably in the URI (or URN). In particular, DNS imposes constraints on name syntax. An example of such constraints is the 64 octet limit per label. Strings used in the ONION domain do not have that constraint. 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 two examples above demonstrate use-cases for reservation at the top-level, and hence that case must be considered.
The underlying discussion here is the tussle between the applications and the network. Application architects see using special name tags (a la .onion) as an easy way to get new features deployed. They consider the hurdles of deploying new URI schemes such as http:/onion/onion-name as too onerous and too slow to deploy for their needs. Network architects worry of overloading the semantics of DNS names and/or creating a name space that is larger than the DNS namespace. They refer to bad precedents such as .uucp and .bitnet.
The fundamental point to consider here is the unicity (or multiplicity) of the name space. Are we talking about one namespace with different resolution protocols or independent name spaces?
It might it be helpful to point out that the property of interest here is the assurance of uniqueness of a name, and another way of thinking about the question is whether it applies across domain names as people expect or need it to? None of this would matter if people didn't expect names constructed according to whatever rules they're following to be unique across a set of names that spans multiple operating environments and resolution protocols.
In [RFC2826] the IAB noted that
If we were to accept the notion that the last label of a domain name is actually a protocol switch, we are actually building a catalog of all top level domains and what resolution protocol each one invokes. Note that such a catalog does not formally exist today, as [RFC6761] is an exception list to the general case which is supposed to use regular DNS as resolution protocol. Such a catalog may remain a concept to guide this discussion or be implemented as an actual IANA registry. In effect, it would associate TLDs with indications on how applications and resolvers should treat them. However, such an approach would leave open the question of not-yet-defined TLDs. No resolution mechanism could be associated with those.
It should also be noted that there are choices for a protocol switch other than reserving labels. 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 below 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.
Each of the seven questions posed by [RFC6761] has the potential to describe why special handling of the requested name(s) in applications by a particular audience may be necessary. However, aside from reserving the name, it is not entirely clear what any of those audiences might further 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 effective way to set expectations of non-technical end-users).
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:
Similar questions applies to resolvers (DNS and non-DNS); what is the expected behavior?
One particular avenue of investigation would be to see if such considerations could be encoded in machine understandable code in an extension of the current [RFC6761] registry.
Organizational considerations can be broken down in two categories, internal and external.
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 [RFC2860]. It is out of scope for this document to revisit that MoU.
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."
[RFC2860] draws a line between what is policy and what is technical. A variety of opinions have been expressed regarding whether [RFC6761] blurs this line. In particular, see http://www.circleid.com/posts/20151222_whats_in_a_name/ for a certain viewpoint on the topic. As noted earlier, it is out of scope for this document to analyse this issue beyond noting that such a variety of views exist.
Taking a different perspective, it has been argued that [RFC6761] specifically extends the DNS protocol to include special treatment for names in the registry, and that there's nothing in 2860 at all that limits the IETF's authority to change the protocol.
However, it should be noted that, if the IETF were to formalize the concept of protocol/name switch in the Internet architecture, coordination would be require between ICANN and IETF on such names. Using the analogy described above of a catalog/registry of such switches, care must be taken to make sure we do not end up with 2 process streams allowed to create entries without any synchronization.
[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.
We should point to RFC 5226 and explicitly quote the definition of "Standards Action" or "IESG Approval":
So, while it is very interesting to note that [RFC6761] was an AD sponsored individual submission in spite of two active DNS related WGs, 6762 is probably clean: it defines the protocol and is itself on standards track.
RFC 7686 however, while on standards track, does not define the TOR protocol, so it was used to fulfill the 'standards action' requirement by the letter. It contains normative references to non-IETF protocols, which is noteworthy.
A comparison of the two '7 question forms' reveals that at least the responses to questions 2, 3, and 4, differ significantly while there is no defined way to communicate the difference to the affected software entities.
An alternate view has been expressed with regard to the protocol evaluation. It states that the authority belongs to the IESG to seek whatever support it likes, within the established process, in making standards decisions, including delegating evaluation of a specific registry change proposal to a WG or a directorate. The IESG might have varied what guidance it sought, but that does not constitute "inconsistency" under the process. That being said, more complete evaluation guidance would be helpful to the IESG and the community.
Regardless of the actual name being proposed as protocol and/or namespace switch, it is also not clear what technical criteria the evaluation body should 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? A number of voices have clearly answered "no" to that question as it would only encourage "squatting" on names.
However, in the case of .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 away from the requested strings was argued as a justification for their inclusion in the registry.
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 is determined to be a “special use” name. However, it is silent on how to choose a name or how to evaluate a specific proposed name.
Section 4.3 of [RFC2860] says:
This remains as true today as when it was written (2000). Domain names have a number of considerations that have complex policy issues that ICANN deals with and which the IETF may not be well equipped to handle.
The ICANN process applicant have to go through to get a name is described in the applicant guide book https://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12-en.pdf which is a 338 page document. It should however be noted that the current round of gTLD application is closed and rules may differ in the next round if and when it happens.
Considerations include, but are not limited to:
Going back to the IETF process used for the evaluation of .local and .onion, one might ask the following questions:
ICANN has created an entire set of groups, organizations, committees, processes and procedures to deal with the evaluation of applied for new TLDs, complete with a cadre of lawyers and policy people. Unless the IETF were willing to do the same, it would have a hard time performing evaluation of the strings themselves, distinct from the evaluation of the technology behind the name resolution system.
An alternate view has been expressed, that such a process is not necessary because the IESG is the body that makes the decision on a specific name reserved by RFC6761, and the IETF has a workable appeal process to deal with any potential issues. However, looking at the level of contention created in the ICANN process around the choice of certain names, serious doubts have been expressed to the scalability and ultimate viability of such an appeal process.
This document aims to provide a problem statement that will inform future work. Whilst 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 among other places SAC-057 [https://www.icann.org/en/system/files/files/sac-057-en.pdf]
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) will garantee that such leakage will not happen. The security (or privacy) of an application MUST NOT rely on names not being exposed to the Internet DNS resolution system.
This document has no IANA actions.
Your name here, etc.
| [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. |
| [RFC7686] | Appelbaum, J. and A. Muffett, "The ".onion" Special-Use Domain Name", RFC 7686, DOI 10.17487/RFC7686, October 2015. |
| [I-D.ietf-dnsop-dns-terminology] | Hoffman, P., Sullivan, A. and K. Fujiwara, "DNS Terminology", Internet-Draft draft-ietf-dnsop-dns-terminology-05, September 2015. |
| [I-D.ietf-dnsop-onion-tld] | Appelbaum, J. and A. Muffett, "The .onion Special-Use Domain Name", Internet-Draft draft-ietf-dnsop-onion-tld-01, September 2015. |
| [I-D.lewis-domain-names] | Lewis, E., "Domain Names", Internet-Draft draft-lewis-domain-names-02, January 2016. |
| [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. |
| [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. |
This section (and sub-sections) to be removed prior to publication.
An appropriate forum for discussion of this draft is for now the dnsop working group.
(E-mail from Robert Elton Maas to the namedroppers mailing list on 9 November 1983)
(E-mail from Peter Karp to the namedroppers mailing list on 8 February 1984)
Initial draft circulated for comment.
[ RFC Editor: Please remove this section before publication]
-00 to -01:
-00: