Network Working Group T. Lemon Internet-Draft Nominum, Inc. Intended status: Informational R. Droms Expires: December 31, 2016 Cisco, Inc. W. Kumari Google June 29, 2016 Special-Use Names Problem Statement draft-tldr-sutld-ps-01 Abstract The Special-Use Domain Names registration policy in RFC 6761 has been shown through experience to present unanticipated challenges. This memo presents a list, intended to be comprehensive, of the problems that have been identified. In addition it reviews the history of Domain Names and summarizes current IETF and non-IETF publications relating on 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 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 December 31, 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 Lemon, et al. Expires December 31, 2016 [Page 1] Internet-Draft Special-Use Names Problem June 2016 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problems associated with Special-Use Internet Names . . . . . 3 4. Existing Practice Regarding SUINs . . . . . . . . . . . . . . 5 4.1. Primary SUIN Documents . . . . . . . . . . . . . . . . . 5 4.1.1. IAB Technical Comment on the Unique DNS Root . . . . 5 4.1.2. Special-Use Domain Names . . . . . . . . . . . . . . 6 4.1.3. MoU Concerning the Technical Work of the IANA . . . . 8 4.2. Secondary documents relating to the SUTLIN question . . . 9 4.2.1. Multicast DNS . . . . . . . . . . . . . . . . . . . . 9 4.2.2. The .onion Special-Use TLD . . . . . . . . . . . . . 9 4.2.3. Locally Served DNS Zones . . . . . . . . . . . . . . 10 4.2.4. Name Collision in the DNS . . . . . . . . . . . . . . 10 4.2.5. Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis . . . . . . . . . . . . . . . . . . . . . . 10 4.2.6. Additional Reserved Top Level Domains . . . . . . . . 10 4.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Informative References . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction One of the key services required to use the Internet is name resolution. Name resolution is the process of translating a human- readable symbolic name into some object or set of objects to which the name refers, perhaps most typically one or more IP addresses. These names are often referred to as domain names, although in this document they will be referred to as internet names to avoid confusion between the names and a particular protocol for resolving these names, the Domain Name System [RFC1034]. At the time of this writing, the IETF has recently been asked to allocate several new special-use top-level internet names. In evaluating the process for additional special-use-top-level internet names as documented in Special-Use Domain Names [RFC6761], the IETF encountered several different sorts of issues. 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. Lemon, et al. Expires December 31, 2016 [Page 2] Internet-Draft Special-Use Names Problem June 2016 This document presents a list, believed to be complete, of the problems associated with the allocation of special-use names. In support of the particular set of problems described here, the document also includes documentation of existing practice as it relates to the use of internet names, as well as a brief history of domain names, and finally to describe the set of problems that exist as reported by various IETF participants with experience in the various aspects of the problem. 2. Terminology For the sake of brevity this document uses a number of abbreviations. These are expanded here: Internet Name A name which serves as input to a host's ordinary name resolution process, for example 'EXAMPLE.ORG'. SUIN Special Use Internet Name SUTLIN Special-Use Top-Level Internet Name IANA Internet Assigned Numbers Authority ICANN Internet Corporation for Assigned Names and Numbers 3. Problems associated with Special-Use Internet Names This section presents a list of problems that have been identified with respect to the allocation of special-use names. Solutions to these problems are out of scope. Because of that, problems with solutions to these problems are also out of scope, and will be covered in a separate document. No assertion is made that any of these problems is more or less important than any other. The point of this is simply to enumerate and briefly describe the problems that have been raised during the discussion of the special-use name problem. The degree of detail is intended to be sufficient that that participants in the discussion can agree that the problems they've raised have been adequately described, and no more. In addition, no assertion is made that all of these problems must be addressed; while each problem has one or more solutions, the solutions may in some cases be mutually contradictory, or may come with costs that do not justify the benefit that would be obtained from solving them. This is the list of problems: Lemon, et al. Expires December 31, 2016 [Page 3] Internet-Draft Special-Use Names Problem June 2016 o IETF and ICANN independently have remit to assign names out of the same namespace; a formal coordination process does not exist. o Although IETF and ICANN nominally have control of the namespace, neither organization can enforce that control over any third party who wants to just start using a subset of the namespace. o The namespace is useful for identifying things outside of the scope of the Domain Name System. o The IETF process for assigning names to things outside of the DNS is tortuous o There is strong resistance within the IETF to assigning names to things outside of the DNS, for a variety of reasons: * Requires a mechanism for identifying which of a set of resolution processes is required in order to resolve a particular name. * Assertion of authority: there is a sense that the namespace is "owned" by the IETF or by ICANN, and so if a name is allocated outside of that process, the person or entity that allocated that name should suffer some consequence that would, presumably, deter future circumvention of the official process. * More than one protocol is bad, in the sense that a single protocol is less complicated to implement and deploy. * If there is an IETF process through which a name can be allocated at zero cost other than time, this process will be used to circumvent the ICANN gTLD process. * Some names that might be allocated would be sufficiently generic that other legitimate uses of those names would overlap with a proposed use, so that assigning the name would preclude some future, better use of it. * If the IETF allocates a name that some third party or parties believes belongs to them in some way, the IETF could become embroiled in an expensive dispute with those parties. o In cases where assignments have been made, technical mistakes have been made due either to insufficiently well-defined process or to a failure to follow the process that was defined. Lemon, et al. Expires December 31, 2016 [Page 4] Internet-Draft Special-Use Names Problem June 2016 o In cases where names have been marked as unsafe to allocate, the actual uses of those names that led to the potential for conflict have not been documented. o No process exists for checking documents to make sure they don't accidentally assign names (e.g. RFC 7788). o Use of the registry is inconsistent--some SUTLIN RFCs specify registry entries; some don't; some specify delegation, some don't. o There exists no safe, non-process-violating mechanism for ad-hoc allocation of special-use names. The problems we have stated here represent the current understanding of the authors of the document as to the complete set of problems that have been identified during discussion by the working group on this topic. The remainder of this document provides additional context that will be needed for reasoning about these problems. 4. Existing Practice Regarding SUINs There are three primary and numerous secondary documents to consider when thinking about the Special-Use Internet Names process. 4.1. Primary SUIN Documents The primary documents are considered primary because they directly address the IETF's past thoughts on this topic in a general way, and also because they describe what the IETF does in practice. Only one of these documents is an IETF consensus document. 4.1.1. IAB Technical Comment on the Unique DNS Root This document [RFC2826] is not an IETF consensus document, and appears to have been written to address a different problem than the SUIN 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 given 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 SUINs. The main points that appear relevant to the specal use names problem are: o The Internet requires a globally unique namespace Lemon, et al. Expires December 31, 2016 [Page 5] Internet-Draft Special-Use Names Problem June 2016 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. 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 any recipient's context, or might not refer to any object at all in a recipient's 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' internet name out of a TOR browser, where it has meaning, and pasting this name into an ssh client that doesn't support connecting over TOR. [TODO: Consider "labels" instead of "symbols".] To boil this down even further, we can take the following advice from this document: o Domain names with unambiguous global meaning are preferable to domain names with local meaning which will be ambiguous. Nevertheless both globally-meaningful and locally-special names are in use and must be supported. o 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. 4.1.2. Special-Use Domain Names The second important document is Special-Use Domain Names [RFC6761]. RFC6761 represents the current IETF consensus on designating and recording SUINs. The IETF has experienced problems with the designation process described in RFC6761; these concerns motivate this document. Again, familiarity with RFC6761 is a prerequisite for having an informed opinion on the topic of SUINs. Lemon, et al. Expires December 31, 2016 [Page 6] Internet-Draft Special-Use Names Problem June 2016 RFC 6761 defines two aspects of SUINs: 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 (RFC6761, 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 any designation of a special-use name is subject to the same open review and consensus process as used to produce and publish all other IETF specifications. 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. RFC6761 provided the process whereby Multicast DNS [RFC6762]designated ".local" as a special-use name and included it in the Special-Use Names registry. It itself also enumerated a set of names that had been previously used or defined to have special uses prior to the publication of RFC6761. Since there had been no registry for these names prior to the publication of RFC 6761, the documents defining these names could not have added them to the registry. There are at least several 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. An example of this is .ARPA. o A special-use name may be a name that is resolved using the DNS protocol, requires no special handling in the stub resolver, but requires special handling in the recursive resolver. An example of this would be "10.in-addr.arpa." o A special-use name may be name that requires special handling in the stub resolver. An example would be a special-use top-level name like '.local' which acts as a signal to indicate that the local stub resolver should use a non-DNS protocol for name resolution. Lemon, et al. Expires December 31, 2016 [Page 7] Internet-Draft Special-Use Names Problem June 2016 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 these purposes for special-use names are valid. [TODO: "Both" implies that there are only two applications; the above bullet points outline 3...] 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 exist no special-use names which require special handling by stub resolvers and which are not at the top level of the naming hierarchy. This does mean, however, that at present, RFC6762 requires the use of a special label, '.LOCAL', to indicate to stub resolvers that mDNS[RFC6762] be used to resolve names under that label. 4.1.3. MoU Concerning the Technical Work of the IANA There exists a Memorandum of Understanding[RFC2860] between the IETF and ICANN (Internet Corporation for Assigned Names and Numbers) which discusses how names and numbers will be managed through the IANA (Internet Assigned Numbers Authority). This document is important to the discussion of SUINs because, while it delegates authority for managing the Domain Name System Namespace generally to ICANN, it reserves to the IETF the authority that RFC 6761 formalizes: Note that (a) assignments of domain names for technical uses (such as domain names for inverse DNS lookup), (b) assignments of specialised address blocks (such as multicast or anycast blocks), and (c) experimental assignments are not considered to be policy issues, and shall remain subject to the provisions of this Section 4. The above text is an addendum to the following: Two particular assigned spaces present policy issues in addition to the technical considerations specified by the IETF: the assignment of domain names, and the assignment of IP address blocks. These policy issues are outside the scope of this MOU. In general, then, the assignment of names in the DNS root zone, and the management of the DNS namespace, is a function that is performed by ICANN. However, the MoU specifically exempts domain names assigned for technical use, and uses the example of 'IN-ADDR.ARPA' Lemon, et al. Expires December 31, 2016 [Page 8] Internet-Draft Special-Use Names Problem June 2016 and 'IP6.ARPA' to illustrate. Both of these names are in the RFC 6761 registry. The point here is not to say what the implications of this statement in the MoU are, but rather to call the reader's attention to the existence of this statement. 4.2. Secondary documents relating to the SUTLIN question In addition to these documents, there are several others with which participants in this discussion should be familiar. 4.2.1. Multicast DNS Multicast DNS [RFC6762] defines the Multicast DNS protocol, which uses the '.LOCAL' SUTLIN. Section 3 describes the semantics of "multicast DNS names." It is of considerable historical importance to note that the -00 version of this document, an individual submission, was published in July of 2001. This version contains substantially the same text in section 3, and was discussed in the DNSEXT working group at IETF 51 in August of 2001[IETF-PRO-51]. The first version of this document designated '.LOCAL.ARPA' as the special-use name. This idea was strongly opposed by DNSEXT working group participants, and as a result the author eventually switched to using '.LOCAL'. The history of RFC 6762 is documented in substantial detail in Appendix H; some notable milestones include the initial proposal to replace Appletalk's NBP in July 1997, the chartering of the Zeroconf working group in September 1999, allocation of a multicast address for link-local name discovery in April of 2000. A companion requirements document, eventually published as [RFC6760] was first published in September of 2001. The point of mentioning these dates is so that discussions involving the time when the '.LOCAL' domain was first deployed, and the context in which it was deployed, may be properly informed. 4.2.2. The .onion Special-Use TLD The .onion Special Use TLD [RFC7686] is important because it is the most recent IETF action on the topic of SUTLINs; although it does not set new policy, the mere fact of its publication is worth thinking about. Two important points to consider about this document are that: o The IETF gained consensus to publish it Lemon, et al. Expires December 31, 2016 [Page 9] Internet-Draft Special-Use Names Problem June 2016 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 SUTLIN were to be recognized by the IETF. 4.2.3. 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 SUTLINs like '.local' and '.onion' in that the names are resolved using the DNS protocol. But it shares the problem that such names cannot be assumed either to be unique or to be functional in all contexts for all internet- connected hosts. 4.2.4. 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 three specific top-level internet names, '.home', '.corp' and '.mail', that present sufficient risk that they must never be allocated by ICANN. 4.2.5. 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. 4.2.6. 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 Lemon, et al. Expires December 31, 2016 [Page 10] Internet-Draft Special-Use Names Problem June 2016 particularly at risk for collision as special-use domain names with no documented use. This attempt failed. Although this document failed to gain consensus to publish, the need it was intended to fill still exists. Unfortunately, although a fair amount is known about the use of these names, no document exists that documents how they are used, and why it would be a problem to allocate them. Additionally, to the extent that the uses being made of these names are valid, no document exists indicating when it might make sense to use them, and when it would not make sense to use them (the simplest version of this document would of course say "never use them." If that were the IETF consensus, that would be a good reason not to bother to publish the document. 4.3. Summary The assignment of internet names is not under the sole control of any one organization. ICANN has authority in many cases, and could be considered in some sense the default. IETF has authority in other cases, but only with respect to protocol development. And neither of these authorities can in any practical sense exclude the practice of ad-hoc allocation of names, which can be done by any entity that has control over one or more name servers or resolvers, in the context of any hosts and services that that entity operates. 5. History Newcomers to the problem of resolving domain names may be under the mistaken impression that the DNS sprang, as in 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 [RFC0882] [RFC0883] 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. Lemon, et al. Expires December 31, 2016 [Page 11] Internet-Draft Special-Use Names Problem June 2016 Another example was NetBIOS Name Service, also known as WINS [RFC1002]. This protocol was used mostly by Microsoft Windows machines, but also by open source BSD and Linux operating systems to do name resolution using Microsoft's own name resolution protocol. 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 or WINS. Most have the capability to resolve names using mDNS by recognizing the special meaning of the '.local' SUTLIN. 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. 6. 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]. 7. Informative References [RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", RFC 882, DOI 10.17487/RFC0882, November 1983, . [RFC0883] Mockapetris, P., "Domain names: Implementation specification", RFC 883, DOI 10.17487/RFC0883, November 1983, . Lemon, et al. Expires December 31, 2016 [Page 12] Internet-Draft Special-Use Names Problem June 2016 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, . [RFC1002] NetBIOS Working Group in the Defense Advanced Research Projects Agency, Internet Activities Board, and End-to-End Services Task Force, "Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed specifications", STD 19, RFC 1002, DOI 10.17487/RFC1002, March 1987, . [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, . [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, . [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, . [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, . [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC 6303, DOI 10.17487/RFC6303, July 2011, . [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, . Lemon, et al. Expires December 31, 2016 [Page 13] Internet-Draft Special-Use Names Problem June 2016 [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP)", RFC 6760, DOI 10.17487/RFC6760, February 2013, . [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, . [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, . [RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use Domain Name", RFC 7686, DOI 10.17487/RFC7686, October 2015, . [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, . [SDO-ICANN-COLL] Interisle Consulting Group, LLC, "Name Collisions in the DNS", August 2013, . [SDO-IANA-SUDR] Internet Assigned Numbers Authority, "Special-Use Domain Names registry", October 2015, . Lemon, et al. Expires December 31, 2016 [Page 14] Internet-Draft Special-Use Names Problem June 2016 [CORP-SUN-NIS] Sun Microsystems, "System and Network Administration", March 1990. [IETF-PRO-51] Internet Engineering Task Force, "Proceedings of the 51st IETF", August 2001, . Authors' Addresses 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 Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 US Email: warren@kumari.net Lemon, et al. Expires December 31, 2016 [Page 15]