Reserved Top Level Domain Names
draft-chapin-rfc2606bis-00.txt

Abstract

The Internet Domain Name System (DNS) defines a tree of names starting with root, ".", immediately below which are top level domain (TLD) names such as ".com" and ".us". RFC2606 reserved a small number of TLD names for use in documentation examples, private testing, experiments, and other circumstances in which it is desirable to avoid conflict with current or future actual TLD names in the DNS. The evolution of Internet engineering and operation practices since RFC2606 was published in 1999, and the expected addition of new TLD names to the DNS, recommend this update to the list of reserved TLD names, and the creation of a "reserved TLD name registry" to which additional names may be added as new requirements arise.

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.

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 02, 2011.

Copyright Notice

Copyright (c) 2011 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.

Table of Contents

• 1. Introduction
• 2. Legacy Reserved Top Level Domain Names
• 3. Additional Reserved Top Level Domain Names and Reserved TLD Name Registry
• 4. Security Considerations
• 5. IAB Considerations
• 6. IANA Considerations
• 7. Acknowledgements
• 8. Appendix - Initial Registry of Reserved Top Level Domain Names
• 9. References
• Authors' Addresses

1. Introduction

The Internet Domain Name System is documented in RFC1034 [RFC1034], RFC1035 [RFC1035], RFC1591 [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 [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 [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 [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 [RFC2119].

2. Legacy Reserved Top Level Domain Names

The four top level domain name labels reserved by RFC2606 [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.

3. Additional Reserved Top Level Domain Names and Reserved TLD Name Registry

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 [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 [RFC4234]. The initial contents of the registry are the names listed in Appendix A of this document.

4. Security Considerations

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.

5. IAB Considerations

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

6. IANA Considerations

According to RFC2606 [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 [RFC4234]. The initial content of the full registry is located in the Appendix to this document.

7. Acknowledgements

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.

8. Appendix - Initial Registry of Reserved Top Level Domain Names

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 [RFC4234].

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.

9. References

Authors' Addresses