North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: how many roots must DNS have before it's considered broken (Re: ISP network design of non-authoritative caches)
- From: Steven M. Bellovin
- Date: Mon Nov 19 17:54:08 2001
In message <firstname.lastname@example.org>, Simon Higgs writ
>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:
>>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
>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
--Steve Bellovin, http://www.research.att.com/~smb
Full text of "Firewalls" book now at http://www.wilyhacker.com