Reserved Top Level Domain Names

The Internet Domain Name System is documented in RFC1034, RFC1035, RFC1591 and numerous additional Requests for Comment. It defines a tree of names starting with root, ".", immediately below which are top level domain names such as ".com" and ".us". Below top level domain names there are normally additional levels of names. RFC2606 reserved a small number of TLD names which, without fear of conflicts with current or future actual top level domain names in the global DNS, can be used for private testing of existing DNS related code, examples in documentation, DNS related experimentation, invalid DNS names, or other similar uses. RFC2606 also noted that the Internet Assigned Numbers Authority (IANA) reserves the label "example" at the second level below the TLDs .com, .net, and .org. Since RFC2606 was published in 1999, Internet engineering and operation practices have evolved in ways that recommend this update to the list of reserved TLD names, and the creation of a "reserved TLD name registry" to which additional labels may be added as new requirements arise. This update is also prompted by the expected advent of new TLDs which might, in the absence of the reservations for which this document provides, introduce TLD labels that could create engineering and operational problems for root server operators and other DNS infrastructure providers. It is important to note that TLD names may be reserved, in other contexts, for policy, political, or other reasons that are distinct from the IETF's concern with Internet engineering and operations. This document reserves TLD names only for operational and engineering reasons. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

The four top level domain name labels reserved by RFC2606 for testing and documentation examples remain reserved: test example invalid localhost ".test" is recommended for use in testing of current or new DNS related code. ".example" is recommended for use in documentation or as examples. ".invalid" is intended for use in online construction of domain names that are sure to be invalid and which it is obvious at a glance are invalid. The ".localhost" TLD has traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP address and is reserved for such use. Any other use would conflict with widely deployed code which assumes this use. This document makes no changes to the IANA reservation of the label "example" at the second level.

In its report of a quantitative study of queries to the DNS root servers entitled "Invalid Top Level Domain Queries at the Root Level of the Domain Name System" [or, SAC 045] ICANN's Security and Stability Advisory Committee "calls attention to the potential problems that may arise should a new TLD applicant use a string that has been seen with measurable (and meaningful) frequency in a query for resolution by the root system and the root system has previously generated a response." Of particular concern is the case in which a string "has been queried and a root name server has responded to the query with a non-existent domain (NXDOMAIN) result, i.e., the string has not been delegated but has been queried." SAC 045 reports the results of a CAIDA measurement study which found that "NXDOMAIN responses account for more than 25 percent of the total responses from root name servers observed in the study, and the top ten such strings account for 10 percent of the total query load." SAC 045 describes in detail the engineering and operational problems that would ensue from the delegation, as new valid TLD names, of previously invalid labels that have frequently appeared in queries to the root: "If the [new TLD label] were to be approved and the TLD included in the root zone, queries to the root level of the DNS for a string that hitherto returned NXDOMAIN would begin to return positive responses containing name servers of the new TLD." Recommendation (2) of SAC 045 calls for the community to develop principles for "prohibiting the delegation of additional strings to those already identified in RFC2606." As the first step in that process, based on the data reported by SAC 045, this document adds to the list of names that may not be used for top-level domains the following labels: .local .localdomain .domain .lan .home .host .corp To facilitate the further steps that may be taken to pursue Recommendation (2) of SAC 045, IANA is requested to publish a new registry of TLD names reserved by the IETF. This Reserved TLD Name Registry should simply list the reserved TLD names with a reference in each case to the authority for reserving the name. New names may be added to the registry through "IETF Specification Required" as provided by RFC4234. The initial contents of the registry are the names listed in Appendix A of this document.

One of the reasons cited in Section 1 for reserving specific labels that cannot be used for valid top level domain names in the global DNS is to make it possible for those labels to be used safely in other contexts, without risk of conflict with "real" domain names. Reserving these labels therefore effectively encourages their use in locally-defined domain names that may resolve differently in different local contexts. An application that looks up "foo.local" on private network A, for example, may get a different result if it looks up "foo.local" on private network B. A name that resolves differently depending on where the lookup request is made presents obvious security issues for any application that does not expect this behavior. These issues arise from the use of any locally-defined labels in domain names, whether or not they are reserved.

There are no architectural implications related to reserving individual strings at the top level of the DNS.

According to RFC2606, IANA agreed to the top level domain reservations in that document. However, IANA was not instructed to publish a list of reserved names. IANA is requested to publish a new registry of TLD strings reserved by the IETF. The Reserved TLD Name registry will consist of a list of reserved TLD names and a reference for each entry to the document that put the strings into reserved status. New strings are to be added to the registry through "IETF Specification Required" as provided by RFC4234. The initial content of the full registry is located in the Appendix to this document.

Several studies have shown that a large fraction of the lookup queries seen by the DNS root servers request information about invalid TLDs. THe authors thank CAIDA, and in particular kc claffy, for their work in this area. The authors are also indebted to the contributors to SAC 045 which provided the impetus for this first step at identifying a particular set of strings to be reserved. David Conrad provided helpful input about potential security concerns surrounding the reservation of strings at the root.

This is the initial registration for the registry of Reserved Top Level Names in the DNS. The IANA is asked to use this material as guidance for the creation of the initial registry. Future registrations in this registry will be done through "IETF Specification Required" as provided by RFC4234. Label Reference .corp RFCxxx .domain RFCxxx .example RFC2606,RFCxxx .home RFCxxx .host RFCxxx .invalid RFC2606,RFCxxx .lan RFCxxx .local RFCxxx .localdomain RFCxxx localhost RFC2606,RFCxxx test RFC2606,RFCxxx NOTE TO RFC EDITOR: The correct number of this document should be substituted in the table above upon publication. At that time this editing note should be deleted.