Subject: I-D ACTION:draft-ietf-dnsop-root-opreq-00.txt

From: [email-masked]
Date: Tue, 08 Jun 1999 07:16:14 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name Server Operations Working Group of the IETF.

	Title		: Root Name Server Operational Requirements
	Author(s)	: R.Bush, D.Karrenberg, M.Kosters, R.Plzak
	Filename	: draft-ietf-dnsop-root-opreq-00.txt
	Pages		: 9
	Date		: 07-Jun-99
	
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.  The primary focus of
this document is to provide guidelines for operation of the root name
servers.  Other major zone server operators (gTLDs, ccTLDs, major
zones) may also find it useful.  These guidelines are intended to
meet the perceived societal needs without overly prescribing
technical details.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-root-opreq-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dnsop-root-opreq-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsop-root-opreq-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Chris Yarnell <[email-masked]>
Date: Thu, 17 Jun 1999 11:49:49 -0700 (PDT)

Hi,

   2.7 Root servers MUST NOT answer AXFR, or other zone transfer,
       queries from clients other than other root servers.  This
       restriction is intended to, among other things, prevent
       unnecessary load on the root servers.

So, I still have some questions about this section of the draft:

1) If load on the server is the driving factor for this, why is it a MUST
and not a SHOULD ?  I would imagine that the operators of certain servers
would be in a better position to decide whether they have the resources to
allow it, or not (with a strong recommendation that they "SHOULD NOT".

2) If there are other factors that require this to be a MUST, please list
them.  Security?  Confidentiality?  Stability?  What?

Note that we have disallowed AXFR at E for several years, so we are not
looking to 'get around' this being a MUST for our own sake.  

I just don't think we should be dancing around this.  If people want to
codify a requirement that root servers disallow AXFR's for zones, the
technical reasoning for such a requirement should be included..

Perhaps if you could explain your thinking, it'd make better sense to me.

Tnx.

---

From: Chris Yarnell <[email-masked]>
Date: Wed, 20 Oct 1999 11:16:53 -0700 (PDT)

---------- Forwarded message ----------
Date: Thu, 17 Jun 1999 11:49:49 -0700 (PDT)
From: Chris Yarnell <[email-masked]>
To: DNSop List <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-dnsop-root-opreq-00.txt

Hi,

1) If load on the server is the driving factor for this, why is it a MUST
and not a SHOULD ?  I would imagine that the operators of certain servers
would be in a better position to decide whether they have the resources to
allow it or not (with a strong recommendation that they "SHOULD NOT".

Tnx.