Re: new port for DNS

Michael Shapiro said this:
> Michael Mealling wrote:
> |Michael Shapiro said this:
> |>    What is the reason for wanting a new port for DNS?   Isn't  it
> |> enough  to  create  new  top level domains?  Running DNS on a new
> |> port would mean installing DNS everywhere to run on this new port
> |> (ie  deploying  a second DNS). It you use an new namespace within
> |> existing DNS (ie a new top level domain) can't  you  achieve  the
> |> same effect?
> |
> |Several reasons:
> |
> |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.
> 
>    This seems a reasonable thing - to separate the load. I'm  not
> convinced  that  a new port is the way to do this, however. Might
> there be a better way that hides the implementation  rather  than
> exposing  it to the clients (ie a new port). For example, at NCSA
> they have multiple httpd's running and the visible one  (on  port
> 80) mutiplexes the requests that come in to these others. But the
> resolution in the browsers only uses port 80.

That's one way to do it if you have a budget that can support it.
I would argue that many more DNS servers are running on things like
lowly Sparc2 and/or Linux boxes. Think of the loading and customization
problems if the httpd daemon could only run on port 80. 

> |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.
> 
>    This doesn't seem correct. A top level domain would accomplish
> just  this. There is no requirement requirement that the new name
> space have  anything  to  do  with  the  exsing  name  space.  In
> particular, the new name space can have its own name servers.

Domains names have nothing to do with the actual structure of the
tree that all those NS records point to. A new domain still means
you are probably loading the same sub-trees in many locations.

>    I just had a thought about the new port. It would be great get
> DNS  itself  to  change  the  port  when contacting a DNS NS, for
> example by encoding the port in the NS record. Want to  run  this
> by the DNS folks?

I already have. Paul Vixie didn't have a problem with it. I've been
hacking named code and it could be a little hairy making those
changes. Running whole trees on new ports is easier and less chaotic
but that's not necessarily a bad thing. I would prefer this solution
but it calls for a much more fundamental change to named.

> |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.
> 
>    Why do you say this? Do you meman the caches are optimized for
> flat  (ie,  the just have a list and sequentially search it)? Are
> you proposing to recode DNS nameservers, then, and  deploy  these
> new  servers as well?  If the caches are this weak, talk to Paul
> Vixie about getting them fixed.

I'm just saying that with named on different ports we could optimize
trees and software implementations based on the needs of that new
name/tree structure without affecting the existing DNS name/tree space.

> |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.
> 
>    This seems to be a politcal/organizational  issue.  I  suggest
> that  URNs  should  have  this  burden  in  order  to  really get
> persistence. The current paractices that  DNS  admins  have  will
> change with time as the web matures.

I guess this is my libertarian nature coming out. If our users had
to run httpd on privilidged ports half of our campus servers
wouldn't exist because the user running the httpd would never get
access to root to run it.....

> |5. It gives us a much much easier upgrade path in the future without
> |affecting existing systems.
> 
>    I can't think this  one  through  -  I  don't  understand  the
> upgrade path issues well enough. Can you elaborate?

Lets say in 7 years we decide that we need a new namespace based on
ISDN address numbers that are hierarchical but have levels that
are very heavily populated. The requirments on the server for each
level are such that it needs a complete rewrite that is incompatible
with the existing namespace. By building the new system on another
port we have an easy migration path that allows for easy backward
compatibilty and a fairly painless transition.

Upgrade paths are made much easier when systems can be run in 
parallel for extended periods. This was one of the primary concerns
with the migration path for IPng....

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

Received on Friday, 16 June 1995 10:50:21 UTC