In message <5.1.0.14.2.20011119140458.0338d260@oak.higgs.net>, Simon Higgs writ es:

At 05:21 AM 11/19/01 +0000, you wrote:

...

Once we start down the slippery slope of "I'm a root too", how many different ad hoc DNS "universes" (for lack of better term) must we have before we decide that things are "broken"?

Two. That happened back in 1996 when the IANA TLD applicants began getting their glue added to AlterNIC. Today lack of entry in the root has created a dozen or so more alt.roots. Now people are beginning to notice the consequences (i.e. the .US zone is now causing cache pollution outside the legacy root since it's using the ICANN .BIZ name servers - and that .BIZ isn't recognized by all the alt.roots).

See what happens when there's more than one root?

But it's OK. Really. There's only one root. Honest. Except for this one, which is being run with all the usual I* blessings:

http://www.isi.edu/otdr/

...

Maintaining a single, authoritative root seems, IMHO, to be a Good Thing. Given multiple registries, namespace collisions would get ugly -- and, even in the absence of collisions, let us consider "reachability" issues.

Don't confuse the question of the number of servers with the technical question of what a root is; that's determined by the content.

That's the point. Getting the alt.root "universes" to cooperate is an exercise similar to "cat herding", but it has to start somewhere.

Please -- if folks "co-operate" properly, there's one root. Don't confuse the question of how many roots there should be with who should decide the contents. Whether or not ICANN should be the sole decision-maker is a purely political question, and out of scope on the ICANN list.

Simon

-- DNS is not a sacred cow that cannot be replaced by something better.

Sure -- my estimate is that that will take ~8 years: 1-2 years to design, 1-2 years of coding, testing, and interoperability testing, at 5 years for the installed base of machines to be replaced, since most machines are never upgraded. And you have to climb uphill against that installed base, and against folks who don't understand why they should populate your new database when they've already populated (and paid, both directly and in support costs), for the existing database. I'm not saying that you're wrong -- in fact, I agree that the current scheme is showing its age in many different ways -- but don't underestimate the difficulty of replacing it. (The only similar example I can think of, in terms of its impact on both end systems and the infrastructure, is IPv6 -- and we all know how much of that is deployed.) --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com