Re: Multiple Roots are "a good thing" - Karl Auerbach

["Douglas A. Dever" <dever () hq oh verio net>]

On Mon, 19 Mar 2001, Patrick Corliss wrote:

> Read carefully, Andrew McLaughlin is saying there's a need for uniqueness as
> otherwise the same name will resolve in different ways.  He is arguing, like
> you, that the *only* way to resolve the problem is with a unique (read "ICANN")
> root.

At the risk of being pedantic, he never actually says ICANN is the one and
only true unique root, thou shall have no other roots before me.  You're
making an assumption there.

 
> It wasn't that many years ago in the United States when there was one big,
> monolithic telephone company.

Really?  Even 30 years ago the phone company was a mixture of local
operators and AT&T.  

 
> It was taken as gospel by many that the stability of the telephone network
> depended on there being one unified, monolithic telephone company.
>
> We've seen through that.  Today we have a flourishing competitive telephone
> system filled with all kinds of commercial and technical offerings that were
> inconceivable during the days of "Ma Bell".

I'm hard pressed to think of a CLEC that is "flourishing."


> I assert that just like the telephone system can have multiple publishers of
> telephone directory services, the Internet can have multiple roots to the Domain
> Name System.

As a collective, we can't agree that
the sky is blue - how do you plan on us comming to a concensus on who
uses what TLD's?  This isn't as cut and dried as a phone book... people
register domain names and expect that they are the only one with that
domain name, just as I assume when someone calls my cell phone number,
they are going to reach me, and not Uncle Billy's Country Store.  I
expect when someone enters my host and domain that they're going to
end up at my host and domain, not where some local network admin
decides it should point to.  Domain names are more permanant to users than
the IP addresses they resolve to.

> In other words, you, or I, or anybody could establish a group of computers to
> operate in parallel with, and not necessarily in administrative coordination
> with, the legacy A-L.root-servers.net computers now operated by NSI, IANA, ICANN
> and others.

We can all  provide .xxx and have conflicts everywhere.  That's a great
idea.

 
> to find a server handling a TLD named in the query.  In other words, a root
> server only answers queries such as "Where do I find a server that contains the
> list of names in .com?".

This brings us back to the orignal reason there's so much resistance to
the idea of multiple root zones... what happens when I point to server A
for .blah and you point to server B to server .blah.

> What happens when we begin to think of the Domain Name System not as an
> intrinsic core service of the Internet, but rather as an elective service that
> can be offered by many providers and among which customers and user select based
> on the packages offered by the providers?

Aha, the let's back DNS more like Usenet argument.  I'll pass.

 
> I'll give you a preview of the answer: We end up with a stable Internet with no
> loss of reachability.  

What do DNS and routing have in common?

> Thus, a user of a root server system will perceive a Domain Name name space
> composed of the TLDs in the store (the root server system) that that user has
> elected to use.

With the average clue level of the internet user dropping like an acme
safe, I can hardly believe we're advocating makeing the system more
complicated for them to find where they want to go.

 
> Now, I should mention, that when I say "user has elected to use", I don't really
> usually mean the end-user directly.  In most cases, the end-user will have
> delegated the choice to that user's ISP or to his or her organizational
> information manager.  Of course, the technically inclined, such as myself, will
> tend to make the choice for ourselves.


Of course, we're going to be barraged by phone calls "How come when I go
to foo.bar on AOL I get to website X, but when I go to foo.bar on your
service I go to website Y?"  This is a great idea.

 
> If we look at this through the eyes of a businessman operating a root server
> system, we realize that there are two elements that the customers will care
> about: TLD coverage and value added services.

The idea of considering DNS to be just another value-added service is
absurd.  
 
> The net result of all the root system operators following this strategy will be

chaos.


> TLDs that are being contested are not very viable.  Thus, if two or
> more claimants were offering different versions of a TLD named ".foo", it would
> be unlikely that any root system operator would add any version of ".foo" to the
> inventory.

Hardly.  I think we've seen enough poor practices and clueless marketing
folks think up just "great" ideas.  Use our freeze-dried, oven-fresh, .foo
instead of UUnet's... it's terrific.  Act now. Supplies are limited.
Hurry!  Operators will be forced to carry one or the other due to customer
pressure.  It's a lose-lose situation.  You can offend all the customer
base by refusing to carry a contested TLD at all, or just the half that
wanted to go to Server X instead of Y.

 
> This tends to remove the issue of TLD ownership from the current ICANN
> regulatory framework and place it where it belongs -- in the traditional give
> and take world of business and open market economics.

We can take the issue of NPA/NXX ownership from the current NANP
regulatory framework and place it where it belongs -- in the traditional
give and take world of business and open market economics.  
Bah.

> An example of a value added service would be that of filtration -- A root server

For an example of how this works in practice, examine the mess that is
Usenet.

> standards.  And it is a mechanism which allows any member to opt out of the
> community, and its restrictions, simply by selecting another root server
> operator.

Of course, it's difficult enough for many users to figure out how to send
an e-mail and/or assign a mail server to their POP client.  We should be
putting more issues like this into their hands since we obviousally don't
spend enough on customer support yet.  Or something like that.

 
> Yes, there are other ways to achieve the same kind of filtering, but who are we
> to say which methods are the most viable?  Indeed, we should be careful not to
> dismiss, or worse to foreclose, an area of Internet entrepreneurship simply
> because we don't see the immediate value.

No, it has an immediate effect on the value of our companies.  From a
provider point of view, it's going to seriousally increase suppport costs.
There's a direct negative effect.


> One of the reasons is that the existing system has so far worked reasonably
> well, so there has been little pressure.  But there is a very strong secondary
> reason -- those who have advocated or established a multiple root system have
> been shunned by the technical community.

Rightly so.

There are a couple of usability issues that this argument conviently
overlooks.  A telephone has a very simplistic interface and there are
people in the shallow end of the gene pool who still can't use them
correctly.  Once you enter the number you want to dial, everything
associated with putting the call together is handled for you, and the call
is connected. A computer has the potential to be a much more complicated
interface, especially for someone who isn't all that computer-savvy.  You
have to assign resolver addresses, assign mail servers and news servers,
have a username and password, etc. Everytime you switch ISPs, the set-up
is different... some do all the work for you, some expect you to do all
the work.  I can understand where it would be confusing to some, therefore
I can't advocate making the system more difficult or confusing.

Further, the argument of DNS simply being a phone book is over-simplifying
the issue.  DNS requires uniqueness because of the way that it's been
implemented.  We use it in place of an IP address.  The PSTN has
nothing like this.  You can be damn sure that if someone was able to pick
up the phone and put in dever.call instead of dialing 11 digits, there
would be a procedure to make sure there weren't conflicts.

--
Douglas A. Dever    dever () verio net
Network Engineering Manager
Verio - http://www.verio.net