Re: new port for DNS

Michael Mealling (Michael.Mealling@oit.gatech.edu)
Wed, 21 Jun 1995 16:54:02 -0400 (EDT)


From: Michael.Mealling@oit.gatech.edu (Michael Mealling)
Message-Id: <199506212054.QAA01161@oit.gatech.edu>
Subject: Re: new port for DNS
To: dupuy@smarts.com (Alexander Dupuy)
Date: Wed, 21 Jun 1995 16:54:02 -0400 (EDT)
Cc: mshapiro@ncsa.uiuc.edu, Michael.Mealling@oit.gatech.edu, uri@bunyip.com
In-Reply-To: <9506161545.AA00714@just.smarts.com> from "Alexander Dupuy" at Jun 16, 95 11:45:42 am

Alexander Dupuy said this:
> > 1. Existing DNS servers are already loaded trying to deal with the existing
> > namespace. A new port would separate the load so that if the existing 
> > DNS space becomes too loaded in the future it does not affect the URN
> > namespace and vice versa.
> 
> In fact, this would only separate the load at the root servers; further down
> in the tree, you either are running the regular DNS and URN-DNS servers on the
> same machines, or you aren't.  If you are, running two in.named processes on
> different ports won't reduce the load (it may even increase it).  If you
> aren't, you don't need separate ports, since you already have separate IP
> addresses.

Thinking about this in this way makes sense. Good point...

> > 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.
> 
> There's nothing to stop anyone from creating a URN top-level domain which is
> a completely separate hierarchy (except for the root servers).

As long as everyone recognizes this. I support the notion that the
existing names don't correspond very well and that a new DNS hierarchy
is need. I prefer basing them on OIDs simply because they exist and have
the properties we need.

> > 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 don't know about "optimized"...  In fact, the excessive size of .com is a
> real problem for the root servers, since it requires them to know about far
> too many domains.  I think DNS could probably deal with most reasonable URN
> hierarchies (especially since DNS zones can include multiple levels of domain
> name; i.e. a name like 1.2.3.4.5.6 may only require lookups in the 4.5.6 and
> 2.3.4.5.6 zones).

True. I'm just wondering about lookup times based on very vertical server
trees that change the dynamics of recursive vs iterative lookup...

> > 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 privileged ports.
> 
> All of the DNS-based URN proposals now on the table use DNS merely to locate a
> URN resolver; the final step is done using another protocol (e.g. HTTP).
> Therefore, you only need an in with the system admins if you want your URNs to
> use funky names based on OIDs or the like.  Ordinary people can just run a URN
> resolver on their home machine, and use the DNS name of that machine in their
> URNs.

But using the DNS name of their machine in the URN is not persistant. If
we do that we might as well be using URLs. DNS hostnames as persistant names
has already been shown to be non-presistant beyond the very top levels. 

> This seems to be a reasonable situation, especially given that ordinary people
> may not have the resources to ensure that their URNs will continue to be
> resolvable 10 or 20 years from now.  Any organization which can make that kind
> of commitment will not only have an "in" with the sysadmins, they will
> probably have hired the sysadmins in the first place.

Its not the ones that can hire the sysadmins that concern me. Its documents
generated by regular people that are valuable to historians that people
like the library community want to preserve in some way. The names
need to be able to support that in a way that doesn't invalidate the
name.

> > 5. It gives us a much much easier upgrade path in the future without
> > affecting existing systems.
> 
> I don't see why this is so.
> 
> There are also several arguments against using an alternate port number:
> 
> 1. It will require running an additional DNS server on machines which want to
> support both regular DNS and URN DNS names.

True...

> 2. It will require the establishment of a new set of root servers.  Given the
> overhead involved in being a root DNS server, I'm not sure how many sites will
> step forward to be the first URN-DNS servers.

In the case of the existing DNS that ended up being those that had a vested
interest in seeing it succeed. In the case of URN name space people like
the Library of Congress, NLM, etc will probably take on this responsiblity.

> 3. Users behind firewalls that want to resolve URNs will be screwed until such
> time as firewalls provide proxy service for the URN-DNS port.  Given the
> increasing popularity of firewalls, not just at commercial sites, but even
> Universities (e.g. Brown) this seems like a significant barrier to the
> acceptance of URNs.  If users behind firewalls can use URLs, but can't resolve
> URNs, I think URNs will go nowhere fast.

This is one of the more valid points you have. This point alone could
be a show stopper. Would an alternative based on named being modified to 
allow a port argument to an NS record be acceptable?

-MM

-- 
------------------------------------------------------------------------------
Life is a game. Someone wins and someone loses. Get used to it.
<BR>
<HR><A HREF="http://www.gatech.edu/michael.html">Michael Mealling</A>