Network Working Group S. Higgs
Internet Draft Higgs Communications
Category: Informational February 2001
Expires: August 2001
Root Server Definitions
< draft-higgs-root-defs-00.txt >
1. 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 an Internet Draft.
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
2. 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].
Higgs Informational [Page 1]
Internet Draft Root Server Definitions February 2001
3. 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".
4. 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.
Higgs Informational [Page 2]
Internet Draft Root Server Definitions February 2001
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.
5. 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.
6. 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).
7. 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.
Higgs Informational [Page 3]
Internet Draft Root Server Definitions February 2001
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.
8. 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.
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 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
Higgs Informational [Page 4]
Internet Draft Root Server Definitions February 2001
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.
10. 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
11. Acknowledgments
The author would like to thank Karl Auerbach, Milton Mueller, Brian
Reid, Richard Sexton, and Einar Stefferud for their constructive
comments.
12. Author's Address
Higgs Communications
P.O. Box XXXX
XXXXXXXX, XX XXXXX-XXXX
Higgs Informational [Page 5]
Internet Draft Root Server Definitions February 2001
Phone: XXX-XXX-XXXX
Fax: XXX-XXX-XXXX
Email: XXXXX@XXXXX.XXX
13. 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.
14. Expires
This Internet Draft expires at the end of August 2001
Higgs Informational [Page 6]
