Re: new port for DNS

Keith Moore (moore@cs.utk.edu)
Fri, 16 Jun 1995 13:22:14 -0400


Message-Id: <199506161722.NAA03457@wilma.cs.utk.edu>
From: Keith Moore <moore@cs.utk.edu>
To: Michael.Mealling@oit.gatech.edu (Michael Mealling)
Cc: mshapiro@ncsa.uiuc.edu (Michael Shapiro), uri@bunyip.com, moore@cs.utk.edu
Subject: Re: new port for DNS 
In-Reply-To: Your message of "Fri, 16 Jun 1995 09:19:48 EDT."
             <199506161319.JAA22330@oit.gatech.edu> 
Date: Fri, 16 Jun 1995 13:22:14 -0400

> 1. Existing DNS servers are already loaded trying to deal with the existing
> namespace. A new port would seperate the load so that if the existing 
> DNS space becomes to loaded in the future it does not affect the URN
> namespace and vice versa.

Huh?  If you run two servers on the same machine, they both contribute
to the load on that system.  If you run them on different hosts, it's
not a problem.

> 2. DNS server trees often do not correspond very well to the trees needed
> for information hierarchies. A seperate port would allow the two DNS
> trees to coexist but not comingle.

Depends on how the naming authorities are defined.  If a decision is
made to use DNS, we would define naming authority names in such a way
as to work well with DNS.

> 3. DNS servers are optimized for an extremely flat namespace (look at 
> all the .com domains with no subdomains). A new namespace could
> potentially have a much different organization and hence caching requirments.

I wouldn't say that DNS servers are optimized for this case so much as
that they've had to deal with it.  The current burden in .com clearly
stretches the originally anticpiated use of DNS; else they would have
designed in incremental update from day one.

Anyway, whether to run different server code is a separate issue than
whether to use a different port.  For the near term at least, it would
be nice to be able to use vanilla named.

> 4. In order for URNs to be 'public'. I.E. we allow anyone to publish, not
> just those that have an in with the system admins; we need the URN 
> resolution process to be able to take place on non privilidged ports.

Not if we separate the process of *location* of a resolution service
from the resolution service itself.  DNS will do just fine for the
former; not nearly so well for the latter.

> 5. It gives us a much much easier upgrade path in the future without
> affecting existing systems.

We can have easy upgrade now, or later.  We know what our current
needs are.  How well can we anticipate our needs even a few years from
now?

Anyway, if we use DNS only for location of the resolution service, we
can easily add additional resolution services (protocols) later.  So
we still have an upgrade path.

Keith