Message-Id: <9402211053.AA08961@mocha.bunyip.com>
To: uri@bunyip.com
Subject: Re: Finding URN->URL servers
Date: Mon, 21 Feb 1994 05:53:13 -0500
From: John Curran <jcurran@nic.near.net>
IF the Internet had a general mechanism for registering multiple
servers for the same service, then we would simply register (N)
URN servers in each domain to provide this function. For example,
if NEAR.NET was going to be issuing URN's in the near future, then
we would go through the effort to have several machines setup as
URN servers.
Currently, there is support for redundant server registration in
two Internet protocols: DNS and SMTP. DNS redundancy is handled
by defining multiple NS records for a given domain:
foo.com. NS ns.foo.com.
NS nic.near.net.
Likewise, MX records provide redundancy (and even prioritization :-)
for SMTP mail servers in a given domain.
Now before folks go off and advocate the creation of "US" (UR* Server)
DNS record, I'd like to examine the downside of the current mechanism.
Just because this model works well for DNS and SMTP, it does mean that
it is the ideal mechanism for other servers.
One of the major problems with DNS-based server registration is that
it's basically static. Yes, it is possible to perform interesting
games to get the records to change quickly, and there is a dynamic
update draft for DNS, but currently the information in the name server
only changes as a result of manual configuration. As a result, one
cannot just fire up another 4 servers on short notice to handle a
workload peak, nor is it possible to change servers for a given service
without having performed very careful DNS planning in advance.
Over the course of many years, I've heard folks express the desire for a
more dynamic service architecture for the Internet; an architecture in
which it would be possible to provide arbitrary services with multiple
redundant servers. Such a architecture could be provided with a dynamic
registration protocol for servers which included such information as the
domain served, priority, system and port number of execution. An enchanced
version of TCPMUX (for example) could be used to query or modify the
"server registration service".
This would also have immense payoff for other fully-replicated servers
(which many ftp, gopher and WWW need today. Each server program would
call create-server with the appropriate arguments, for example:
{ register this host as html server for the served domain, priority 10 }
create-server("HTTP", "near.net", 10, "www.near.net", my_listen_port, key);
Given such an infrastructure, it would trivial to add the necessary
URN services, as well as replicate entire servers for load leveling
on a moment's effort. Sorry to rambling down this tangent, but it's
about time for us to consider the Internet infrastructure which exists
_above_ the basic transport services.
/John