view Side-By-Side changes

                  Technical Criteria for Root and TLD Servers
		    draft-manning-dnssvr-criteria-00.txt
		    draft-manning-dnssvr-criteria-01.txt

Abstract

   This draft proposes criteria for servers and their environments that 
   will support zones for top level and root domains. It is expected that 
   the machines running root name service will be different than the machines 
   running TLD name service. Although there are differences, the same basic
   criteria should hold. It For example, it is expected that TLD servers may 
   field more queries and the root servers may be more concerened concerned with cache 
   pollution.

   Although this draft has been discussed in various bodies, it is not
   final, it should not be regarded as a consensus document, and it is
   presented for open debate in the Internet community.

Status of this Memo

   This document wants to be is 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.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet- Drafts
   Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).

Design Goals:

	Define the basic set of requirements for TLD/Root TLD & Root server hardware. systems.
	Make them all objectively verifiable.

Disclaimer:

	This document doesn't discuss actual placement of servers.
	Procedures for dealing with non-compliance are not covered in
	this memo.

Selected Operational Qualifications:

1. Modern BIND or equivalents (if any exist).
	The upgrade process will be coordinated with the zone-master staff
	and will occur within 96 hours of inital initial notification. Zone-master
	senior staff will specify the software and version(s) that will
	be run in a particular zone.

2. UDP checksums enabled.
	Note that this should also apply to all machines running DNS.

3. Dedicated host 
	no host. 
	No user accounts, just the operations & admin or root account.
	no
	No other services except NTP. (remove telnet, SMTP, FTP etc).
	This requires support to be from the console or other specified
	secure channel. It is expected that one-time tokens will be used
	for authentication.

4. Singly homed (only one interface).
	Name service should always answer out the same interface as requests
	come in on. Also, delegations will usually list a single A RR, so there
	should only be a single canonical name.

5. Protected: Protected.
	In general, each server must be adequately protected against security 
   	threats.  The system administrator must stay up-to-date on the latest
   	security methods and threats and must implement reasonable security
   	countermeasures. Audits by the zone administrator or authorized agents
   	will be permitted and corrective measures will be taken. A good way to
   	keep current is to follow the CERT recommendations.  A reasonable 
	approach is to only run DNS sw, NTP and ICMP support with extensive 
	logging. Recommended packages to assist are tcp_wrappers and ipfilter. 
	Any other package which is has an acceptable technology is fine.

6. Servers time is synchronized via NTP.
   	This is useful for supporting functions; e.g. logging. It is expected 
	that future enhancements such as dynamic update and security support 
	will take advantage of accurate clocks. This presumes that the NTP 
	server has been secured using strong authentication.

7. Sufficient resources resources. 
	Each system must be able to support a transaction rate of 1200/sec and
   	mean time to respond of 0.5 seconds 5 milliseconds per transaction. transaction as a baseline.  
   	There should be enough extra resources available to support a 15% 50% growth
   	per year in the number of transactions per second without affecting the 
   	response time. Note that these numbers involve system selection and 
   	available infrastructure bandwidth.

8. Representative Representatives on TLD/Root administrator list is are responsive:
        8a. e-mail about required changes will be answered within 24 hours;
        8b. vacations will cause responsibilities to be delegated, not ignored;
        8c. contact numbers numbers, including after hours and emergency, on file 
	    with zone-master senior staff members;
	8d. an escalation/delegation list that has at least three levels of
	    hierarchy.

9. Named.boot file will specify... specify:
        9a. "xfrlist" of local nets and maybe other roots;
        9b. server will use "secondary" from the zone master, not FTP;
            Note that the load of fork & named-xfer for very large zones
            will probably block the machine if concurrent AXFRs are done 
	    with the latest version of BIND (#);
        9c. "options no-recursion" and "limit transfers-per-ns 1". 1";
	9d. "options no-fetch-glue".
	(Equivalences for non-bind non-BIND servers will apply!)

(#) BIND 4.9.3-R-P1 01may96 

10. Network and name server outages will be reported.
	10a. To the root admin and TLD admin lists whether scheduled or 
	     unscheduled.
	10b. via phone to the zone-master senior staff if the outage 
	     unscheduled or if the outage is to occur in less than 24 hours.
	10c. Extended outages may result in exceptional handling situations.

11. Name server and its immediate infrastructure are on uninterruptable 
    power supply. protected against likely
	force majeure (power failures, ...).

12. Address PTR points (only) to ?.root-servers.net, not a "local" name.
	(for root
    TLD servers only! :) will have similar requirements.

Possible Selection Criteria:

1. serves max possible number of low-hopcount endpoints not otherwise served.
2. credibly likely to continuously perform on qualification criteria for
   the duration of the operations contract.
3. stable organization which is considered likely to survive and prosper.
4. Limited exposure to points of failure that may be shared by other, peer
   nameservers.


Security considerations of this memo

   None.

Acknowledgments

   Constructive comments have been received from:
   Jon Postel, Paul Vixie, Michael Patton, Andrew Partan, Michael Dillon, 
   Don Mitchell Steven Doyle, Owen DeLong and other members of the internet 
   community.

Authors' Addresses

	Bill Manning
	USC/ISI
	4676 Admiralty Way 
	Marina del Rey, CA. 90292
	01.310.822.1511
	+1.310.822.1511
	bmanning@isi.edu
--

	Paul Vixie
	Internet Software Consortium (ISC)
	Star Route Box 159A
	Woodside, CA 94062
	+1 415 747 0204
	paul@vix.com

----