Return to newtlds Forum - Message Thread - FAQ

Username: mueller
Date/Time: Sat, July 1, 2000 at 5:04 AM GMT
Browser: Microsoft Internet Explorer V5.01 using Windows 95
Score: 5
Subject: Comments of Dr. Mueller, Part 1

Message:
 

 
        Comments of Dr. Milton Mueller, Associate Professor
Syracuse University School of Information Studies
 
Prefatory comments:

ICANN is to be commended for preparing a thorough set of questions regarding policy for new TLDs. Certain aspects of the questions and the accompanying statement are troubling, however.

First, ICANN needs to define more precisely what it means by "stability." As best as I can discern, the word is used to denote "any problem that might occur anywhere in the Internet." This overly broad definition has the ill effect of encouraging ICANN to insert itself into too many areas where it does not belong. "Stability" is normally used to denote technical and operational stability of the DNS. If ICANN is using the term to mean something else, it should offer a precise definition and ground it in the White Paper.

Second, the ICANN call (section A) states, "Introducing new TLDs implies a change in the overall structure of the DNS." That comment reveals a surprising lack of knowledge of the DNS protocol and its structure. The DNS is a hierarchical name space. While the business implications of adding TLDs are (in some cases) significant, the technical implications are not much different than registering a second-level domain name; indeed, there are many second-level domains that generate more traffic than top-level domains. Adding new top-level domains consists of adding a few lines of text into the root zone file that define the new TLD string and provide addresses for at least two name servers capable of resolving names under that TLD. Adding TLDs is not a change in the overall structure of DNS. It is an ordinary implementation of DNS.

Third, the report also states that we have "no experience" with the addition of new TLDs to the root. This is plainly false. Over 30 new TLDs – country codes -- were added each year to the root during the mid-1990s. Technically and operationally, there is no difference between ccTLDs and gTLDs. In the root zone file, all TLDs are simply strings of text associated with the IP addresses of name servers. The computers responding to queries of the root zone are completely unaware of whether the TLD queried stands for a country or something else. It just looks up the name and returns the record. There are no new operational or technical issues posed by adding TLDs to the root. There are, of course, important resource allocation decisions to be made regarding who gets them. One does not clarify this issue by falsely characterizing it as a step into uncharted technical territory or by raising unwarranted fears about the stability of the Internet.

On to the specfic questions:

Q1: In the introduction of new TLDs, what steps should be taken to coordinate with the Internet Engineering Task Force, the Internet Architecture Board, and other organizations dealing with Internet protocols and standards?

There are no protocol or standardization issues raised by the addition of new top level domains per se. As noted above, it is a simple implementation of DNS.

Q2: What stability concerns are associated with the initial phases of registration within the TLD?

None. To put this in perspective, the com zone is currently increasing by over 35,000 entries every day of every week. The idea that any one of the ten new TLD registries would instantly attract that large a stream of new registrations is not very likely. It is far more likely that new registries will have to work very hard for their business. But if it did happen, a registry with the proper facilities would be able to handle it. Indeed, it seems more stable to distribute the growing load of DNS entries over multiple new registries than to concentrate it on a single point of failure.

At any rate, a particular registry’s quality of service is not an issue for the root manager. The stability of the Internet itself is not threatened by a local failure, anymore than Internet stability is affected when a local ISP’s dial up lines are all busy or a web site receives too many hits to handle. Registries that are unable to handle the initial phases of registration will lose business. If ICANN is wise and introduces enough new registries to ensure competition, consumers will have plenty of other choices and the problem will be confined to the registry.

Q4: Would these stability concerns be magnified by introducing a large number of TLDs at once?

No. The DNS is a robust protocol that has proven its scalability over the long term. The consensus point reached by Working Group C was that a maximum of 10 new TLDs should be added. Unless the number exceeds what is as yet an unknown threshold, but is certainly well over a thousand entries in the top-level zone, there are no stability issues whatsoever raised by adding new TLDs.

We know that NSI put the root zone on the same server as the zone files for dot com for many years. During that period, the com zone file was quite large, containing over a million entries. The developers of DNS such as Paul Mockapetris and other technical experts such as Paul Vixie have made it clear publicly that there are no stability issues raised by adding 10 new TLDs to the root.

Q5: Are there any practical means of reversing the introduction of a significant new TLD once it goes into operation?

Of course. You can take it out of the root.

If by "practical" you mean "costless and painless," then the answer is probably no. The real issue is who bears the costs of the "reversal" and how the liability gets worked out.

Q6: Is it feasible to introduce a TLD on a "trial basis," giving clear notice that the TLD might be discontinued after the trial is completed?

Given the switching costs associated with the use of domain names, this is not a commercially viable way to introduce a TLD, so any activity within that domain would not be a "trial" of anything except some people’s willingness to gamble.


     

 


Message Thread:


Privacy Policy | Terms of Service | Cookies Policy