Subject: Re: draft-dnsop-root-opreq-00.txt

From: Randy Bush <[email-masked]>
Date: Tue, 16 Mar 1999 08:08:49 -0500 (EST)

> 	- Are you writing this for the IANA?

uh, i am writing it for the usual audiences of IETF documents.

> 	- Did you consider/read RFC 2010?

yes, a year or so back, whenever it was published.  i specifically did not
reread it when doing this i-d.  as i said in sg, the iesg and iab were not
overly impressed with it, too much unneeded detail and not enough high
level.

> Most of this is already covered there.

the gossip from those who read both recently is that the subjects in common
are covered rather differently.

randy

---

From: Bill Manning <[email-masked]>
Date: Tue, 16 Mar 1999 08:08:28 -0500 (EST)

A couple of thoughts:

	- Are you writing this for the IANA?
	- Did you consider/read RFC 2010?  Most of this is already
	  covered there.

> Internet Assigned Numbers Authority                          Randy Bush
> INTERNET-DRAFT                                                    Verio
> draft-dnsop-root-opreq-00.txt                                  99.03.15
> 
> 
>                Root Name Server Operational Requirements
....
> 
> 4. Acknowledgments
> 
>    The author would like to thank Scott Bradner, Robert Elz, and John
>    Klensin for their constructive comments.
> 
....
>
> 5. References
> 
> [RFC1035]
>      Domain names - implementation and specification.  P.V. Mockapetris.
>      Nov 1987.
> 
> [RFC1305]
>      Network Time Protocol (Version 3) Specification, Implementation.
>      David L. Mills.  Mar 1992
> 
> [RFC2030]
>      Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and
>      OSI.  D. Mills.  Oct 1996.
> 
> [RFC2181]
>      Clarifications to the DNS Specification.  R. Elz, R. Bush.  Jul
>      1997.
> 
> [RFC2535]
>      Domain Name System Security Extensions.  D. Eastlake, 3rd, C. Kauf-
>      man.  Mar 1999.
> 

-- 
--bill

---

From: Paul A Vixie <[email-masked]>
Date: Tue, 16 Mar 1999 08:08:17 -0500 (EST)

short comments:

>    1.2 The root servers serve the root, aka 'dot', zone.  Although today
>        some of the root servers also serve some TLDs (top level domains)
>        such as gTLDs (COM, NET, ORG, etc.), infrastructural TLDs such as
>        INT and IN-ADDR.ARPA, and some ccTLDs (country code TLDs, e.g. SE
>        for Sweden), these TLDs MUST be moved to separate TLD servers in
>        the near future.

qualified disagreement:  the servers which serve dot should also serve
in-addr.arpa and eiter ip6.int or its late model equivlents.  i agree
that com et al need to move to separate servers.  (we stopped short of
this when we did 2010, for political reasons pertaining to that time but
not to this time.)

>    2.1 It would be short-sighted and presumptious of this document to
>        specify particular hardware, operating systems, or name serving
>        software.  Variations in these areas would actually a source of
>        robustness.

the name server implementation should be "open source."

>    2.5 Root name servers MUST disable recursive name lookup, forwarding,
>        etc.  They also MUST NOT provide secondary service for any zones
>        other than the root zone.  These restrictions help prevent undue
>        load on the root servers and reduce the chance of their caching
>        incorrect data.

and in-addr.arpa and ip6.int.

>        3.2.3 The LAN segment(s) on which a root server is homed SHOULD
>              be separately firewalled or packet filtered to discourage
>              network access to any port other than those needed for name
>              service.

in particular, packets coming from rfc1918 space should be blocked by the
upstream router if possible, or at any rate not responded to by the name
server.

>        3.2.4 The root servers SHOULD have their clocks synchronized via
>              NTP [RFC1305] [RFC2030] or similar mechanisms.  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.

with authenticated ntp.

>        3.2.5 All attempts at intrusion or other compromise SHOULD be
>              logged, and all such logs from all root servers SHOULD be
>              analysed by a central security team to look for patterns,
>              serious attempts, etc.

centralized across what domain?  a particular root's ops team, or the
collected root ops teams?

---

From: Paul A Vixie <[email-masked]>
Date: Tue, 16 Mar 1999 11:27:04 -0800

> I respectfully disagree with the delegations of in-addr.arpa and ip6.int
> being in the roots. IMHO, we need to have organizations that are loosely
> coupled and in control of their own part of the infrastructure. Thus,  I
> think the regional registries and the IANA/ICANN/Numbers Organization
> should decide what they want to do here. If they want their own servers,
> then they should go forward and get delegations from the roots.

this document amounts to instructions to iana in its selection of vendors
to provide root name service.  iana's delegation point is above regional
registries.  it should delegate ipv6 tla's and ipv4 first-octets to whom-
ever.  that means ip6.int and in-addr.arpa are supposed to be much smaller
and change much less often than they do now.

