Internet Engineering Task Force S. Higgs
Internet Draft Higgs Communications
Category: Informational May 2001
Document: < draft-higgs-root-defs-01.txt >
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 XXXX
XXXXXXXX, XX XXXXX-XXXX
Phone: XXX-XXX-XXXX
Fax: XXX-XXX-XXXX
Email: XXXXX@XXXXX.XXX
12. Expires: November 2001
###
