Re: how many roots must DNS have before it's considered broken (Re: ISP network design of non-authoritative caches)

["Steven M. Bellovin" <smb () research att com>]

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