# Re: new port for DNS

Michael Mealling (Michael.Mealling@oit.gatech.edu)
Fri, 16 Jun 1995 10:51:10 -0400 (EDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Michael Mealling: "Re: new port for DNS"
- Previous message: Terry Allen: "Re: Question for DNS propronents?"

    From: Michael.Mealling@oit.gatech.edu (Michael Mealling)

    Message-Id: <199506161451.KAA25350@oit.gatech.edu>

    Subject: Re: new port for DNS

    To: mshapiro@ncsa.uiuc.edu (Michael Shapiro)

    Date: Fri, 16 Jun 1995 10:51:10 -0400 (EDT)

    In-Reply-To: <9506161350.AA24281@void.ncsa.uiuc.edu> from "Michael Shapiro" at Jun 16, 95 08:50:59 am

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>

- Next message: Michael Mealling: "Re: new port for DNS"
- Previous message: Terry Allen: "Re: Question for DNS propronents?"