I believe there might be a way around the problems we currently face, and
one that seems true to the "spirit" of the global Internet. Perhaps it is
not exactly as I have outlined below, but I do believe there exists a
solution based upon some of the ideas I present and would welcome
discussion. I should note that I am not in a position to develop what I
describe here, as I have other responsibilities. But the problem is not
intractable and the solution now seems rather simple to me.
Before you read on, you should know I think we need to slay some critical
assumptions that stand in our way and so, there be dragons below. Like most
problems, the solution appears to be mostly administrative and so, while
what follows is not expressly technical, you know understand the role the
rootservers provide, but that's about the only requirement.
In short, I propose an adjunct to DNS based upon the following precepts:
1. Decentralization of control
2. Reliance on established protections for intellectual property
3. Integration with the browser to subvert established (and emerging)
controls
4. Reliance on free-market forces to dictate quality of service
5. Reliance on users to resolve name collisions
Most involved in the various arguments related to ICANN et al seem far too
immersed in the political intrigue to appreciate the simple fact that any
real change on the global Internet has come from the bottom up, has never
been legislated or dictated, nor, I believe, can it be controlled. It seems
to me that the problem really is not who will manage/control the namespace,
but that the current namespace is too closely held, which suggests there is
a solution to be had, if we consider the problem in its correct context.
Have you really considered what it might take for the popular Internet to
embrace a co-existing adjunct to for "standard" DNS? (Throughout these
musings, be assured I do not propose the abolishment of DNS. Rather, I ask
you to consider a new service to supplement the current DNS infrastructure,
providing for a vastly expanded namespace, driven solely by market forces
not political intrigue.)
Consider RealNames, what do they provide but a form of name service, albeit
a very closely held and controlled one? As I am sure you know, Realnames is
the creator of a larger namespace composed of registered keywords (Coke,
Ford, Soap, Books, etc.) than that currently supported by DNS.
What makes RealNames interesting to me isn't that they offer a new
namespace, but that they have gotten people to use it. They have
accomplished this monumental feat by integrating this new lookup service
directly into the browser, which in many ways is the surfer's sole window to
the Internet.
True, you cannot send e-mail to RealName 'Coke' via the browser, but you can
navigate to the name holder's web-site and from there attempt to communicate
via the correct channels. (With RealName's recent announcement of inclusion
into the Microsoft IE deliverable, this makes them terrifically powerful.
But again, they control their namespace, exercising editorial mandate over
who can register under the name 'Coke' which in my view is entirely
unacceptable.)
What RealNames has shown, though, is that the Web--as an information
service--has grown large enough to subvert better established, critical
infrastructure services. This is terrifically interesting and, I believe,
suggests a solution to our current woes.
What would it take to create a new service integrated directly into the
browser, where typing a URL that was not served via DNS, like
'http://www.foobar.baz/', into the address field would "do the right thing"
and resolve it to the correct and proper website, located at a DNS-reachable
site? (I call this new service "Golem Domains" since they appear as magical
artificial domains rather than ICANN or rootserver-cabal sanctioned true
domains.)
Not much, as we have seen with RealNames. In fact, the Microsoft IE has
hooks which allow you to do exactly this, with little coding required.
And so, if we can add this service to IE (and presumably NS as well), we are
still left with the apparently intractable issues of who "controls" the .baz
TLD?
Radical thinking perhaps, but I suggest the "control model" is and always
has been the wrong model; it is based upon a single administrative
assumption I feel has now outlived its usefulness and can be replaced: that
all domain names must be unique and thus, there must be a single
authoritative, centrally-located and administered namespace. (Again, please
recognize the distinction I make between established DNS-registered domains
and these new, golem-domains. DNS is critical infrastructure and should be
preserved, but as RealNames has shown, multiple entities can (and do) share
the same navigable name, relying upon the user to disambiguate their use.
But, more on collisions later.
If we discard this assumption of central control, how would we manage a
distributed collection of potentially colliding golem-domain nameservers?
I believe anyone with gumption and resources should be able to "serve"
mappings between golem-domains and their constituent hosts, no matter what
the actual TLD. (Since our client-side resolver would only provide answers
for domain inquiries that were not served by DNS proper, even if someone
wished to create registrations within COM/NET/ORG/etc., it would never be
considered by the browser, as long as the domain resolved via DNS.)
The standard Unix nameserver ("named") supports the serving of any TLD but
relies on the entrenched administrative infrastructure (the rootservers) to
"discover" the correct place to resolve a domain, and as we all know and
love, this model focuses far too much power into machines controlled by a
very few.
If we could decentralize all such control, how would we do it? I'd suggest
we replicate (and distribute) the facility provided by the rootservers and
use something like Usenet to broadcast "authority records" to any entity
willing to run a golem-rootserver (the first-level resolver) for our new
service.
Of course, at first the service is run from a central farm of
golem-rootservers, but the source-code of the golem-rootserver would be made
freely available. Discovery of the proper resolver would first occur by
checking to see if a magic hostname within the current domain existed, and
if not, through a hard-coded hostname in the client that pointed to the
initial golem-rootserver farm.
As the service became popular, ISPs would wish to run their own
golem-rootserver for their customers to reduce bandwidth and, if it could be
made into a simple management-less service (like named), I suspect many
companies would as well.
Ok, we have an integrated client application, a first-level resolver to
point to the authoritative home of host/domain mapping. What's left?
Ahh...the thorny issue of who can create an authority record, and thus
advertise to the world that they provide domain mapping for a particular
TLD?
Again, a radical suggestion, but I believe anyone should be able to serve
whatever TLD they wish, regardless of their technical capability or
financial stability. I am a strong believer in market-economics driving
growth of the global Internet, using this view, golem-rootservers for TLDs
will assuredly come and go, but consumers of golem-domains will quite
naturally gravitate to the most stable, financially secure service they can
find.
Ahhh...cybersquatting and intellectual property issues. Again, I do not
believe this is the issue we all believe it to be. There are mechanisms
extant to manage these problems; we should use them.
If you advertise that you will register new entries within a TLD and believe
you "own" it, you should protect it in the standard manner, through the
courts or other official channels. (I have always believed assuming the
operational infrastructure should bear the burden of policing intellectual
property disputes is nonsense and, as we have seen, a great way for
government to meddle in something that "simply has to work.")
So if I decide to call my web-site foobar.baz, I would need to either become
a registry myself, setting up and running a golem-rootserver, sending the
required authority record and serving domains in .baz, or I would need to
pay someone to provide that service to me.
Whom do I choose to do so? Well, if I choose Joe's Web House and Internet
Domain Garage, I should expect the kind of service one might imagine such a
company could provide, but if I choose AT$T, GTE, or PsiNet or ... I think
you get the picture, as in the really real-world, good service will out.
Finally and once again, name collision: Once registered, either through my
own auspices or via those of my chosen agent registry, by typing
'http://foobar.baz' into the browser I would be presented with ALL the
'foobar.baz's existing in all the self-proclaimed .baz registries, so I
could choose which one I wanted, perhaps retrieving whois-style registration
information from various registries (automatically) to assist in my
decision. (Isn't this how the real-world process of disambiguating
multiple, similar names occurs?) This is, of course, how RealNames
operates.
What if resolution is too slow, perhaps because a golem-rootserver cannot be
contacted expediently, you ask?
Again, the market will dictate the proper level of service and if resolution
is slow or provides too many answers or lacks the answer I am looking for,
domain owners will vote with their dollars.
So,
1. Decentralization of control
2. Reliance on established protections for intellectual property
3. Integration with the browser to subvert established (and emerging)
controls
4. Reliance on free-market forces to dictate quality of service
5. Reliance on users to resolve name collisions
Now, there is a possibility (as I am sure RealNames believes) that such a
service can become DNS's natural inheritor. DNS was created (and should
remain) a mapping between human-readable name and machine-readable address,
but it has been called upon to provide much, much more, due to market
requirements. It is high time to create something that relieves DNS of its
unmanageable burden.
So, who wants to do it first? You don't need anyone's permission.
--
Rob Raisch CTO - RivalWorks, Inc. <http://www.rivalworks.com>
Who do you want to play today?
(I'm responsible for this message, not my company.)
