W3C home > Mailing lists > Public > uri@w3.org > June 1995

Re: new port for DNS

From: Alexander Dupuy <dupuy@smarts.com>
Date: Fri, 16 Jun 1995 11:45:42 -0400
Message-Id: <9506161545.AA00714@just.smarts.com>
To: mshapiro@ncsa.uiuc.edu, Michael.Mealling@oit.gatech.edu
Cc: uri@bunyip.com
> 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

> 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).

> 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 may only require lookups in the 4.5.6 and zones).

> 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

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.

> 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.

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.

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.

I believe that this last problem, in particular, is a fatal one for the idea
of alternate port DNS for URN resolution.

inet: dupuy@smarts.com
Member of the League for Programming Freedom -- write to lpf@uunet.uu.net
GCS d?@ H s++: !g p? !au a w v US+++$ C++$ P+ 3 L E++ N+(!N) K- W M V- po- Y+
     t+ !5 j R G? tv-- b++ !D B- e>* u+(**)@ h--- f+ r++ n+ y+*
Received on Friday, 16 June 1995 11:45:01 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:31 UTC