Subject: Re: your mail

From: Randy Bush <[email-masked]>
Date: Tue, 16 Mar 1999 08:08:09 -0500 (EST)

Internet Assigned Numbers Authority                          Randy Bush
INTERNET-DRAFT                                                    Verio
draft-dnsop-root-opreq-00.txt                                  99.03.15

               Root Name Server Operational Requirements

    Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document is an Internet-Draft and is in full conformance with
   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.

0. Abstract

   As the internet becomes increasingly critical to the world's social
   and economic infrastructure, attention has rightly focused on the
   correct, safe, reliable, and secure operation of the internet
   infrastructure itself.  The root domain name servers are seen as a
   crucial part of that technical infrastructure.  This document
   attempts to provide guidelines for operation of the root servers.
   These guidelines are intended to meet the perceived societal needs
   without overly prescribing technical details.

Bush                        Expires 99.09.15                    [Page 1]

INTERNET-DRAFT  Root Name Server Operational Requirements       99.03.15

1. Background

   The resolution of domain names on the internet is critically
   dependent on the proper, safe, and secure operation of the root
   domain name servers.  Currently, these dozen or so servers are
   provided and operated by a very competent and trusted group of
   volunteers.  This document does not propose to change that, but
   merely to provide formal guidelines so that the community understands
   how and why this is done.

   1.1 The ICANN has become responsible for the operation of the root
       servers.  The ICANN has appointed a Root Server System Advisory
       Committee (RSSAC) to give technical and operational advice to the
       ICANN board.  The ICANN and the RSSAC look to the IETF to provide
       engineering standards.

   1.2 The root servers serve the root, aka 'dot', zone.  Although today
       some of the root servers also serve some TLDs (top level domains)
       such as gTLDs (COM, NET, ORG, etc.), infrastructural TLDs such as
       INT and IN-ADDR.ARPA, and some ccTLDs (country code TLDs, e.g. SE
       for Sweden), these TLDs MUST be moved to separate TLD servers in
       the near future.

   1.3 The root servers are neither involved with nor dependent upon the
       'whois' data.

   1.4 The the domain name system has proven to be sufficiently robust
       that we are confident that the, presumably temporary, loss of
       most of the root servers should not significantly affect
       operation of the internet.

   1.5 Experience has shown that the internet is quite vulnerable to
       incorrect data in the root zone or TLDs.  Hence authentication,
       validation, and security of these data are of great concern.

2. The Servers Themselves

   The following are requirements for the technical details of the root
   servers themselves:

   2.1 It would be short-sighted and presumptious of this document to
       specify particular hardware, operating systems, or name serving
       software.  Variations in these areas would actually a source of
       robustness.

Bush                        Expires 99.09.15                    [Page 2]

INTERNET-DRAFT  Root Name Server Operational Requirements       99.03.15

   2.2 Each server MUST run software which correctly implements the IETF
       standards for the DNS, currently [RFC1035] [RFC2181].  While
       there are no formal test suites for standards compliance, the
       maintainers of software used on root servers are expected to take
       all reasonable actions to conform to the IETF's then current
       documented expectations.

   2.3 At any time, each server MUST be able to handle a load of
       requests for root data which is three times the measured peak of
       such requests on the most loaded server in then current normal
       conditions.  This is usually expressed in requests per second.
       This is intended to ensure continued operation of root services
       should two thirds of the servers be taken out of operation,
       whether by intent, accident, or malice.

   2.4 Each root server should have sufficient connectivity to the
       internet to support the bandwidth needs of the above requirement.

   2.5 Root name servers MUST disable recursive name lookup, forwarding,
       etc.  They also MUST NOT provide secondary service for any zones
       other than the root zone.  These restrictions help prevent undue
       load on the root servers and reduce the chance of their caching
       incorrect data.

   2.6 Root servers MUST answer queries from any internet host, i.e. may
       not block root name resolution from any valid IP address, except
       in the case of queries causing operational problems, in which
       case the blocking SHOULD last only as long as the problem, and be
       as specific as reasonably possible.

3. Security Considerations

   The servers need both physical and protocol security as well as
   unambiguous authentication of their responses.

   3.1 Physical security MUST be ensured in a manner expected of data
       centers critical to a major enterprise.

       3.1.1 Physical access security MUST be provided for the location
             of the servers themselves, whether or not the overall site
             itself is secure.  This may be through traditional locks
             with very restricted key access, electronic locks, etc.

Bush                        Expires 99.09.15                    [Page 3]

INTERNET-DRAFT  Root Name Server Operational Requirements       99.03.15

       3.1.2 Power continuity for at least 48 hours MUST be assured,
             whether through on-site batteries, on-site power
             generation, or some combination thereof.  This MUST supply
             the server itself, as well as the infrastructure necessary
             to connect the server to the internet.  There MUST be
             procedures which ensure that power fallback mechanisms and
             supplies are tested no less frequently than once a month.

       3.1.3 Fire detection and/or retardation MUST be provided.

       3.1.4 Provision MUST be made for rapid return to operation after
             an system outage.  This SHOULD involve backup of systems
             software and configuration.  But is SHOULD also involve
             backup hardware which is pre-configured and ready to take
             over operation, which MAY require manual procedures.

       3.1.5 Root server operators SHOULD coordinate backup timing so
             that many servers are not off-line being backed up at the
             same time.  Backups SHOULD be frequently transferred off
             site.

   3.2 Network security should be of the level provided for critical
       infrastructure of a major commercial enterprise.

       3.2.1 The root servers themselves SHOULD provide no services
             other than root name service.  I.e. they SHOULD NOT support
             other internet remote protocols such as http, telnet,
             rlogin, ftp, etc.  Maintenance access SHOULD be via serial
             console.

       3.2.2 Root name servers MUST NOT trust other hosts, except
             secondary servers trusting the primary server, for any
             matters of authentication, encryption keys, or other access
             or security information.

       3.2.3 The LAN segment(s) on which a root server is homed MUST NOT
             also home crackable hosts.  I.e. the LAN segments should be
             switched or routed so there is no possibility of
             masquerading.

       3.2.3 The LAN segment(s) on which a root server is homed SHOULD
             be separately firewalled or packet filtered to discourage
             network access to any port other than those needed for name
             service.

