Internet DRAFT - draft-rssac-dnsop-rfc2870bis

draft-rssac-dnsop-rfc2870bis



DNS Operations                      Root Server System Advisory Committee
Internet-Draft                                            
Intended status: Informational                                
Expires: 2012 July 24                                    06 February 2012
Replaces RFCs 2010, 2870


               Root Name Server Operational Requirements
                  draft-rssac-dnsop-rfc2870bis-04

Status of this Memo

   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.

   This Internet-Draft will expire on July 24, 2012.

IETF Legal Notices

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

  This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
  
   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.


     "This document is subject to the rights, licenses and restrictions
      contained in BCP 78, and except as set forth therein, the authors
      retain all their rights."

     "This document and the information contained herein are provided on an
      "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
      REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
      IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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."

     "The IETF takes no position regarding the validity or scope of any
      Intellectual Property Rights or other rights that might be claimed
      to pertain to the implementation or use of the technology described
      in this document or the extent to which any license under such
      rights might or might not be available; nor does it represent that
      it has made any independent effort to identify any such rights. 
      Information on the procedures with respect to rights in RFC
      documents can be found in BCP 78 and BCP 79."

     "Copies of IPR disclosures made to the IETF Secretariat and any
      assurances of licenses to be made available, or the result of an
      attempt made to obtain a general license or permission for the use
      of such proprietary rights by implementers or users of this
      specification can be obtained from the IETF on-line IPR repository
      at http://www.ietf.org/ipr."

     "The IETF invites any interested party to bring to its attention any
      copyrights, patents or patent applications, or other proprietary
      rights that may cover technology that may be required to implement
      this standard.  Please address the information to the IETF at
      ietf-ipr@ietf.org."

