S. Higgs Internet Draft Higgs Communications Document: draft-higgs-root-defs-00.txt February 2001 Category: Informational Root Server Definitions Status of this Memo This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as-is. 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 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 maintain the unicity of the DNS across any variation in 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 memo attempts to address the concepts of RFC2826 by defining the relationship between the U.S. Government Root Zone and the Private and Inclusive Root Zones. The purpose of this memo is to provide guidelines to prevent a root zone fragmentation. 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 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 Servers U.S. Government root servers are identified by the ROOT-SERVERS.NET domain name. 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. The U.S. Government root MUST pay the same respect to other root zones. The U.S. Government root MUST NOT create conflicts with pre-existing top level domains in the Inclusive root zone(s). 6. Private Root Servers Private root servers 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 Private root servers is OPTIONAL. In certain circumstance use may be required to meet the specific operational needs of a particular organization. 7. Inclusive Root Servers Inclusive Root Servers utilize the U.S. Government Root Zone as a baseline and add additional TLDs to enhance the name space. Inclusive Root Servers MUST include the complete U.S. Government- published zone. Inclusive Root Servers MUST NOT create conflicts with other root zones. Inclusive Root Servers SHOULD duplicate the name space extended beyond the U.S. Government-published baseline. This can be achieved by reciprocal agreements and peering of non-U.S. Government published TLDs between Inclusive Root Server operators. Use of Inclusive Root Servers is entirely OPTIONAL. 8. 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 Servers become authoritative for subservient DNS Servers and Clients. They will produce results different from the U.S. Government Root Servers for non-U.S. Government-published TLDs. Private or Inclusive Root 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, Milton Mueller, Brian Reid, Richard Sexton, and Einar Stefferud for their constructive comments. 11. Author's Addresses Higgs Communications P.O. Box 4519 Sylmar, CA 91041-4519 Phone: 818-352-3208 Fax: 818-352-0030 Email: simon@higgs.net 12. Full Copyright Statement Copyright (C) Higgs Communications 2001. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and all derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to Higgs Communications, or modifying the content. Except to the extent expressly granted herein, the presentation, distribution or other dissemination of the information contained herein by Higgs Communications is not a license, either expressly or implied, to any intellectual property owned or controlled by Higgs Communications. This document and the information contained herein is provided on an "AS IS" basis and HIGGS COMMUNICATIONS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT WILL HIGGS COMMUNICATIONS BE LIABLE TO ANY OTHER PARTY FOR THE COST OF PROCURING SUBSTITUTE GOODS OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL, CONSEQUENTIAL, DIRECT, INDIRECT, OR SPECIAL DAMAGES WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY MANNER RELATING TO THIS DOCUMENT, WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES. ###