Bush                        Expires 99.09.15                    [Page 4]

INTERNET-DRAFT  Root Name Server Operational Requirements       99.03.15

       3.2.4 The root servers SHOULD have their clocks synchronized via
             NTP [RFC1305] [RFC2030] or similar mechanisms.  For this
             purpose, servers and their associated firewalls SHOULD
             allow the root servers to be NTP clients.  Root servers
             MUST NOT act as NTP peers or servers.

       3.2.5 All attempts at intrusion or other compromise SHOULD be
             logged, and all such logs from all root servers SHOULD be
             analysed by a central security team to look for patterns,
             serious attempts, etc.

       3.2.6 Server logging SHOULD be to separate hosts which SHOULD be
             protected similarly to the root servers themselves.

   3.3 Protocol authentication and security are required to ensure that
       data presented by the root servers are those created by those
       authorized to maintain the root zone data.

       3.3.1 The root zone MUST be signed by the IANA in accordance with
             DNSSEC, see [RFC2535] or its replacements.  It is
             understood that DNSSEC is not yet deployable on some common
             platforms.  Hence this may take on the order of a year from
             this writing to deploy.

       3.3.2 Root servers MUST be DNSSEC-capable so that queries may be
             authenticated by clients with security and authentication
             concerns.  It is understood that DNSSEC is not yet
             deployable on some common platforms.  Hence this may take
             on the order of a year from this writing to deploy.

       3.3.3 Transfer of the root zone between root servers MUST be
             authenticated and be as secure as reasonably possible.
             Servers MUST use DNSSEC to authenticate root zones received
             from other servers.  It is understood that DNSSEC is not
             yet deployable on some common platforms.  Hence this may
             take on the order of a year from this writing to deploy.

       3.3.4 A 'hidden primary' server, which only allows access by the
             authorized secondary root servers, MAY be used.

4. Acknowledgments

   The author would like to thank Scott Bradner, Robert Elz, and John
   Klensin for their constructive comments.

Bush                        Expires 99.09.15                    [Page 5]

INTERNET-DRAFT  Root Name Server Operational Requirements       99.03.15

5. References

[RFC1035]
     Domain names - implementation and specification.  P.V. Mockapetris.
     Nov 1987.

[RFC1305]
     Network Time Protocol (Version 3) Specification, Implementation.
     David L. Mills.  Mar 1992

[RFC2030]
     Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and
     OSI.  D. Mills.  Oct 1996.

[RFC2181]
     Clarifications to the DNS Specification.  R. Elz, R. Bush.  Jul
     1997.

[RFC2535]
     Domain Name System Security Extensions.  D. Eastlake, 3rd, C. Kauf-
     man.  Mar 1999.

6. Author's Address

   Randy Bush
   5147 Crystal Springs
   Bainbridge Island, WA US-98110
   +1 206 780 0431
   [email-masked]

7. Specification of Requirements

   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 RFC 2119.

Bush                        Expires 99.09.15                    [Page 6]

INTERNET-DRAFT  Root Name Server Operational Requirements       99.03.15

8. Full Copyright Statement

   Copyright (C) The Internet Society (1999).  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
   derivative works.  However, this document itself may not be modified in any
   way, such as by removing the copyright notice or references to the Internet
   Society or other Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for copyrights
   defined in the Internet Standards process must be followed, or as required
   to translate it into languages other than English.

   The limited permissions granted above are perpetual and will not be revoked
   by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an "AS IS"
   basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
   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.

Bush                        Expires 99.09.15                    [Page 7]

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 17 Mar 99 6:18:12 JST

Randy;

>              switched or routed so there is no possibility of

Isn't it better to require root servers attached to a single
LAN segment that each has only one IP address?

							Masataka Ohta

---

From: Peter Koch <[email-masked]>
Date: Mon, 22 Mar 1999 18:21:47 +0100

>        as specific as reasonably possible.

Is this meant to imply they MUST answer AXFR queries for the root zone?

-Peter

---

From: Chris Yarnell <[email-masked]>
Date: Mon, 22 Mar 1999 09:39:22 -0800 (PST)

>>        not block root name resolution from any valid IP address, except
[...]
> Is this meant to imply they MUST answer AXFR queries for the root zone?

Well, a refusal is an 'answer', IMO.  I think this section speaks to root
servers selectively blocking certain hosts or netblocks completely?

---

From: "Matt Crawford" <[email-masked]>
Date: Mon, 22 Mar 1999 11:32:49 -0600

[ moderator note: could we move this to [email-masked], which has the
  work item? -- rb ]

>>        [ ... ]

REFUSED is an answer, isn't it?

---

From: Lars-Johan Liman <[email-masked]>
Date: Mon, 22 Mar 1999 20:05:45 +0100

> [ moderator note: could we move this to [email-masked], which has the

Nitpick:

If you're referring to the mailing list, it is

  [email-masked]

and nothing else, for the time being.

				  /Liman
#-------------------------------------------------------------------------
# Lars-Johan Liman			 ! Internet: [email-masked]
# Ebone/NORDUnet/SUNET Operations Centre ! HTTP    : //www.sunet.se/~liman
# Royal Institute of Technology, Sweden	 ! Voice   : Int +46 8 - 790 65 60
#-------------------------------------------------------------------------