On May 12, 2006 at 18:12 tv@pobox.com (Todd Vierling) wrote:
On 5/12/06, Barry Shein <bzs@world.std.com> wrote:
On May 12, 2006 at 14:51 tv@pobox.com (Todd Vierling) wrote:
The complexity added by TLDs has one extremely critical good side effect: distribution of load by explicitly avoiding a flat entity namespace. The DNS has a hierarchical namespace for a reason, and arguments to the contrary will convince on the order of sqrt(-1) people.
As if you couldn't just hash on whatever the last component is and pick a server on that basis? Query(server[Sum(bytes) mod Nservers])?
There are probably good answers to people's suggestions for change but working backwards from "that's the way we've always done it"
If you bothered to read the 1983 RFCs I mentioned, and others related to machine naming, you'd realize that the DNS of today is not, in fact, "the way we've always done it."
I've been on the net since 1977, nearly 30 years. I participated in the public discussions which led to the current DNS system. I managed Boston University's campus-wide internet environment when the DNS system was implemented ca 1984-5. When my group connected BU to the internet the host table was still in use. Hunt down "BU joins the internet", a typo in our initial update tickled a bug in the bsd hosttable program which brought down about 2/3 of the internet (yes, down.) I can't say I'm proud of that, but it's kind of hard to forget.
The namespace *was* flat, once. That didn't scale, and not just because of technical limitations -- the fact that there are only so many useful combinations of 26 letters in a relatively short name had some weight in there too. So hierarchical naming was standardized (some forms of nonstandard hierarchy existed before then), and it's unlikely we're going back anytime in the foreseeable future.
But there's no technical advantage of a hierarchical system over a simple hashing scheme, they're basically isomorphic other than a hash system can more easily be tuned to a particular distribution goal. There might be political or sociological or managerial advantages, but spreading out requests in a reasonably balanced manner among more than one server is a fairly simple technical problem. So that alone is not really a showstopper. I don't dispute the practical, non-technical issues.
Changing *how* the names are structured into a different hierarchy of organization, I could believe. Changing the fact that they are structured back to being unstructured... the ship has already sailed.
So your argument is that it shouldn't be considered because that's not the way it is. At any rate, as I said in my note I'm not advocating this, I'm just pointing out that some of the arguments against it have been rather shallow, claiming it wasn't technically practical or that's not the way it's been done so that's not the way it will be done. There's no particular technical reason not to flatten the namespace, particularly 30 years later with modern hardware where the compute cost of hashing vs strrchr(host,'.') wouldn't be as much of an issue. There are practical, non-technical issues. My understanding wasn't that the suggestion was to eliminate all hierarchy, only to eliminate the manor TLDs (.com, .net, .org), I believe the example was something like lists.nanog rather than lists.nanog.org. -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo*