Internet Engineering Task Force S. Higgs Internet Draft Higgs Communications Category: Informational May 2001 Document: Root Zone Definitions Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html 1. Abstract The purpose of this memo is to provide guidelines to prevent a root zone fragmentation. This memo is provided as a supplement to Request For Comments 2826 (RFC2826)[1]. RFC2826 states that there is a single unique root of the public DNS. This memo attempts to resolve outstanding issues pertaining to a unique root while maintain the unicity of the DNS across any variation of the actual data contained in a root zone. In other words, the total sum of DNS data from all variations of root zone data is a single unique root. This root zone is defined in this memo as the "Virtual Inclusive Root". This memo also attempts to further refine the concepts of RFC2826 by defining the relationship between the U.S. Government Root Zone and the Private and Inclusive Root Zones. This memo does not provide guidelines for the introduction of new Top Level Domains, nor does it address the various issues that have delayed the introduction of new TLDs since the first requests were submitted to IANA in 1995[2]. 2. Conventions used in this document 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[3]. For the purposes of this document, the term "non-U.S. Government" will be referred to as "Inclusive". 3. Unresolved issues pertaining to a unique root Domain Name Service (DNS) is a hierarchical distributed database architecture[4]. Because it is hierarchical, the assumption is made in RFC2826 that there can be only one unique root zone. RFC2826 mentions the use of private networks creating private name spaces but does not define the relationship between the private name space and the U.S. Government-published name space. RFC2606 (also known as Best Current Practice 32 / BCP32)[5] also mentions four reserved top level domains (TLDs) which are used for configuration and testing purposes. These are deliberately left out of the U.S. Government-published name space, and their use immediately creates an "non-U.S. Government" or "Inclusive" root zone. RFC2826 does not mention enhancements to the U.S. Government- published name space that are provided by non-U.S. Government Root Servers. These are also known as "non-ICANN Root Servers", "Alternative Root Servers", "Enhanced Root Servers", and "Inclusive Root Servers". This document does not refute the technical findings of RFC2826. In all the variations of root servers examined, there is only one root zone being published for each root server cluster. The reality is that for various reasons that are beyond the scope of this document, multiple root servers exist within the publicly visible segments of the Internet. It is a simple matter for any DNS Server operator or end user to change their DNS configuration settings to see any of these non-U.S. Government root servers. It is also possible for DNS information to be altered, at any level within the DNS hierarchy, on any DNS Server, at any time. This is entirely at the discretion of each DNS Server operator. Consequently the DNS Server operator MUST, at all times, act in a responsible manner consistent with the stable operation of the Internet. Most modern operating systems provide a mechanism (such as the resolv.conf file or a "Network" control panel) that pre-defines the local trusted DNS Servers that will be initially queried. Each computer therefore has the ability to query a unique combination of DNS Servers. Consequently the end user MAY change their DNS settings and bypass their local ISPs DNS Servers. This allows Inclusive Root Zones to be viewed in the public Internet space. 4. Stability of the root zone and criminal consequences It should be recognized that in the United States, altering DNS records to the detriment of a pre-existing organization is covered under federal computer fraud statute, 18 United States Code, Section 1030[6]. As a result, criminal convictions have resulted from the alteration of DNS information[7]. Most countries now have similar laws. 5. U.S. Government Root Zone U.S. Government root servers are identified by the ROOT-SERVERS.NET domain name. Historically, these servers resolve the default root zone that is shipped with DNS server software. The zone file for the U.S. Government root servers can be found here: ftp://rs.internic.net/domain/named.ca The authoritative host for the U.S. Government-published TLDs is A.ROOT-SERVERS.NET. U.S. Government authorized root servers publish the root zone described in RFC2826. This document uses this zone as the baseline to determine the relationships to other published DNS root zones. Use of the U.S. Government root zone is RECOMMENDED. It is used as the baseline for the Inclusive Root zones. 6. Private Root Zone Private root zones do not reflect the publicly viewable Internet name space. They MAY carry a sub-set (or none at all) or the U.S. Government-published baseline TLDs. They are NOT required to carry the complete U.S. Government- published Root Zone. They MUST NOT be directly accessible from the public Internet. The only exception is when they are accessed through a secure and authenticated gateway (such as a Virtual Private Network (VPN)) in order to identify hosts which are only accessible within an organization's intranet infrastructure. Use of a Private Root Zone is OPTIONAL. In certain circumstance use may be required to meet the specific operational needs of a particular organization. 7. Inclusive Root Zones Inclusive Root Zones utilize the U.S. Government root zone as a baseline and add additional TLDs to enhance the name space. Inclusive Zoot zones SHOULD include the complete U.S. Government- published zone. Inclusive Root Servers SHOULD peer the name space extended beyond the U.S. Government-published baseline. This can be achieved by reciprocal agreements of non-U.S. Government published TLDs between Inclusive Root Zone operators. Use of an Inclusive Root Zone is OPTIONAL. 8. Virtual Inclusive Root The "Virtual Inclusive Root" is the sum of all variations of all publicly-accessable root zone data. It is the gross manifestation of the unicity in the global DNS. Each root zone MUST pay the same respect to all other root zones. Each root zone MUST NOT create top level domain conflicts with other root zones. Pre-existing top level domains MUST be recognized by other root zones as part of the Virtual Inclusive Root zone. Peering of top level domains amongst root zones is highly RECOMMENDED. 9. Security Considerations There is an inherent trust relationship created between a DNS Server and DNS Client. By convention, all DNS Servers are expected to return correct information to the DNS Client. Both Private and Inclusive Root Zone servers become authoritative for subservient DNS Servers and Clients. They will produce results different from the U.S. Government Root Zone servers for non-U.S. Government-published TLDs. Private or Inclusive Root Zone servers MAY be employed in order to enhance network security of a particular organization. Several well known companies use additional TLDs within their local area networks. These _hidden_ TLDs are used to protect the identity of network assets and do not resolve outside of the company's intranet. Other Security Considerations for root servers are described in detail in RFC2870[8]. This document RECOMMENDS full compliance with RFC2870. 9. References 1 Internet Architecture Board, "IAB Technical Comment on the Unique DNS Root", RFC 2826, May 2000 2 Postel, J., "The IANA's File of iTLD Requests", http://www.gtld- mou.org/gtld-discuss/mail-archive/00990.html 3 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 4 Mockapetris, P., RFC1034, "Domain Names - Concepts and Facilities", November 1983 5 D. Eastlake, A. Panitz, "Reserved Top Level DNS Names", BCP32, RFC 2606, June 1999 6 United States Code, Title 18, Chapter 47, Sec. 1030. "Fraud and related activity in connection with computers" http://www.usdoj.gov/criminal/cybercrime/1030_new.html 7 U.S. vs. Kashpureff (NY) http://www.usdoj.gov/criminal/cybercrime/kashpurepr.htm 8 Bush, R., Karrenberg, D., Kosters, M., Plzak, R., "Root Name Server Operational Requirements", RFC2870, June 2000 10. Acknowledgments The author would like to thank Karl Auerbach, Scott Bradner, Milton Mueller, Brian Reid, Richard Sexton, and Einar Stefferud for their constructive comments. 11. Author's Address Higgs Communications P.O. Box 4519 Sunland, CA 91041-4519 Phone: 818-352-3208 Fax: 818-352-0030 Email: simon@higgs.net 12. Expires: November 2001 ###