Maybe it's not that bad. The eventual result is instead of having
a billion .COM SLDs, there are a billion TLDs: all eggs in one
There are simply not going to me billions, millions, or even probably tens of thousands of TLDs as a result of this. It's still a complex several months long administrative process that costs some multiple of $100,000.
As far as I can work out, minus the press noise, the difference is that creating a TLD will take half a year rather than half a decade or more.
basket, the root zone -- there will be so many gTLD servers, no DNS
resolver can cache the gTLD server lookups, so almost every DNS
query will now involve an additional request to the root, instead
of (usually) a request to a TLD server (where in the past the TLD
servers' IP would still be cached for most lookups).
Maybe, maybe not.
Ultimately that is a 1/3 increase in number of DNS requests, say
to lookup www.example.com
if there wasn't a cache hit. In that case, I would expect the
increase in traffic seen by root servers to be massive.
There will probably be a significant increase if there is a very wide takeup of new TLDs, yes.
Conversely load on some of the existing gTLD servers may decrease if the number of domains in active use is spread across a larger number of independent TLDs.
Possible technical ramifications that haven't been considered with
the proper weight,
and ICANN rushing ahead towards implementation in 2009 without
having provided opportunity for internet & ops community input
before developing such drastic plans?
Massive further sell-out of the root zone (a public resource) for
commercialization of the DNS? Potentially giving some registrants
advantageous treatment at the TLD level, which has usually been
available to registrants on more equal terms??
[access to TLDs merely first-come, first-served]
Don't think that is operational and in any case the current system is weighted towards entities who have had domains for eons when they were able to be the first comers, it's very unfair and unequal in the sense that it works against the interests of newer registrants. Definitely not operational though.
Vanity TLD space may make ".COM" seem boring. Visitors will expect
"MYSITE.SHOES", and consider other sites like myshoestore1234.com
or "not secure"
The lucky organization who won the ICANN auction and got to run the
SHOES TLD may price subdomains at $10000 minimum for a 1-year
registration (annual auction-based renewal/registration in case of
requests to register X.TLD by multiple entities) and registrants
under vanity TLD to sign non-compete agreements and other
pernicious EULAs and contracts of adhesion merely to be able to put
up their web site,
As a subdomain of what _LOOKS_ like a generic name.
And, of course, http://shoes/ reserved for the TLD registrant's
billion-$ shoe store,
with DNS registration a side-business (outsourced to some DNS
registrar using some "domain SLD resale" service).
The operational issue is?
Actually your shoe shop still now has a greater number of choices (.com or .shoes) and I can bet that if your scenario comes to pass with a very aggressive and restrictive registrar of .shoes, some enterprising soul will register .boots, .sneakers or .shoeshop etc to make their living on those parts of the market that don't like .shoes policies.
The possibilities that vanity TLD registry opens are more insidious
than it was for someone to bag a good second-level domain.
Questionable and certainly not operational.
Sure, nefarious use of say .local could cause a few problems but
I'd be more concerned about nefarious use of a TLD like ".DLL",
".EXE", ".TXT" Or other domains that look like filenames.
Or .com. Oddly enough I just now found a Windows box and typed "command.com" in a browser URL bar and it did what I expected, when I typed the same thing at a cmd prompt it did something different and I expected that too.
Seeing as a certain popular operating system confounds local file
access via Explorer with internet access...
You may think "abcd.png" is an image on your computer... but if you
type that into your
address, er, location bar, it may be a website too!
To the extent that possibility already exists, there is a reason that web URIs have both a host and path component. I don't see why new TLDs substantially change this. If applications insist on confusing the two then bad things will always happen but that is an app issue.