
| Personally, I like the <eighty-subdomains>.BigCompany.COM. approach; | it just scales better. Less messy. Tastes great. Me too. However, there appears to be some counterpressure to move towards what I perceive as some kind of system which lacks any real hierarchy in the sense of domains. Perhaps instead of trying to "fix" the DNS by creating huge new bunches of things to the right of the last normally-seen dot, we should move towards something completely different. Maybe instead of: <whatever>.COM being considered as three tokens and being looked up as: ask a ROOT nameserver for COM NSes ask a COM nameserver for <whatever> NSes ask a <whatever> nameserver for appropriate info (all modulo caching) instead we treat it as (leaving out the '<' '>' stuff out of laziness): <w><h><a><t><e><v><e><r><.><c><o><m> and look up like this: ask a ROOT nameserver for M NSes ask a M nameserver for O NSes ... ask a <w> nameserver for appropriate info that will scale to a huge number of generally unformatted labels for things. This strikes me as a practical way of moving towards ".Earth" and ".Alt" and thousands of other "top-level-domains". Other than technical scalability, the other general design goal for any changes to the status quo wouuld have to be administrative scalability. As a too-easy example, in this model that's essentially making sure an overworked or evil delegator for $origin ever.com won't break the ability of people wanting $origin whatever.com or $origin never.com from going about obtaining those names. Perhaps some form of automagic registration scheme should be available to allow for others to initiate any rightwards growth of names unless they involve certain charaters (like '.', perhaps, so as not to overly confuse people who are used to foo.bar.com being under the administration of whoever is in charge of bar.com). Again, I worry about being wasteful of other people's time here; this could be a non-issue for operators big and small for all I know, so I'll drop back into read-only mode for a bit, and let smarter DNS people and folks more in the trenches talk it out (or ignore it). Sean.

(I keep thinking -- what has this got to do with North American Network Ops?)
instead we treat it as (leaving out the '<' '>' stuff out of laziness):
<w><h><a><t><e><v><e><r><.><c><o><m>
and look up like this:
ask a ROOT nameserver for M NSes ask a M nameserver for O NSes ... ask a <w> nameserver for appropriate info
That's an implementation detail; the protocol won't (I mean, wouldn't :-)) have to change at all to support this.

Sean Doran writes:
instead we treat it as (leaving out the '<' '>' stuff out of laziness):
<w><h><a><t><e><v><e><r><.><c><o><m>
and look up like this:
ask a ROOT nameserver for M NSes ask a M nameserver for O NSes ... ask a <w> nameserver for appropriate info
that will scale to a huge number of generally unformatted labels for things.
Indeed, but this makes many assumptions, like that all of these machines will always be up. Having so many machines is just asking for more trouble; more points of failure. And in this case, each nameserver is potentially a single point of failure.
This strikes me as a practical way of moving towards ".Earth" and ".Alt" and thousands of other "top-level-domains".
Blech, not all that pleasent a concept, although with the incredible polution of namespace that is happen, it's probably one of the only options. Alec -- +------------------------------------+--------------------------------------+ |Alec Peterson - chuckie@panix.com | Panix Public Access Internet and UNIX| |Network Administrator | New York City, NY | +------------------------------------+--------------------------------------+

Maybe instead of:
<whatever>.COM being considered as three tokens and being looked up as: ask a ROOT nameserver for COM NSes ask a COM nameserver for <whatever> NSes ask a <whatever> nameserver for appropriate info (all modulo caching) instead we treat it as (leaving out the '<' '>' stuff out of laziness):
<w><h><a><t><e><v><e><r><.><c><o><m> and look up like this: ask a ROOT nameserver for M NSes ask a M nameserver for O NSes ... ask a <w> nameserver for appropriate info that will scale to a huge number of generally unformatted labels for things.
And, unfortunately, scale to taking huge numbers of seconds for stuff that isn't already cached. I just queried a bunch of sites and got times from .1s to 8s for 3-lookup queries. While I'm willing to wait for 10 seconds for a return, I'm not sure I'd be willing to wait 1.5 minutes. People have this perception that the net should go fast (unfortunately even when they're dialed up with 2400bd modems :-). This'll be a win for a.com, but a real lose for CompuServe.com :-). ...arun --------------------------------------------------------------------------- Arun Welch 5000 Arlington Centre Blvd Lead Software Engineer Columbus, OH 43220 CompuServe awelch@csi.compuserve.com
participants (4)
-
Alec H. Peterson
-
Arun Welch
-
Paul A Vixie
-
Sean Doran