if this is a divisive policy issue then randy's document should defer to
the iana in determining what zones will be served by the "root name servers".

> What is the rational of this requirement? Perhaps someone will want to
> run some commercial solution - could lead to better robustness with
> "separate" code bases.

i expect there to shortly be "several" open source dns implementations and
i hope that this will lead to the robustness you're requesting.  but i'd
like to be able to review the source code to any root name server's dns
implementation, and i'd like the rest of the world to be able to do the same.

---

From: [email-masked]
Date: Tue, 16 Mar 1999 02:23:36 -0500

> this when we did 2010, for political reasons pertaining to that time but

I respectfully disagree with the delegations of in-addr.arpa and ip6.int being
in the roots. IMHO, we need to have organizations that are loosely coupled
and in control of their own part of the infrastructure. Thus,  I think the 
regional registries and the IANA/ICANN/Numbers Organization should decide 
what they want to do here. If they want their own servers, then they should 
go forward and get delegations from the roots.

Thanks,
Mark

-- 

Mark Kosters     [email-masked]      InterNIC Registration Services
PGP Key fingerprint =  1A 2A 92 F8 8E D3 47 F9  15 65 80 87 68 13 F6 48

I am not a spokesperson for NSI. Anything I write or say is my personal 
opinion and in no way should be interpreted as NSI's official position.

---

From: Robert Elz <[email-masked]>
Date: Wed, 17 Mar 1999 10:19:46 +1100

Date:        Tue, 16 Mar 1999 14:53:59 -0800 (PST)
    From:        Bill Manning <[email-masked]>
    Message-ID:  <[email-masked]>

  | What matters is 
  | that all the servers can deliver the same answers to the same question...
  | while ensuring significant diversity to protect against specific attacks
  | on any given piece of the structure.

I agree with that, I didn't mention diversity as I didn't really think of
it as important to the point I was making (the draft already requests that
I believe).

But  

  | I think you have to have both and open source helps ensure that.

I don't follow that at all.   I would have thought that the set of open
source, and proprietary is a larger set than the set of open source alone.
Hence, I would have assumed, greater diversity would be able to be achieved
by permitting either kind of server, not by restricting the choice to a
subset.    That is particularly true while the set of public source DNS
servers is largley of cardinality 1.

kre

---

From: Bill Manning <[email-masked]>
Date: Tue, 16 Mar 1999 14:53:59 -0800 (PST)

> None of this is realistic.
> 
> What actually matters is that the server deliver the same answers as all
> the other servers (those answers being the definition of what is in the
> root zone), and that the organisation running the server be generally trusted
> to operate it correctly.   Nothing beyond that is needed - if they want to
> spend $'s and purchase a commercial server (or a commercial OS, or commercial
> hardware), that's for them to decide.
> 
> kre

Actually, I don't think that is quite right. There is quite a bit to be
said for significant diversity in most aspects of building a resiliant
robust system.  The concerns I have with Randys draft are several but
the one that might be germaine here is the push for uniformity and consistancy.
One of the strengths of the Postel legacy here is the amazing diversity
in the existing structure. If, as Paul Vixie suggests, that this draft
is a template for ICANN instructions to root-server operators, then
I think that this smacks too much of micro-mgmt.  What matters is 
that all the servers can deliver the same answers to the same question...
while ensuring significant diversity to protect against specific attacks
on any given piece of the structure.      

I think you have to have both and open source helps ensure that.

--bill

--bill

---

From: Robert Elz <[email-masked]>
Date: Wed, 17 Mar 1999 08:40:10 +1100

Date:        Tue, 16 Mar 1999 11:27:04 -0800
    From:        Paul A Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

  | i expect there to shortly be "several" open source dns implementations and
  | i hope that this will lead to the robustness you're requesting.  but i'd
  | like to be able to review the source code to any root name server's dns
  | implementation, and i'd like the rest of the world to be able to do the same.

This sounds nice, but of itself is ineffective for anything much that matters.

To actually achieve the objectives, not only would the nameserver source
be required to be "open source" but the operating system upon which it
runs (and anything else important, such as its prom level boot code
probably), and similar sources for all firewalls, routers, and other
intervening boxes between the root nameserver and enough of the net that
compromise of any others of them would not do significant harm to the
root server.

For the truly paranoid, so would the code of the disc drives and controllers
etc, and even the microcode or silicon layout of the chips used in implementing
all of this stuff...

kre

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 17 Mar 99 12:09:23 JST

Bill;

> in the existing structure.

I think it was a good thing that Postel delegated ccTLDs to those people
who have serious concern with a specific contry code.

However, it does not prevent some contryies have their own legislation
about what is the lawful and unlawful root servers.

> If, as Paul Vixie suggests, that this draft

ICANN, as a private secter, has too weak formalism to be an
internationally recognized authority of the root servers
that we need something based on rigid international treaty
supported by at least majority vote of UN.

Some contries can still say ICANN unlawful, though.

						Masataka Ohta