The IFWP you refer to was not the source of ICANN. Rather, it was Joe Sims of Jones Day who worked in secret, making unknown agreements with unknown parties for unknown quid-pro-quos who created the ICANN we know today.
The IFWP process was derailed by a self-appointed steering committee that included, among others, the person who (unknown to the public) soon be named the President of the new ICANN.
One of the dates coming up on the ICANN calendar this summer or very early autumn is the renewal of the Memorandum of Understanding between ICANN and the Nat'l Telecommunications and Information Administration (NTIA) [part of the US Dept of Commerce].
That MoU is the vehicle through which ICANN gains most of its authority over DNS. See http://www.icann.org/general/agreements.htm for a pointer to the MoU and its series of amendments.
I was on ICANN's original internationalized domain name committee. We pretty much decided to do whatever the IETF says to do. That still feels like an appropriate answer and is consistent with the notion that ICANN ought to merely coordinate rather than dictate technology.
Although DNS is defined to be 8-bit clean, there are ancient relics in the standards about how some names have to be in a reduced alphanumeric plus hyphen character set.
What scares me is this: There are a lot of DNS engines out there that might be surprised to suddenly find characters outside of that character set. And some of these engines are in surprising places - firewalls, NATs, web caches, etc. I had an experience in which someone was tunneling audio via DNS UDP packets and for some reason a mongo sized Cisco in the middle was parsing those packets and crashing IOS.
And internationalized names can creep in even when it appears that standard ascii is being used - imagine an ascii name that maps to an internationalized CNAME.
I tend to agree with John Klensien that the best way to deal with things is to push for new things to be layered on top of DNS, thus making DNS largely invisible, and to try to get people to start being blind to the semantics of the DNS character strings. Sounds impossible until one realizes that the method adopted by the IETF - ACE encoding - will mean that we start seeing DNS names that look like bq--3kdhyekjayy.org floating around.
Just wait until gethostbyname() sees some of these things - imagine a domain name that contains things like dots, nulls, asterisks, etc inside each of the DNS "labels". I'm dreding the day when I see see "rm -rf/" as a DNS label!
There is no disaster if everyone picks their own root system. In fact there is a very definite benefit - the data is distributed more widely, points of traffic concentration are reduced, and the vulnerability of the entire system to data polution via bad root zone files is reduced.
The issue is not whether there are multiple systems of roots - the issue is whether they are consistent. Right now those who are operating root systems the compete with the ICANN/NTIA/NSI legacy root are offering supersets. How one views an enhanced service depends on whether one is in the "I chose not to move forward with the times" camp or the "I upgraded to a more complete service" camp.
DNS has largely failed on the real issue: invarience.
There are three questions:
- Does the meaning of a DNS name change depending on who utters the name (client invarience)?
- Does the meaning of a DNS name change depending on where the name is uttered (geographic invarience)?
- Once bound to a meaning, does the meaning of a DNS name change over time (temporal invarience)?
On all three of these counts DNS fails. Content management systems have broken the first kinds of invarience and, among other reasons, our simple inability to distinguish between containers and the information they contain has broken the latter.
I've run my own root server - it takes a small amount of work to keep the referral addresses up to date. One easy way is to write a simple script that uses dig to hoover-up delegation information from any of the legacy root servers.
I find it easier to use one of the competing root systems. I use the ORSC one. It has been quite reliable over the years - in fact it has been better than the ICANN/NTIA/NSI one (it didn't lose.com for several hours a while back.)
There is already a rather lose group of root system operators who try to avoid doing silly and ultimately unproductive things like having two different versions of the same name but with different contents.
All that DNS needs is somebody to edit the root zone file (which implies chosing between competing demands for the same name - a situation that can be readily and inexpensively handled by a first-come-first-served rule) and to make sure that those who run the root servers are reasonable and responsible folks who follow the protocols defined by the IETF.
ICANN, however, has expanded its role into all kinds of unnecessary things - like creating a worldwide trademark law and its own system of kangaroo courts with a jurisprudence that would make Judge Roy Bean blush.
ICANN has also decided that it needs to engage in massive (and expensive) nano-management of DNS sellers - ICANN has even mandated the minimum that these sellers must spend on marketing! ICANN plans to spend every penny of that $2,400,000 that it received in application fees just to "deploy" seven new top level domains - ones like.museum,.coop, and.aero, or.name. That kind of negative innovation will turn the Internet into a reprise of the 1950's telephone company in pretty short order. With ICANN at the helm we can expect more imagination in coal mining than in Internet naming technology.
ICANN's "Governmental Advisory Committee" (GAC) is composed only of government representatives - so we can get a hint of what government in ICANN - and thus government in DNS - will look like. The GAC has proven that while it has utterly no comprehension of net technology, it is able to blither for days on end to find just the right euphemism to put into a communiqe. And when it comes to making choices, the assembled governments of ICANN's GAC have demonstrated repeatedly that they tend to sacrifice their citizens pocketbooks, property, and privacy to the predators of the net - among them NSI and the trademark industry.
What ICANN's president's plan does is to eliminate what few constraints had existed on the ability of ICANN's management to do what they pleased, which seems to be to build empires to the sky and to engage in massive travel (one ICANN staffer travels to about 50 international venues per year!) Under the president's plan, ICANN's yearly budget goes up tenfold to several tens of millions of dollars per year!
Public participation in ICANN - if it were ever to come about would provide a check to these excesses.
And such public oversight is sorely needed - ICANN's management cares not a damn for the internet community or net users. And ICANN's management has demonstrated that its goals, and its methods, are not all that far from those of Enron, except that ICANN has the benefit of being being exempt from taxes.
In the movie Coconuts Grocho Marx said about the swamp property he was auctioning: "Oh, you can get stucco, oh, you can really get stuck oh." ICANN's president's plan is the same kind of swamp - and we are all going to get very stuck unless we oppose it, prevent it, and come up with a plan for an truely limited ICANN.
ICANN's management created this monstrosity on its own initiatiative - it is esssentially an act of gross insubordination by ICANN's management and an act of disdain for the Board of Directors and for the internet community.
This "restructructuring" is a complete recreation of ICANN, but with even the hint of public participation stripped away.
I just go off the airplane home from this ambush. I'm really ticked off.
This kind of thing was being done in 1968 - check out the UC Irvine "Distributed Computing System". If I remember right it went well beyond things like file sharing among relatively autonomous machines, it even had the memory allocator running on different machines than those holding the memory being allocated.
I believe that it also used an intresting mechanism in which resource requests were allocated using an auction like mechanism - if one of the boxes needed to spawn a process it would put out an RFP and machines willing to undertake the job would offer bids with costs. A second committment phase bound the offer to the bid.
The reason why there are only 12 or 13 root servers is based on several factors.
The most basic factor is that the DNS specification imposes an obsolete 512 byte limit on the size of UDP DNS packets. (DNS can run on TCP but the overhead is much higher than with UDP.
Since reply packets often contain many resource records, and DNS names can be up to 255 bytes each, you can see that one can brew up server names that would strongly press that 512 byte limit even with two servers. Fortunately, server names are usually not all that long.
DNS name compression comes into play to help, and that situation has improved since most root servers now support root-servers.net as the right hand part of their names.
Internationalization of domain names under the ACE rules coming out of the IETF will work the other way - internationalized server names will tend to be longer than than the a.root-servers.net form that we see today.
Now, just because we see one NS record in a list of servers doesn't mean that there is only one computer there - or even that it is in one place. Many servers are actually clusters that are hiding behind load balancers.
And with IP "anycast" technology (essentially a way of establishing multiple instances of the same address block by using localized more specific route announcements) we can have as many servers as we want at the same apparent address but located in widely scattered locations around the world. The.biz servers are, I believe, handled this way.
Oh, by-the-way, don't fall into the belief that the names/addresses listed in the "hints" file are the root - those addresses merely serve as a way to find a single root server. That server, in turn, will provide the actual set of root servers. That's why the hints file is called "hints" - it's just there to get the ball rolling.
I wrote a document about some simple steps that could be taken to improve DNS security before ICANN's meeting last November.
http://www.cavebear.com/rw/steps-to-protect-dns. ht m
Don't let the fact of 12 or 13 servers lul one into a sense of security - they are all fed data from the same source, and if that source is corrupted, then all the root servers will be corrupted. And that's not a hypothetical - the entire.com top level domain disappeared for a few hours in 2000. (Most people didn't notice this because of the damping provided by DNS caching, but it would have become really bad had the situation continued for a few more hours.)
Also, because all of the root servers run a nearly common code base, they are potentially vulnerable to a common weakness.
In addition, one need not bring down a server to take it off-line, an attacker need merely saturate the network in the vicinity of a target server so that no good traffic can get through. An even scarier notion is that of corruption of Internet routing so that packets flowing to DNS server addresses are forwarded out router interface null0.
DSL and cable TV Internet services are not worthy of the name "broadband". They are more aptly described as modem++.
Real broadband would be fast enough to bring in at least two stream of decent quality video (which I define as being at least 4:3 DVD quality and really ought to be 16:9 HDTV quality at full frame rates and resolutions - I'm talking rates on the order of 6 to 20+ megabits/second per stream.)
And a real "broadband" service, even if it has asymetrical bandwidth, ought to be at least capable of supporting things like servers for small businesses. The "mostly-in" paradigm of most of today's DSL and cable services just creates a caste system.
We really need fiber optics to every home and business. At a minimum cities ought to require that every time a trench is dug in a roadway or to a house, that an empty conduit be installed and connected. That way, over time, a conduit system would be created so that the conduit system would be there when we are ready to install the glass itself (after we've figured out the patching and packet routing mechanisms that need to go along with the actual fiber.)
I'm not sure that people are aware of the efforts of the Cable TV and telco industries to prevent the installation of municipial fiber optic utilities. There are efforts underway at the State level to enact laws to prevent cities from installing city-owned fiber optic cable plants because that would cut into the near-monopoly services of the phone and cable TV companies.
This kind of thing has been happening with increasing frequency recently, and in many instances the subsequent holder of the domain name is a porner trying to catch those who go to the name thinking that it's still what it used to be.
When the name previously was used for childrens materials my guess is that a case could be made that the second person is intentionally targeting children - and the existing legal system has plenty of cauldrons of boiling oil for those kinds of folks.
There are several useful resources:
There's Carl Opendahl's "Considerations for innocent domain name owners"http://www.patents.com/dno.htm
The At-Large-Study-Committee are very selective about what they use for input. The seem to hear only what they want to hear. Only today when someone questioned the basis of their assertion of "consensus" and said (paraphrase) "hey haven't you even tried asking on slashdot" one of the ALSC folks gave a lukewarm, non-committal reply and said (praphrased): "That would be nice, why don't you go and do it."
ICANN and its progeny such as the ALSC are well practiced in claiming "consensus" for things they want to do and "no consensus" for things that they don't want to do. They rely on the claim alone and never demonstrate any objective basis for that claim.
How do we rebut that? Given ICANN's selective hearing making direct inroads is very hard. Most ICANNites couldn't even spell/. much less know how to read it. My suggestion is to reach outside of/. and raise your concerns in other forums, particularly non-techie forums - things like your local newspapers, your local legislature, etc.
We need to have an ICANN - it actually has a useful and valuable role. But it needs to be narowed to certain highly specific jobs and to be controlled by the public.
But unless there is a very strong outcry against the ALSC report, the NAIS report has a peanut's chance in a zoo of being adopted by the majority of ICANN's board of directors.
By-the-way, if you are in LA for the ICANN meeting next week, make sure you preregister. Paranoia has struck deep and they aren't letting in anyone who hasn't preregistered.
Your elected ICANN representatives from Europe and from North America voted against this contractual change.
Maybe if ICANN were to open itself up to more elected representatives such decisions would go the "right" way.
However, ICANN has a "study" under way in which the basic existance of publicly elected members of the board is being questioned.
Unless folks work hard to demand the continued existance and expansion of ICANN's "at-large" we can foresee the day when the vote for such things isn't 12-for vs 3-against but will be unopposed because there will be no one present who represents the public interest.
I agree with you that this kind of decision making does render claims that ICANN is a "bottom-up consensus body" somewhat hard to believe.
But there is an issue that I want to raise - the credibility of some of the comments that are submitted.
I'd find it a lot easier to point to the mass of public comment on an issue if that comment were expressed in more felicitious form - better formed arguments, less profanity, more substance, less personal attack, etc.
Remember, when making comments to ICANN you are not doing so so much to convince me - I tend to take the public-interest position - but to convince the other folks within ICANN. And those other folks are, for the most part, rather more put-off by some of the less tactful forms of expression.
Sure, it's fun write an emotional outburst. But it tends to not carry much weight.
We've got a real uphill fight with ICANN. It will help a lot if the public comments to ICANN were more articulate.
The IETF is working on this and has been for a while. It's a lot more difficult than one might think.
From the technical point of view it's a choice between somehow encoding non-ASCII character sets into the limited character set of DNS "hostnames". (DNS itself is supposed to be 8-bit clean but there is an ancient limitation called "hostnames" that imposes an alphanumeric plus hyphen character set.)
The problem with this approach is that in some languages the size of the names becomes limited because the 63 octets per label get consumed pretty quickly when it takes two or three of 'em to encode a character. The speakers of those languages, understandably, feel that they are getting the leftover after the western nations get the good stuff.
The other approach is to actually modify the DNS protocols. There are some bit patterns in the length octet of the DNS label to indicate that a whole new label length/encoding mechanism is in place. The concern about this approach is what happens when these packets flow through existing resolvers and through so called "transparent" devices (firewalls, NATs, web caches, etc) that tend to futz with DNS packets.
NSI is seeing big $$ in all of this and has established an early registration system, oops I mean "testbed" so you can register your internationalized name even though there is no protocol support yet. This "testbed" is up and running now.
Competing root systems will no more damage the net than competing telephone number lookup mechanisms damage the telephone system.
When there are inconsistencies, users will chose with their feet whether to continue to use a name service that doesn't give 'em answers that meet with their expectations.
To my mind it is better to empower the users with a choice, even at the cost of some hypothetical inconsistencies, than to create a worldwide bureaucracy that forces all users to march to the drumbeat of the marketeer with the biggest budget.
Sure there are some potential problems - NS and CNAME records written in one TLD context and resolved in another, web caches that stupidly re-resolve DNS names in URLs rather than using the IP address of the TCP/HTTP connection they intercepted, etc. But I'd happily trade-in a worldwide bureaucracy in return for a couple of repairable technical glitches.
By-the-way, I been using the ORSC root system for my own systems for a couple of years.
I've also got cavebear.web in the IOD registry.
As an experiment I recently created.ewe in the ORSC root (and others) so that if I ever get a few cycles I may build an anonymous registration system - a person would submit a ((name),(list-of-dns-servers)) tuple and if (name) isn't yet taken the system would add the name and serverlist to the zone file and return a management key that can be used to perform updates. All information about the source of the registration will be tossed - if one wants to find out who is running it somebody will have to contact the owners of the machines at the IP addresses in the server list. As for garbage collection - If no queries for (name) are detected for some period of time - say 90 days - then the name and its list of servers (and the key) will be silently dropped.
You are simply repeating the FUD - Fear, Uncertainty, and Doubt - spread by those who want to block new TLDs.
There is absolutely no risk of "instability" by adding even hundreds of thousands of new TLDs. I've worked with someone who actually created a working root with somewhere on the order of 6,000,000 TLDs. (We essentially floated an old version of.com up one level.)
The "instability" that is feared is that the e-merchants won't be able to sell you the latest wizzo shoes 24x7x365. Seems to me that since it's the merchants who want this that they ought to ante up the $$ to pay for bomb-proof servers, mongo UPS systems, and other things that won't stop you from getting a 404 when somebody moves their content or an exchange congests or a routing black hole forms.
As for actual DNS failures - DNS is robust and won't keel over should some TLD operator futz up his/her zone file. In fact most folks didn't even notice when NSI lost.com for several hours the other month.
New TLDs are simply not a reason to go Chicken Little.
By-the-way, I am a happy user of.web in the IOD registry. I use the ORSC/Superroot DNS roots. I've got access to many TLDs beyond those in the ICANN/NTIA root. And there's not a trace of "instability".
The reason that.kids wasn't accepted was that there was a fear that by virtue of ICANN giving the stamp of approval to the charter ICANN could become indirectly responsible/liable should the operator of.kids not keep parents happy. (And if there's anything we know, its that parents have rather divergent opinions about what is appropriate for their children.;-)
What bothers me as an incoming ICANN director is that this same risk applies with regard to any TLD that has a limited purpose, like.coop. This is the reason why I want ICANN to simply hand out "slots" - tickets to put the name of your chosing into the root - and not inquire into the semantics of the string used or the policies that will be applied. I figure that the policies are a matter between the TLD operator and his/her customers.
I wasn't on the board of directors for this decision, so I didn't get a vote in things.
From information I've received from the folks who run at least some of the root servers, their root servers are not "very stressed out" or even "stressed out". I've looked at the numbers and they have plenty of headroom in terms of CPU, disk I/O, memory, and network bandwidth. The situation may be different for some of the other systems that serve up the root zone. (I've heard rumors that the numbers I've seen may not be complete. And I've heard it mentioned that Win 2K has a built-in query to "a.root-servers.net" when it can't find any local server against which to try a dynamic update. As a new ICANN director I'll be digging a bit deeper on these to find out the full story.)
What you might have seen are numbers for boxes that are serving a dual role - serving up both the root and the big heavy duty TLD zones like.com/.net/.org. That situation is being alleviated as separate servers are deployed to separately handle the root and the various TLD zones.
As for a lot of entries in a zone - yes, searching algorithms tend to take more time as more items are searched. But where we have an existance proof of a zone with nearly 20 million entries running adequately (.com) we can pretty much laugh at the concept of even a few tens of thousands of new entries in the root causing any sort of problem.
I'm not sure that a usenet style hierachy would solve the issue - it still leaves people thinking that DNS is a directory, which it is not.
However, you hit the nail right on the head with your comment that this DNS nonesense will be remedied by better search and directory technology that is layered on top of DNS rather than embedded inside DNS.
A fully distributed, rootless name service would be something from the current DNS protocols and DNS implementations.
However, if one considers today's DNS to be a set of TLDs (Top Level Domains) that are found by consulting a "root" then it is indeed possible to create root systems other than the one most, but not all. of us use. Personally, I use one of these other root systems - and I have been doing for several years and have had zero problems.
Take a look at
http://www.superroot.org/ and
http://www.opennic.unrated.net/public_servers.html
Slashdot Mirror
The IFWP you refer to was not the source of ICANN. Rather, it was Joe Sims of Jones Day who worked in secret, making unknown agreements with unknown parties for unknown quid-pro-quos who created the ICANN we know today.
The IFWP process was derailed by a self-appointed steering committee that included, among others, the person who (unknown to the public) soon be named the President of the new ICANN.
The IFWP materials may be seen via http://domainhandbook.com/ifwp.html
One of the dates coming up on the ICANN calendar this summer or very early autumn is the renewal of the Memorandum of Understanding between ICANN and the Nat'l Telecommunications and Information Administration (NTIA) [part of the US Dept of Commerce].
1 .htm This is due for renewal about now.
That MoU is the vehicle through which ICANN gains most of its authority over DNS. See http://www.icann.org/general/agreements.htm for a pointer to the MoU and its series of amendments.
Another vehicle is a contract with NIST for the "IANA Function":
http://www.icann.org/general/iana-contract-21mar0
Under the At-Large Study Committee (ALSC) proposal only domain name holders would be given a vote.
But that concept received virtually no public support (as if that mattered in the land of ICANNia.)
There was far more support for keeping the previously used criteria: Anyone of age 16 or more who had a postal address.
There have been even broader proposals - the key being some means to have a degree of confidence that any single person gets but one vote.
I was on ICANN's original internationalized domain name committee. We pretty much decided to do whatever the IETF says to do. That still feels like an appropriate answer and is consistent with the notion that ICANN ought to merely coordinate rather than dictate technology.
/" as a DNS label!
Although DNS is defined to be 8-bit clean, there are ancient relics in the standards about how some names have to be in a reduced alphanumeric plus hyphen character set.
What scares me is this: There are a lot of DNS engines out there that might be surprised to suddenly find characters outside of that character set. And some of these engines are in surprising places - firewalls, NATs, web caches, etc. I had an experience in which someone was tunneling audio via DNS UDP packets and for some reason a mongo sized Cisco in the middle was parsing those packets and crashing IOS.
And internationalized names can creep in even when it appears that standard ascii is being used - imagine an ascii name that maps to an internationalized CNAME.
I tend to agree with John Klensien that the best way to deal with things is to push for new things to be layered on top of DNS, thus making DNS largely invisible, and to try to get people to start being blind to the semantics of the DNS character strings. Sounds impossible until one realizes that the method adopted by the IETF - ACE encoding - will mean that we start seeing DNS names that look like bq--3kdhyekjayy.org floating around.
Just wait until gethostbyname() sees some of these things - imagine a domain name that contains things like dots, nulls, asterisks, etc inside each of the DNS "labels". I'm dreding the day when I see see "rm -rf
There is no disaster if everyone picks their own root system. In fact there is a very definite benefit - the data is distributed more widely, points of traffic concentration are reduced, and the vulnerability of the entire system to data polution via bad root zone files is reduced.
1 1_2001.ppt
The issue is not whether there are multiple systems of roots - the issue is whether they are consistent. Right now those who are operating root systems the compete with the ICANN/NTIA/NSI legacy root are offering supersets. How one views an enhanced service depends on whether one is in the "I chose not to move forward with the times" camp or the "I upgraded to a more complete service" camp.
DNS has largely failed on the real issue: invarience.
There are three questions:
- Does the meaning of a DNS name change depending on who utters the name (client invarience)?
- Does the meaning of a DNS name change depending on where the name is uttered (geographic invarience)?
- Once bound to a meaning, does the meaning of a DNS name change over time (temporal invarience)?
On all three of these counts DNS fails. Content management systems have broken the first kinds of invarience and, among other reasons, our simple inability to distinguish between containers and the information they contain has broken the latter.
Take a look at my submission to the NRC on these points: http://www.cavebear.com/rw/nrc_presentation_july_
I've run my own root server - it takes a small amount of work to keep the referral addresses up to date. One easy way is to write a simple script that uses dig to hoover-up delegation information from any of the legacy root servers.
.com for several hours a while back.)
I find it easier to use one of the competing root systems. I use the ORSC one. It has been quite reliable over the years - in fact it has been better than the ICANN/NTIA/NSI one (it didn't lose
There is already a rather lose group of root system operators who try to avoid doing silly and ultimately unproductive things like having two different versions of the same name but with different contents.
All that DNS needs is somebody to edit the root zone file (which implies chosing between competing demands for the same name - a situation that can be readily and inexpensively handled by a first-come-first-served rule) and to make sure that those who run the root servers are reasonable and responsible folks who follow the protocols defined by the IETF.
ICANN, however, has expanded its role into all kinds of unnecessary things - like creating a worldwide trademark law and its own system of kangaroo courts with a jurisprudence that would make Judge Roy Bean blush.
ICANN has also decided that it needs to engage in massive (and expensive) nano-management of DNS sellers - ICANN has even mandated the minimum that these sellers must spend on marketing! ICANN plans to spend every penny of that $2,400,000 that it received in application fees just to "deploy" seven new top level domains - ones like .museum, .coop, and .aero, or .name. That kind of negative innovation will turn the Internet into a reprise of the 1950's telephone company in pretty short order. With ICANN at the helm we can expect more imagination in coal mining than in Internet naming technology.
ICANN's "Governmental Advisory Committee" (GAC) is composed only of government representatives - so we can get a hint of what government in ICANN - and thus government in DNS - will look like. The GAC has proven that while it has utterly no comprehension of net technology, it is able to blither for days on end to find just the right euphemism to put into a communiqe. And when it comes to making choices, the assembled governments of ICANN's GAC have demonstrated repeatedly that they tend to sacrifice their citizens pocketbooks, property, and privacy to the predators of the net - among them NSI and the trademark industry.
What ICANN's president's plan does is to eliminate what few constraints had existed on the ability of ICANN's management to do what they pleased, which seems to be to build empires to the sky and to engage in massive travel (one ICANN staffer travels to about 50 international venues per year!) Under the president's plan, ICANN's yearly budget goes up tenfold to several tens of millions of dollars per year!
Public participation in ICANN - if it were ever to come about would provide a check to these excesses.
And such public oversight is sorely needed - ICANN's management cares not a damn for the internet community or net users. And ICANN's management has demonstrated that its goals, and its methods, are not all that far from those of Enron, except that ICANN has the benefit of being being exempt from taxes.
In the movie Coconuts Grocho Marx said about the swamp property he was auctioning: "Oh, you can get stucco, oh, you can really get stuck oh." ICANN's president's plan is the same kind of swamp - and we are all going to get very stuck unless we oppose it, prevent it, and come up with a plan for an truely limited ICANN.
ICANN's management created this monstrosity on its own initiatiative - it is esssentially an act of gross insubordination by ICANN's management and an act of disdain for the Board of Directors and for the internet community.
This "restructructuring" is a complete recreation of ICANN, but with even the hint of public participation stripped away.
I just go off the airplane home from this ambush. I'm really ticked off.
This kind of thing was being done in 1968 - check out the UC Irvine "Distributed Computing System". If I remember right it went well beyond things like file sharing among relatively autonomous machines, it even had the memory allocator running on different machines than those holding the memory being allocated.
I believe that it also used an intresting mechanism in which resource requests were allocated using an auction like mechanism - if one of the boxes needed to spawn a process it would put out an RFP and machines willing to undertake the job would offer bids with costs. A second committment phase bound the offer to the bid.
All this in the late 1960's.
The reason why there are only 12 or 13 root servers is based on several factors.
.biz servers are, I believe, handled this way.
The most basic factor is that the DNS specification imposes an obsolete 512 byte limit on the size of UDP DNS packets. (DNS can run on TCP but the overhead is much higher than with UDP.
Since reply packets often contain many resource records, and DNS names can be up to 255 bytes each, you can see that one can brew up server names that would strongly press that 512 byte limit even with two servers. Fortunately, server names are usually not all that long.
DNS name compression comes into play to help, and that situation has improved since most root servers now support root-servers.net as the right hand part of their names.
Internationalization of domain names under the ACE rules coming out of the IETF will work the other way - internationalized server names will tend to be longer than than the a.root-servers.net form that we see today.
Now, just because we see one NS record in a list of servers doesn't mean that there is only one computer there - or even that it is in one place. Many servers are actually clusters that are hiding behind load balancers.
And with IP "anycast" technology (essentially a way of establishing multiple instances of the same address block by using localized more specific route announcements) we can have as many servers as we want at the same apparent address but located in widely scattered locations around the world. The
Oh, by-the-way, don't fall into the belief that the names/addresses listed in the "hints" file are the root - those addresses merely serve as a way to find a single root server. That server, in turn, will provide the actual set of root servers. That's why the hints file is called "hints" - it's just there to get the ball rolling.
I wrote a document about some simple steps that could be taken to improve DNS security before ICANN's meeting last November.
. ht m
.com top level domain disappeared for a few hours in 2000. (Most people didn't notice this because of the damping provided by DNS caching, but it would have become really bad had the situation continued for a few more hours.)
http://www.cavebear.com/rw/steps-to-protect-dns
Don't let the fact of 12 or 13 servers lul one into a sense of security - they are all fed data from the same source, and if that source is corrupted, then all the root servers will be corrupted. And that's not a hypothetical - the entire
Also, because all of the root servers run a nearly common code base, they are potentially vulnerable to a common weakness.
In addition, one need not bring down a server to take it off-line, an attacker need merely saturate the network in the vicinity of a target server so that no good traffic can get through. An even scarier notion is that of corruption of Internet routing so that packets flowing to DNS server addresses are forwarded out router interface null0.
DSL and cable TV Internet services are not worthy of the name "broadband". They are more aptly described as modem++.
Real broadband would be fast enough to bring in at least two stream of decent quality video (which I define as being at least 4:3 DVD quality and really ought to be 16:9 HDTV quality at full frame rates and resolutions - I'm talking rates on the order of 6 to 20+ megabits/second per stream.)
And a real "broadband" service, even if it has asymetrical bandwidth, ought to be at least capable of supporting things like servers for small businesses. The "mostly-in" paradigm of most of today's DSL and cable services just creates a caste system.
We really need fiber optics to every home and business. At a minimum cities ought to require that every time a trench is dug in a roadway or to a house, that an empty conduit be installed and connected. That way, over time, a conduit system would be created so that the conduit system would be there when we are ready to install the glass itself (after we've figured out the patching and packet routing mechanisms that need to go along with the actual fiber.)
I'm not sure that people are aware of the efforts of the Cable TV and telco industries to prevent the installation of municipial fiber optic utilities. There are efforts underway at the State level to enact laws to prevent cities from installing city-owned fiber optic cable plants because that would cut into the near-monopoly services of the phone and cable TV companies.
This kind of thing has been happening with increasing frequency recently, and in many instances the subsequent holder of the domain name is a porner trying to catch those who go to the name thinking that it's still what it used to be.
When the name previously was used for childrens materials my guess is that a case could be made that the second person is intentionally targeting children - and the existing legal system has plenty of cauldrons of boiling oil for those kinds of folks.
There are several useful resources: There's Carl Opendahl's "Considerations for innocent domain name owners"http://www.patents.com/dno.htm
And then there's the collection of things by Ellen Rony at http://www.domainhandbook.com/media.html In particular see: Pornography Takes Over Financial Site for Children http://www.nytimes.com/2001/10/26/technology/26NET .html
The At-Large-Study-Committee are very selective about what they use for input. The seem to hear only what they want to hear. Only today when someone questioned the basis of their assertion of "consensus" and said (paraphrase) "hey haven't you even tried asking on slashdot" one of the ALSC folks gave a lukewarm, non-committal reply and said (praphrased): "That would be nice, why don't you go and do it."
/. much less know how to read it. My suggestion is to reach outside of /. and raise your concerns in other forums, particularly non-techie forums - things like your local newspapers, your local legislature, etc.
ICANN and its progeny such as the ALSC are well practiced in claiming "consensus" for things they want to do and "no consensus" for things that they don't want to do. They rely on the claim alone and never demonstrate any objective basis for that claim.
How do we rebut that? Given ICANN's selective hearing making direct inroads is very hard. Most ICANNites couldn't even spell
We need to have an ICANN - it actually has a useful and valuable role. But it needs to be narowed to certain highly specific jobs and to be controlled by the public.
There is a very reasonable alternative to that awful ALSC report:
http://www.naisproject.org/report/final
But unless there is a very strong outcry against the ALSC report, the NAIS report has a peanut's chance in a zoo of being adopted by the majority of ICANN's board of directors.
By-the-way, if you are in LA for the ICANN meeting next week, make sure you preregister. Paranoia has struck deep and they aren't letting in anyone who hasn't preregistered.
Your elected ICANN representatives from Europe and from North America voted against this contractual change.
Maybe if ICANN were to open itself up to more elected representatives such decisions would go the "right" way.
However, ICANN has a "study" under way in which the basic existance of publicly elected members of the board is being questioned.
Unless folks work hard to demand the continued existance and expansion of ICANN's "at-large" we can foresee the day when the vote for such things isn't 12-for vs 3-against but will be unopposed because there will be no one present who represents the public interest.
Even if you don't buy from the Verisign "registrar" the underlying "registry" services are performed by Versign.
So don't think that because you register through Gandi that you are avoiding Verisign - they get $6 of that $10 you paid.
I agree with you that this kind of decision making does render claims that ICANN is a "bottom-up consensus body" somewhat hard to believe.
But there is an issue that I want to raise - the credibility of some of the comments that are submitted.
I'd find it a lot easier to point to the mass of public comment on an issue if that comment were expressed in more felicitious form - better formed arguments, less profanity, more substance, less personal attack, etc.
Remember, when making comments to ICANN you are not doing so so much to convince me - I tend to take the public-interest position - but to convince the other folks within ICANN. And those other folks are, for the most part, rather more put-off by some of the less tactful forms of expression.
Sure, it's fun write an emotional outburst. But it tends to not carry much weight.
We've got a real uphill fight with ICANN. It will help a lot if the public comments to ICANN were more articulate.
The IETF is working on this and has been for a while. It's a lot more difficult than one might think.
From the technical point of view it's a choice between somehow encoding non-ASCII character sets into the limited character set of DNS "hostnames". (DNS itself is supposed to be 8-bit clean but there is an ancient limitation called "hostnames" that imposes an alphanumeric plus hyphen character set.) The problem with this approach is that in some languages the size of the names becomes limited because the 63 octets per label get consumed pretty quickly when it takes two or three of 'em to encode a character. The speakers of those languages, understandably, feel that they are getting the leftover after the western nations get the good stuff.
The other approach is to actually modify the DNS protocols. There are some bit patterns in the length octet of the DNS label to indicate that a whole new label length/encoding mechanism is in place. The concern about this approach is what happens when these packets flow through existing resolvers and through so called "transparent" devices (firewalls, NATs, web caches, etc) that tend to futz with DNS packets.
NSI is seeing big $$ in all of this and has established an early registration system, oops I mean "testbed" so you can register your internationalized name even though there is no protocol support yet. This "testbed" is up and running now.
I rather disagree.
Competing root systems will no more damage the net than competing telephone number lookup mechanisms damage the telephone system.
When there are inconsistencies, users will chose with their feet whether to continue to use a name service that doesn't give 'em answers that meet with their expectations.
To my mind it is better to empower the users with a choice, even at the cost of some hypothetical inconsistencies, than to create a worldwide bureaucracy that forces all users to march to the drumbeat of the marketeer with the biggest budget.
Take a look at http://www.cavebear.com/cavebear/growl/issue_2.htm #multiple_roots
Sure there are some potential problems - NS and CNAME records written in one TLD context and resolved in another, web caches that stupidly re-resolve DNS names in URLs rather than using the IP address of the TCP/HTTP connection they intercepted, etc. But I'd happily trade-in a worldwide bureaucracy in return for a couple of repairable technical glitches.
By-the-way, I been using the ORSC root system for my own systems for a couple of years.
I've also got cavebear.web in the IOD registry.
As an experiment I recently created .ewe in the ORSC root (and others) so that if I ever get a few cycles I may build an anonymous registration system - a person would submit a ((name),(list-of-dns-servers)) tuple and if (name) isn't yet taken the system would add the name and serverlist to the zone file and return a management key that can be used to perform updates. All information about the source of the registration will be tossed - if one wants to find out who is running it somebody will have to contact the owners of the machines at the IP addresses in the server list. As for garbage collection - If no queries for (name) are detected for some period of time - say 90 days - then the name and its list of servers (and the key) will be silently dropped.
You are simply repeating the FUD - Fear, Uncertainty, and Doubt - spread by those who want to block new TLDs.
There is absolutely no risk of "instability" by adding even hundreds of thousands of new TLDs. I've worked with someone who actually created a working root with somewhere on the order of 6,000,000 TLDs. (We essentially floated an old version of .com up one level.)
The "instability" that is feared is that the e-merchants won't be able to sell you the latest wizzo shoes 24x7x365. Seems to me that since it's the merchants who want this that they ought to ante up the $$ to pay for bomb-proof servers, mongo UPS systems, and other things that won't stop you from getting a 404 when somebody moves their content or an exchange congests or a routing black hole forms.
As for actual DNS failures - DNS is robust and won't keel over should some TLD operator futz up his/her zone file. In fact most folks didn't even notice when NSI lost .com for several hours the other month.
New TLDs are simply not a reason to go Chicken Little.
By-the-way, I am a happy user of .web in the IOD registry. I use the ORSC/Superroot DNS roots. I've got access to many TLDs beyond those in the ICANN/NTIA root. And there's not a trace of "instability".
The reason that .kids wasn't accepted was that there was a fear that by virtue of ICANN giving the stamp of approval to the charter ICANN could become indirectly responsible/liable should the operator of .kids not keep parents happy. (And if there's anything we know, its that parents have rather divergent opinions about what is appropriate for their children. ;-)
What bothers me as an incoming ICANN director is that this same risk applies with regard to any TLD that has a limited purpose, like .coop. This is the reason why I want ICANN to simply hand out "slots" - tickets to put the name of your chosing into the root - and not inquire into the semantics of the string used or the policies that will be applied. I figure that the policies are a matter between the TLD operator and his/her customers.
I wasn't on the board of directors for this decision, so I didn't get a vote in things.
From information I've received from the folks who run at least some of the root servers, their root servers are not "very stressed out" or even "stressed out". I've looked at the numbers and they have plenty of headroom in terms of CPU, disk I/O, memory, and network bandwidth. The situation may be different for some of the other systems that serve up the root zone. (I've heard rumors that the numbers I've seen may not be complete. And I've heard it mentioned that Win 2K has a built-in query to "a.root-servers.net" when it can't find any local server against which to try a dynamic update. As a new ICANN director I'll be digging a bit deeper on these to find out the full story.)
What you might have seen are numbers for boxes that are serving a dual role - serving up both the root and the big heavy duty TLD zones like .com/.net/.org. That situation is being alleviated as separate servers are deployed to separately handle the root and the various TLD zones.
As for a lot of entries in a zone - yes, searching algorithms tend to take more time as more items are searched. But where we have an existance proof of a zone with nearly 20 million entries running adequately (.com) we can pretty much laugh at the concept of even a few tens of thousands of new entries in the root causing any sort of problem.
I'm not sure that a usenet style hierachy would solve the issue - it still leaves people thinking that DNS is a directory, which it is not.
However, you hit the nail right on the head with your comment that this DNS nonesense will be remedied by better search and directory technology that is layered on top of DNS rather than embedded inside DNS.
A fully distributed, rootless name service would be something from the current DNS protocols and DNS implementations.
However, if one considers today's DNS to be a set of TLDs (Top Level Domains) that are found by consulting a "root" then it is indeed possible to create root systems other than the one most, but not all. of us use. Personally, I use one of these other root systems - and I have been doing for several years and have had zero problems. Take a look at http://www.superroot.org/ and http://www.opennic.unrated.net/public_servers.html
A while back I wrote a note on competitive root systems: http://www.cavebear.com/cavebear/growl/issue_2.htm #multiple_roots The IAB of the IETF takes a dim view of competive roots, but I don't accept the logic of their decison. (The IAB's note is in RFC2826.)