Re: .COM Clusters are Not RSCs

[Karl Denninger <karl at mcs.net>]

On Fri, Mar 20, 1998 at 12:25:57PM -0500, Keith Moore wrote:
> > > Another risk is that people will start a 'land grab' on TLDs similar
> > > to what's happened with subdomains of .COM.  Any rules for allocating
> > > new TLDs that are based solely on competition, whether they be
> > > "first-come-first-served" or "my lawyers are bigger than your lawyers"
> > > or even "we have nukes, you don't" robs the net community of any hope
> > > of reasonable organization of TLD space.
> > 
> > Easily dealt with.  You can have "N" TLDs (where "N" is some small number,
> > say, three or four) until you demonstrate through a public audit process
> > that you have at least "X" registrants per TLD in use on average.
> 
> That addresses only one of several concerns.  It presumes that someone
> has the right to "own" a particular gTLD, if he can sign up some
> number of users.  I disagree with that presumption.

Then go argue with every TLD operator currently in existence, including .US.

There is not ONE current TLD that has this policy in the root.  I believe
you and others with this point of view are simply tilting at windmills with
this position, as the precedent is solidly on the other side of the
equation.

> > > Another risk is that the number of TLDs will grow so large that TLD
> > > queries are no longer likely to be in cache.  This has implications
> > > for response time and reliability of DNS, as well as bandwidth usage.
> > 
> > That's a bald-faced lie.  COM/NET/ORG are on the roots right now.  Forcing 
> > NSI to remove them to their own machines, and replacing them with 15,000 
> > TLDs (1% of the current load they carry) is the best possible single
> > performance improvement we could make in the DNS system.
> 
> Read my statement again.  (Hint: I wasn't talking about the load on
> DNS servers.)

Yep.

> Right now, everyone has the NS RR for COM in his DNS cache.  Any query
> for X.COM only has to go to one server, and only takes one round-trip.

This is NOT true.

A query for X.COM has to go to the root server, and THEN to the server which
holds the data for X.COM.  The roots run with recursion off.

This means that the funnel function is FLAT; there is ZERO cache coherency,
since the roots take ALL the hits for the names in the zone (since they hold
the zone) and then refer the hits out to the server with the "A" record (or
MX, or whatever).

> If there were 15,000 gTLDs, chances are that a large number of their
> NS RRs would not be cached.  A query for X.Y would thus require
> additional round-trips.  Each round trip consumes more network
> bandwidth, increases the delay seen by the user, and increases the
> opportunity for failure.  

You are correct, but you proceed from an incorrect assumption.

Having lots more TLDs means that there MAY be a cache miss on the TLD lookup
itself.  But that's not really the issue.  The issue is the lookup for the
SLD within the TLD.  Right now there are a dozen machines that take ALL of
that load for the commercial domains.

With 15,000 TLDs, there are *TENS OF THOUSANDS* of machines across which
that load is spread.  This *increases* reliability and operational
stability.  Further, the incidence of hits on the root servers will drop
some 90% (I'll give you 9% back from 99% due to the cache coherency issue 
at the root - which is, incidentally, NOT the important point).

> Think about the probability of any particular DNS server failing to
> respond (this is a few percent in my experience), multiplied by the
> number of different DNS servers that have to be consulted.  

You have this problem now.  The odds are you will have it LESS frequently
with lots of gTLDs, because of two factors:

1)	TLD servers had better be in well-connected places (or you won't
	have many customers as a registry operator!)

2)	The QUANTITY of references to a given TLD server will be spread
	across the number of gTLDs, DECREASING traffic dramatically to any
	given set of machines, and therefore LOWERING the overall load which
	they are expected to handle.

This means BETTER service, not worse.

> Think
> about the additional delay seen by the user each time a DNS client has
> to time out and fail over to a different server.

Which is absolutely unaffected by this change - the timeouts are, 99% of the
time, coming from the SLD DNS server, which still has to be queried with 1
TLD or 15,000 TLDs.

> Bottom line: the technical problems with DNS and large numbers of TLDs
> can be solved, though perhaps not without changes to widely deployed
> software.  

This is just not true.  No changes are needed, and we have the operational
proof of it in front of our faces every day.

> The real problems are in establishing reasonable rules for
> creation of new TLDs and in seeing that those rules are adhered to.
> These are not technical problems; they're political problems.
> 
> The political problems are proving very difficult to solve, largely
> because of greedy people who insist on trying to carve out a portion
> of TLD space for themselves, at the expense of the net community.  
> I have nothing but contempt for those people.
> 
> Keith

Then you have contempt for the IANA (which manages the .US space and has
granted HUNDREDS of exclusive monopolies under it) and every other TLD
operator out there.

You need to start with Postel, or face reality.

--
-- 
Karl Denninger (karl at MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin
http://www.mcs.net/          | T1's from $600 monthly / All Lines K56Flex/DOV
			     | NEW! Corporate ISDN Prices dropped by up to 50%!
Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS
Fax:   [+1 312 803-4929]     | *SPAMBLOCK* Technology now included at no cost