In message <5.1.0.14.2.20011119140458.0338d260@oak.higgs.net>, Simon Higgs writ
es:
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: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, error
Full text of "Firewalls" book now at http://www.wilyhacker.com