Subject: Re: Last Call: Root Name Server Operational Requirements to BCP

From: Scott Bradner <[email-masked]>
Date: Sun, 12 Mar 2000 08:17:59 -0500 (EST)

> As has been pointed out in the past, this  document is likely mis-named.

I don't understand the comment - it sounds like Bill is saying
that the doc is misnamed because it only covers what the name says
it covers

Scott

----

>From [email-masked] Sun Mar 12 03:21:12 2000
From: Bill Manning <[email-masked]>
Subject: Re: Last Call: Root Name Server Operational Requirements to BCP
To: [email-masked] (Randy Bush)
Date: Sun, 12 Mar 2000 00:20:52 -0800 (PST)
Cc: [email-masked] (D. J. Bernstein), [email-masked], [email-masked]
In-Reply-To: <[email-masked]> from "Randy Bush" at Mar 11, 2000 11:23:25 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

% 
% > Perhaps you'll say that you don't care whether all the TLDs are broken;
% > you're just worrying about the root zone.
% 
% correct
% 

As has been pointed out in the past, this  document is likely mis-named.
And I believe that simply focusing on root servers is wrong. The "trickledown"
effect is pervasive in the DNS architecture.  RFC 2010 talks about rootserver
expectations and recognises that at the time, there was a co-mingling of
root and TLD service on the same suite of servers. It also comprehended that
the TLD service should be moved to their own sets of servers. This document
seems to retain the view that root and gTLD zones will remain comingled. I
think it is better addressed to the "flat" gTLDs with large numbers of zones.
In any case, I think that Randys focus on just the root is misguided. It is 
important to have compatability betwen parent and child servers. And this 
documents label does not reflect that.

-- 
--bill

---

From: "D. J. Bernstein" <[email-masked]>
Date: 12 Mar 2000 20:35:50 -0000

Scott Bradner writes:
> it only covers what the name says it covers

But that's simply not true. Look at what the document says:

   * The abstract explicitly includes ``other major zone server
     operators'' in the document's audience.

   * Section 1.5 expresses ``great concern'' for the security of data
     ``in the root zone or TLDs.''

   * Sections 2.3, 2.7, and 3.3.9 deal with load problems---which are
     in the .com zone, not the root zone.

If the intent really is nothing more than to secure the root zone, then
I have several objections to the document:

   (1) Securing the root zone, without securing any TLDs, is a stupid
       goal. It does not protect any DNS users.

   (2) The document deceives readers as to its intent. It needs to make
       clear that, yes, it really is focused on this stupid goal, and it
       was written with no consideration of TLDs or any other zones.

   (3) The root zone can be securely and efficiently distributed through
       USENET (backed up by HTTP) as a PGP-signed file, say once a week,
       and installed locally by ISPs. This procedure achieves the goal,
       unlike the procedure in the document---DNSSEC doesn't work. This
       procedure also has much lower cost than the procedure in the
       document: far fewer computers and networks need to be secured.

However, despite Bush's statement, I find it difficult to believe that
this was actually the intent of the document. I'd like to hear comments
on this topic from the other authors.

---Dan

---

From: Randy Bush <[email-masked]>
Date: Sun, 12 Mar 2000 13:00:35 -0800

>      operators'' in the document's audience.

"may find it useful" or they may not.  clearly it is also useful for rabid
soapbox climbing.

>      ``in the root zone or TLDs.''

   1.5 Experience has shown that the internet is quite vulnerable to
       incorrect data in the root zone or TLDs.

which does not imply in any way that the document addresses how to run
anything but a root zone.

>      in the .com zone, not the root zone.

no, they are specifically in the root zone.

randy

---

From: Ray Plzak <[email-masked]>
Date: Mon, 13 Mar 2000 11:23:26 -0500 (EST)

Given the fact that by the end of the year most of the gTLDs will either
be moving or have moved off of the root servers this does not appear to be
a "stupid" goal.  The administrators of the gTLDs will have to implement
security on their suite of servers.  The author's of this document
intended this to be specifically for the root zone but also thought fit to
pass along the observation(s) that these actions would be appropriate for
other administrators such as those of the gTLDs.  Now why would that be
"stupid"?

Ray