Abstract
   
   As the Internet has become critical to the world's social and economic 
   infrastructure, attention has focused on the correct, safe, reliable, and 
   secure operation of the Internet infrastructure itself.  The DNS is considered 
   a crucial part of that technical infrastructure. The root domain and its 
   authoritative name servers are a part of that technical infrastructure.  

   The primary focus of this document is to provide guidelines for secure, stable, 
   and resilient authoritative name service for the root zone. Additionally it will 
   look into some specifics for the operation of the name servers.  Other operators 
   of authoritative name servers such as those for generic top-level domains (gTLDs),
   country code top-level domains (ccTLDs) and other zones may also find this
   document useful.
   
   
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.  The Internet Assigned Numbers Authority functions operator (IANA)
   publishes the "root hints" file [HINTS] which lists the names and
   IP addresses of the thirteen authoritative root name servers that are the focus of
   this document. This document uses the term "server" to refer to the many ways a root
   operator provisions to provide root name service, irrespective of
   physical platform, IP address family or number of concurrent processes. This document
   provides guidelines for the operation of these root name servers to enable robust 
   and resilient DNS service for the root zone. The root zone service is provided by 
   the root servers operating under the following general characteristics.  It is expected
   that current practice will continue to evolve and we expect future revisions to this
   work.
   
   1.1   The Internet Corporation for Names and Numbers (ICANN) has appointed 
         a Root Server System Advisory Committee
         (RSSAC) (http://www.icann.org/committees/dns-root/) to give
         technical and operational advice to the ICANN board.  ICANN and
         RSSAC expect to use engineering standards developed within the IETF.
   
   1.2   The root servers serve the root (".") and ROOT-SERVERS.NET
         zones.  For legacy reasons, some of the root servers have also
         served other important zones. In the future, the data served by root 
         servers may change after careful review by RSSAC and ICANN.

   1.3   The root servers are neither involved with nor dependent upon
         any WHOIS [5] data.

   1.4   The domain name system has proven to be sufficiently robust
         that the temporary simultaneous loss of a number of the root server instances 
         has not significantly affect secure and stable operation of the Internet.

   1.5   Experience has shown that the Internet is quite vulnerable to
         incorrect data in the root zone or top-level domain (TLD)
         zones. Authentication, validation, and security of these data and the
         communications channels they transit are to be considered possible   
         vulnerabilities. The root server operators have taken steps to harden the 
         communications channels these data transit. [TSIG-7]

   1.6   Many of the root operators provision more than one physical or logical host 
         to provide root name service. [ROOTSERVERS]  In such configurations, incoming 
         DNS queries to the IP address providing root name service are distributed to
         multiple hosts using a variety of architectural techniques, including 
         layer-three load balancing devices, equal-cost multipath routing and Anycast
         routing.  (Anycast is discussed further in Section 4.)
    

   Since this document is not normative, the key word "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 
   in this document MAY be interpreted as described in RFC 2119 [1].

         
2.  The Servers Themselves

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

   2.1   Maintaining overall robustness and resilience of the root server system is
         accomplished by the root server operators by coordinating a heterogeneity of
         hardware, operating systems, topology, or name serving software across all 
         of the root name server nodes. [ROOTSERVERS]

   2.2   Each server runs software which correctly implements the
         IETF standards for the DNS, currently RFC1035 [2], RFC2181
         [3] and RFC4035[14].  While there are no accepted, 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 should be able to handle a load of
         requests for root data which is at least ten times the measured
         average number of requests on that server in then-current
         normal conditions.  This capacity is usually expressed in
         queries per second.  This specification is intended to ensure
         continued operation of root services in the event of extreme
         scenarios, such as distributed denial-of-service (DDoS) attacks
         and other operational anomalies.
   
   2.4   Each root server should have sufficient connectivity to the
         Internet to support the bandwidth needs of the above
         specification.  Connectivity to the Internet should be as diverse
         as possible. While reasonable efforts to ensure that the service is
         available Internet-wide, events do occur which prevent some nodes from 
         receiving the Root DNS service.  These events are out of scope of this
         document. They may include ISP or end-site misconfiguration, route 
         hi-jacking, routing system problems, DNS redirection or blocking, and 
         congestion in the intermediate ISPs.  This is not an exaustive list.

   
   2.5   Servers must provide authoritative responses only from the
         zones they serve.  The servers must disable recursive lookup,
         forwarding or any other function that might allow them to
         provide cached answers.  For root servers, there IS no place 
	 to recurse to and they get no answers from other servers to cache.
         The response packets should have reasonable IP TTL/IPv6 Hop-Limit 
         values. 64 is current suggested value. The value may be modified by 
         future events.

   2.6   Root servers must answer queries from any Internet host, i.e.
         root servers may not block root name resolution from any valid
         IP address regardless of address family, 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. Root servers must answer queries from the
         same address family as the query. Root servers may filter any Dynamic 
         Update requests [RFC2136]. They must not accept requested changes unless
         sent from an authorized sources with appropriate authentication [RFC3007].


   2.7   Root servers may choose to disallow AXFR, or other zone transfer,
         queries from clients other than other root servers.  This
         restriction is intended to prevent unnecessary load on the root servers.
         Operators may choose to rate limit traffic bases on protocol.

   2.8   Servers must generate checksums when sending UDP datagrams and
         must verify checksums when receiving UDP datagrams containing a
         non-zero checksum.


3.  Security Considerations

   The servers need both physical and protocol security as well as
   unambiguous authentication of their responses. Physical security focuses
   on the machines and their locations, Protocol security and response 
   authentication are covered by Internet Protocol standards.


3.1.  Physical Security

   Physical security will be commensurate to a level expected of data
   centers housing mission critical services.  Given the global distribution
   of hardware platforms, these levels may vary.  

   3.1.1   Whether or not the overall site in which a root server instance 
           is located has access control, the specific area in which the
           root server is located must have positive access control.
           At a minimum control measures should be either mechanical or electronic
           locks.  Physical security may be enhanced by the use of
           intrusion detection and motion sensors, multiple serial
           access points, security personnel, etc.

   3.1.2   Power continuity for at least 24 hours should be assured,
           whether through on-site batteries, on-site power generation
           or some combination thereof.  There must be procedures that ensure 
           the power fallback mechanisms and supplies are tested no less 
           frequently than the specifications and recommendations of the manufacturer.

   3.1.3   Fire detection and/or retardation must be provided.

   3.1.4   Provision must be made for rapid return to operation after a
           system outage.  Such provision should involve backup of
           system software and configuration but may also involve
           backup hardware which is pre-configured and ready to take
           over operation, which may require manual procedures.

3.2.  Network Security

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

   3.2.1   The root servers should not provide services other
           than DNS name service, secure shell for management, and network time
	   for TSIG and DNSSEC synchronization, e.g.
           protocols such as HTTP, Telnet, rlogin, FTP, routing daemons, 
           etc.  The rational for this argument is that the fewer services running,
           the less likely  there will be interference from non-DNS related events.
           The only login accounts permitted should be for the server administrator(s).  

           Servers should have a secure mechanism for remote
           administrative access and maintenance.  Failures happen;
           there will be times when something breaks badly enough that
           administrators will need to connect remotely.  Remote logins
           should be protected by a secure means that is strongly
           authenticated and encrypted, and locations from which remote
           login is allowed should be protected and hardened.  Remote
           logins should be restricted to a list of discrete IP
           addresses or address ranges.

   3.2.2   Root name servers should not trust other hosts, except
           servers presenting validated credentials, for matters of
           network time, authentication, encryption keys, or other access 
           or security information.  If a root operator uses Kerberos authentication
           to manage access to the root server, then the associated
           Kerberos key server must be protected with the same prudence
           as the root server itself.  This applies to all related
           services which are trusted in any manner.

   3.2.3   The broadcast domain on which a root server node is located should not
           also have other Internet-reachable hosts.  Secure monitoring
           hosts that passively monitor network traffic to and from the
           root server may be placed in the same broadcast domain.  Broadcast domains
           should be switched or routed so there is less possibility of masquerading.

   3.2.4   The broadcast domain(s) in which a root server node is located should
           be separately firewalled or packet filtered to prohibit network access 
           to any port other than those needed for name service and administration. 
           State-based firewalls for filters should be avoided as they create a DoS 
           point in DNS resolution.

   3.2.5   The root servers should have their clocks synchronized via
           NTP [6], SNTP [7] or similar mechanisms, in as secure manner
           as possible.  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.6   All attempts at intrusion or other compromise should be
           logged, and all such logs from all root servers may be
           analyzed by a cooperative security team communicating with
           all server operators to look for patterns, serious attempts,
           etc.  Logs must available in UTC to facilitate log comparison.

   3.2.7   Server logging may be to separate hosts which should be
           protected similarly to the root servers themselves.

   3.2.8   The server should be protected from attacks based on source
           routing.  The server must not solely rely on address- or name-based
           authentication.

   3.2.9   The network on which the server is located should have accurate
           reverse maps in both in-addr.arpa and ip6.arpa. This is to ensure a
	   valid PTR is returned for the root name servers.

3.3.  Protocol Authentication and Security

   Protocol authentication and security should be 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 should be signed and maintained by the US Depoartment of 
            Commerce contractor in accordance with current DNSSEC specifications 
            ([8], [9] and [10]) and practice.

   3.3.2    The root servers must be DNSSEC-capable so that queries may be 
            authenticated by clients with security and authentication concerns.

   3.3.3    Transfer of the root zone between root servers must be
            authenticated and be as secure as reasonably possible.  Out
            of band security validation of updates should be supported.
            Root server operators have agreed to use TSIG [4] to authenticate 
            root zone distribution from authorized sources.

   3.3.4    A "distribution" server, which only allows access by the
            authorized secondary root servers, may be used.

   3.3.5    Root zone updates should only progress after one or more
            heuristic checks designed to detect erroneous updates have
            been passed.  In case the update fails the tests, human
            intervention must be requested and the last known good zone
	    published. This is to mitigate the rare but occasional error
	    root zone generation / transmission.

   3.3.6    Root zone updates should normally be effective no later than
            one fourth of the time between root zone updates from notification 
            of the root server operator, based on the current update cycle of
	    a scheduled update every 12 hours.

   3.3.7    A special procedure for emergency updates of the root zone should 
            be defined by either the root server operators and/or RSSAC.
            Updates initiated by the emergency procedure should be made
            no later than 12 hours after notification.

   3.3.8    In the event of a critical network failure, each root server
            must have a method to update the root zone data via a medium
            which is delivered through an alternative, non-network,
            path.  In the event that the root server cannot serve
            current data, it must cease offering DNS service.  See also
            Paragraph 4.3.

   3.3.9    Each root should keep global statistics on the amount and
            types of queries received/answered on a daily basis.  These
            statistics may be made available to RSSAC and RSSAC-
            sponsored researchers to help determine how to better deploy
            these machines more efficiently across the Internet.  Each
            root may collect data snapshots to help determine data
            points such as DNS query storms, significant implementation
            bugs, etc.  This would be a first step in developing a consistent
	    data collection profile for the root zone.

   3.3.10   Each root operator must monitor its server to detect operational
            problems, such as a host being down, a host not running a
            name server, a name server not returning authoritative
            answers for the root zone, etc.  Servers may also be
            monitored from an external network.  These monitoring
            processes could be automated.  If problems are detected,
            the appropriate staff should be notified to troubleshoot and
            remedy the problem.

4.  Anycast and Network Considerations

   The root zone has been available via shared unicast as described in
   RFC 3258 [11] from several of the authoritative root name servers
   since 2002.  This technique is now commonly referred to as "anycast",
   despite its differences from the definition of that term in RFC 4786
   [12].  Anycast has proven to be a successful method for increasing
   the capacity and geographic distribution of the root server system.
   For a root server to offer service successfully using anycast,
   several current practices should be followed.

   4.1   A root server should be anycast using IPv4 address space that is a
         /24 from pre-RIR allocations.  Using any prefix longer than a /20 that
         is not from the this range risks reachability problems because of
         filtering by ISPs who won't route such address space. IPv6 address space
	 should be at least a /48. Root server nodes be numbered (v4 and v6) using
         addresses covered by routes that have been tested and are believed to 
         propagate globally.

   4.2   Each of a root server's anycast instances may be sourced
         from a consistent origin autonomous system (AS).  That is, the
         BGP routing announcement for all instances of a given root
         server's service address (i.e., the IPv4 address corresponding
         to the RDATA of that root name server's NS record) should have
         the same origin AS.

   4.3   Each anycast instance of a root server must withdraw its BGP
         routing announcement upon service failure.  Each anycast
         instance must monitor its ability to provide root name service
         and withdraw its route if it detects itself unable to provide
         service.  Such monitoring may be automatic and not dependent
         on a human noticing a service failure.

   4.4   Anycast instances using BGP should not use the BGP MULTI_EXIT_DISC (MED)
         attribute because of possible inter-domain routing (IDR)
         oscillation in networks using route reflectors or AS
         confederations.  Suggested better alternatives are BGP origin
         code, altering AS path length (i.e., prepending), adjusting
         local preference and communities.  Specific route oscillation
         scenarios and mitigations are described in detail in RFC 3345
         [13].

   4.5   Some root operators provision different kinds of anycast
         instances for a given root server.  Some instances are
         designated to be local to particular autonomous systems and
         thus advertise their routes with the BGP no-export community
         attribute.  Other instances are designated "global" and
         reachable from anywhere on the Internet; these instances do not
         advertise with no-export.  In the event of this configuration,
         the local and global instances should not advertise routes with
         the same prefix length.  The global instances should advertise
         a shorter covering prefix.

         Failure to advertise a shorter covering prefix from the global
         instances can result in unreachability in certain scenarios.
         For example, consider AS A with a local root server anycast
         instance (i.e., advertising its route with the no-export
         attribute) announced as prefix P1.  AS A prefers its local
         route to P1 over the other paths to P1 it may have received
         (corresponding to any global nodes).  Now consider AS B that
         peers only with AS A. Since the local instance of prefix P1 is
         the best path and is marked no-export, AS A does not send this
         prefix to AS B. AS B thus has no route to prefix P1 and cannot
         reach any instances of this root server.

         Instead, consider if the root server operator advertised a
         shorter covering prefix P2 for its global instances.  In the
         scenario above, AS A would send prefix P2 to AS B, making any
         of this root server's global instances reachable from AS B.

         For IPv4, if the root server prefix is a globally routable /24, and the
         operator does not have the necessary adjacent address space to
         aggregate and advertise a shorter prefix, the /24 itself should
         be advertised globally and a longer prefix (i.e., /25 or
         longer) designated local-only.  Such a longer local-only prefix
         will not typically be passed across peering boundaries, which
         eliminates the need to tag this prefix as no-export.

   4.6   Root server nodes should be deployed with the highest "splay" possible 
         from other root server nodes.  Such deployments will ensure the highest
         level of service since there will be less fate sharing due to common 
         topology failures, power grid shutdowns, seismic events or other localized
         disruptions. RFC 1281 describe failures due to fate sharing.  Root server
         operators monitor performance of their service from many locations, and 
         take appropriate steps to maximize their service availability. 

       
5.  Communications

   Communications and coordination between root server operators and
   between the operators and IANA and ICANN are necessary.

   5.1   Planned outages and other scheduled maintenance times should be coordinated
         between root server operators to ensure that a significant
         number of the root servers are not all unavailable at the same time.
         Announcement of planned outages also keeps other operators from
         investigated a scheduled maintenance window.

   5.2   Root server operators may exchange log files, particularly
         as they relate to security, loading, and other significant
         events.  This may be through a central log coordination point,
         or may be informal.

   5.3   Statistics as they concern usage rates, loading, and resource
         utilization may be exchanged between operators, and may
         be reported to IANA for planning and reporting purposes.

   5.4   Root name server administrative personnel must be available to
         provide service 24 hours a day, 7 days per week.  On call
         personnel may be used to provide this service outside of normal
         working hours.


6.  IANA considerations
         
   There are no new IANA considerations introduced by this memo.

         
7.  Internationalization considerations

   There are no new internationalization considerations introduced by
   this memo.
 
8.  Acknowledgements

    This work originated with the original root server requirements document and
    has been substantially updated and revised.  Thanks to Bill Manning, Paul Vixie,
    Mark Kosters and Matt Larson for much of the text and RSSAC for its review. 
    Specific comments were received from Howard Kash, Jim Cassells, Akira Kato,
    Shinta Sato, Dave Swager, Terry Manderson, David Conrad, Warren Kumari, Ed Lewis,
    and John Dickinson.

9.  References

9.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Mockapetris, P., "Domain names - implementation and
        specification", STD 13, RFC 1035, November 1987.

   [3]  Elz, R. and R. Bush, "Clarifications to the DNS Specification",
        RFC 2181, July 1997.

   [4]  Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington,
        "Secret Key Transaction Authentication for DNS (TSIG)",
        RFC 2845, May 2000.

9.2.  Informative References

   [5]   Daigle, L., "WHOIS Protocol Specification", RFC 3912,
         September 2004.

   [6]   Mills, D., "Network Time Protocol (Version 3) Specification,
         Implementation", RFC 1305, March 1992.

   [7]   Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for
         IPv4, IPv6 and OSI", RFC 4330, January 2006.

   [8]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
         "DNS Security Introduction and Requirements", RFC 4033,
         March 2005.

   [9]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
         "Resource Records for the DNS Security Extensions", RFC 4034,
         March 2005.

   [10]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
         "Protocol Modifications for the DNS Security Extensions",
         RFC 4035, March 2005.

   [11]  Hardie, T., "Distributing Authoritative Name Servers via Shared
         Unicast Addresses", RFC 3258, April 2002.

   [12]  Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting
         Service", RFC 1546, November 1993.

   [13]  McPherson, D., Gill, V., Walton, D., and A. Retana, "Border
         Gateway Protocol (BGP) Persistent Route Oscillation Condition",
         RFC 3345, August 2002.

   [14]   R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, "Protocol 
          Modifications for the DNS Security Extensions", RFC 4035, March 2005

   [HINTS]   Root Hints authoritative source: http://www.internic.net/zones/named.root
          checked 20120125

Authors' Addresses

   Root Server System Advisory Committee (RSSAC)
   <rssac@icann.org>


   Bill Manning, Editor
   PO Box 12317
   Marina del Rey, CA 90295
   USA