ID: Root Zone Definitions draft 01

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

###