Re: draft-manning-dnssvr-criteria-01.txt

[[e-mail]]

> 
>     Date:        Mon, 6 May 1996 14:22:56 -0700 (PDT)
>     From:        [e-mail]
>     Message-ID:  <[e-mail]>
> 
>     Actually, both points 3 & 4 have some security implications.
>     In general, its easier to trust/secure something that has
>     reduced complexity. 
> 
> Yes, though I'm not sure the number of interfaces is all that
> important, almost nothing depends on any particular interface,
> a server that is vunerable through one will be almost always
> vunerable through all.
> 
>     Expect -03 shortly.
> 
> And what happened to -02 ?
> 
> kre

	-02 was some editorial changes that Paul had asked for
	and Brians excise of the draft nature of the docuement.
	In addition it included a first cut of removing the ISO-TLD
	constraints, leaving in the hooks for the generic TLDs.
	-03 pulled all reference to any TLDs, with a caution that
	this document might be interesting reading for "serious"
	TLD admins.... Here it is:


Internet Draft                				    Bill Manning
May 1996                                                	     ISI 
							      Paul Vixie
Expires in six months						     ISC


                 Proposed Technical Criteria for Name Servers
		    draft-manning-dnssvr-criteria-03.txt

Abstract

   This draft proposes criteria for name servers and their environments that 
   will support zones for 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 may hold. For example, it is expected that TLD servers may 
   field more queries and the root servers may be more concerned with cache 
   pollution. There are some feelings that if you want to (and have the
   resources to) run a high quality nameserver anywhere in the DNS hierarchy, 
   these criteria may be considered.

   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 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 a basic set of requirements for high availablity name server 
	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 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 user accounts, just the operations & admin or root account.
	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.
	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 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. 
	Each system must be able to support a transaction rate of 1200/sec and
   	mean time to respond of 5 milliseconds per transaction as a baseline.  
   	There should be enough extra resources available to support a 50% growth
   	per month in the number of transactions per second without affecting the
   	response time. Note that these numbers involve system selection and 
   	available infrastructure bandwidth.

8. Representatives on root administrator list 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, 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:
        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";
	9d. "options no-fetch-glue".
	(Equivalences for non-BIND servers will apply!)

(#) BIND 4.9.3-R-P1 01may96 

10. Network and name server outages will be reported.
	10a. To the zone admin list 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 protected against likely
	force majeure (power failures, ...).

12. Address PTR points (only) to ?.root-servers.net, not a "local" name.

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, 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
	+1.310.822.1511
	[e-mail]

	Paul Vixie
	Internet Software Consortium (ISC)
	Star Route Box 159A
	Woodside, CA 94062
	[phone]
	[e-mail]

-- 
--bill