Re: The Path URN Specification

Martin Hamilton writes:
 > 
 > Daniel LaLiberte writes:
 > | Below is the draft of our path scheme specification.  

 > It seems a bit too complicated.  I wonder whether the sub-node
 > stuff is really necessary - could the resolver not just recurse
 > down to the most deeply nested DNS server ?

...until it fails.

That was our original plan, and it would work reasonably well, but it
means that for every urn lookup, there would necessarily be a hit on
at least one remote DNS server.  The list of sub-nodes for each node
in the TXT records is there precisely to avoid asking DNS to resolve
a domain if it is known that there is no domain that would match.

Nevertheless, there *will* be a hit on *some* remote server for every
urn that is not cached since the "terminal" resolver of httpd will be
hit either way.  If DNS is always hit, that is twice as many hits, but
a factor of 2 is just as scalable over a large number of clients.  Still,
we would rather avoid it for political reasons.

Some changes to DNS itself might be recommended to better support this
kind of use, but we were intent on using DNS as is.  For example, if a
list of one-level down subdomains could be requested, no separate list
need be maintained in the TXT records (hmm, this might be available
already with the "ls" query).

Another implementation issue that the proposal should further address
is how much iteration is involved by which parties.  The path lookup
process is necessarily iterative by design, but so is DNS itself.
When you look up a domain name, DNS logically starts at the top of the
tree and works its way down.  So does path lookup.  Use of caches
avoids most of the need to bother higher level domains, which is
essential to scalability.  So with the path lookup, there will be
iteration between web clients and local DNS resolvers, but for all
cached domains, no remote resolvers need be bothered.  When paths
contain components of the name space that have not yet been explored,
then remote resolvers will be queried, one resolver for each remaining
component of the path down to the terminal resolver.

Daniel LaLiberte (liberte@ncsa.uiuc.edu)
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/

Received on Monday, 20 March 1995 13:10:01 UTC