ICANN|ARCHIVES

Internet Corporation for Assigned Names and Numbers

Note to the ICANN Community

Given all the various discussions that are taking place on alternate roots, I decided to put together the attached discussion draft on the subject. The motivation for writing the draft was because I found a lack of completeness in the various discussion pieces floating across the net (except for the technical references noted in the draft). Among other issues not addressed was documentation of the policy basis for ICANN's commitment to a unique, authoritative root.

This draft is intended to prompt community discussion and I welcome constructive comments and feedback. The draft is based on a variety of sources cited in the document. The draft does not break new ground but attempts to restate existing policy and the technical basis for such policy.

It is clear from the draft that I have persuaded at least myself that there are solid technical grounds for a single authoritative root and that ICANN should continue its commitment through established policy to such a concept and to the community-based orderly processes that surround such policy. This constitutes a public trust. One corollary is that with current architectures and under current policy, ICANN cannot support the concept of multiple roots except within an experimental framework, where experimentation is carefully defined. Another corollary is that to change this policy would require a community consensus for the change in ICANN's character that would be entailed.

M. Stuart Lynn
President

Click here to enter the Public Comment Forum on a Unique, Authoritative Root for the DNS.

Discussion Draft: A Unique, Authoritative Root for the DNS

Abstract

This document reaffirms ICANN's commitment to a single, authoritative public root for the Internet Domain Name System (DNS) and to the management of that unique root in the public interest according to policies developed through community processes. This commitment is founded on the technical and other advice of the community and is embodied in existing ICANN policy.

The DNS is intended to provide a convenient means of referring to sites available on the Internet. By offering users an easy-to-use and reliable means of unambiguously referring to web sites, e-mail servers, and the Internet's many other services, the DNS has helped the Internet achieve its promise as a global communications medium for commerce, research, education, and cultural and other expressive activities.

The DNS is a globally distributed database of domain name (and other) information. One of its core design goals is that it reliably provides the same answers to the same queries from any source on the public Internet, thereby supporting predictable routing of Internet communications. Achievement of that design goal requires a globally unique public name space derived from a single, globally unique DNS root.

Although the Internet allows a high degree of decentralized activities, coordination of the assignment function by a single authority is necessary where unique parameter values are technically required. Because of the uniqueness requirement, the content and operation of the DNS root must be coordinated by a central entity.

Where central coordination is necessary, it should be performed by an organization dedicated to serving the public interest and that acts according to policies developed through processes that are developed through the participation of affected stakeholders. Traditionally, the responsibility for performing the central coordinating functions of the global Internet for the public good, including management of the unique public DNS root, has been carried out by the Internet Assigned Numbers Authority (the IANA). ICANN's core mission is to continue the work of the IANA in a more formalized and globally representative framework, to ensure the views of all the Internet's stakeholders are taken into account in carrying out this public trust.

Over the past several years, some private organizations have established DNS roots as alternatives to the authoritative root. Frequently, these "alternative" roots have been established to support for-profit top-level domain registries that have been unable to gain entry into the authoritative root as managed in the public interest by the IANA or ICANN. Other "alternative" roots have been established as expressions of the disagreements some individuals have had with the policies developed by the broader community processes for management of the authoritative root, or their disinterest in participating in that process.

Because these alternative roots substitute insular motives for the community-based processes that govern the management of the authoritative root, their decisions to include particular top-level domains have not been subjected to the same tests of community support and conformance with the public trust. Indeed, their introduction has been done with little regard for the public interest, since, if they were broadly used, they could impair the uniqueness of the authoritative DNS's name resolution. ICANN's stability-preservation mandate requires that it avoid acting in a manner that encourages their proliferation. This means that ICANN should continue to adhere to community-based processes in its decisions regarding the content of the authoritative root, and should give no preference to those who choose to work outside of these processes and outside of the policies engendered by this public trust.

None of this precludes experimentation, provided it is done in a manner that does not threaten the stability of name resolution in the authoritative DNS. Experimentation is essential to the vitality of the Internet. Nor does it preclude the ultimate introduction of new architectures that may ultimately obviate the need for a unique, authoritative root. But the translation of experiments into production and the introduction of new architectures require community-based approaches, and are not compatible with individual efforts to gain proprietary advantage.

1. The Technical Need for a Single Authoritative Root

The DNS was originally deployed in the mid-1980s as an improved means of mapping easy-to-remember names (e.g., "example.com") to the IP addresses (e.g., "128.9.176.32") by which packets are routed on the Internet. It is a distributed database that holds this mapping information (as well as various other types of technical information regarding computers on the Internet) in "resource records." The DNS provides these resource records in response to queries it receives from programs called "resolvers" on individual computers throughout the Internet. The resolvers translate domain names into the corresponding IP addresses.

From the inception of the DNS, its most fundamental design goal has been to provide the same answers to the same queries issued from any place on the Internet. As stated in RFC 1034, the basic specification of the DNS's "Concepts and Facilities" (P. Mockapetris Nov. 1987), "The primary [design] goal is a consistent name space which will be used for referring to resources." And as reiterated in RFC 2535, "Domain Name System Security Extensions" (D. Eastlake Mar. 1999), "It is part of the design philosophy of the DNS that the data in it is public and that the DNS gives the same answers to all inquirers."

The DNS is hierarchical. By design, the hierarchy begins with a group of "root nameservers," which are specially-designated computers operated under common coordination that provide information about which other computers are authoritative regarding the top-level domains in the DNS naming structure. Thus, a resolver seeking information concerning a domain name such as "example.com" obtains one of the root servers' resource records about .com, which tells the resolver which computers have authoritative information about names within the .com top-level domain. The resolver then queries one of those authoritative nameservers about example.com, to obtain the IP address of the computer designated by that name.

The principal advantage of this hierarchical structure is that it allows different parts of the naming database to be maintained by different entities. According to the DNS's design, each domain was intended to be administered by a single entity. See RFC 920, "Domain Requirements" (J. Postel and J. Reynolds Oct. 1984).

When the DNS was deployed in the mid-1980s, a set of root nameservers was designated and several top-level domains were established. These root nameservers (there are now 13 of them distributed around the world) are intended to provide authoritative information about which nameservers hold the naming information for each of the top-level domains. Since the root nameservers operate at the top of the hierarchy, resolvers find them by referring to IP addresses pre-stored at local computers throughout the Internet.

Over the past several years, some groups have established alternative root nameservers on the public Internet that distribute different information than the information distributed by the standard root nameservers. These groups then seek to persuade ISPs and Internet users to replace the pre-stored IP addresses of the standard root nameservers with those of their alternative servers. For a variety of reasons, these alternative roots have not to date enjoyed a significant level of usage on the public Internet.

Fortunately, the rare usage of alternative roots has limited their practical effect on the Internet. If these "alternative" roots were to become prevalent, however, they would have the potential for seriously disrupting the reliable functioning of the DNS:

1. Most apparently, the presence of alternative public DNS roots results in different answers being given to the same DNS queries issued from different computers on the Internet, depending on the pre-stored IP addresses in the inquiring computer. The fundamental DNS design goal of providing consistent answers to DNS queries is therefore frustrated.¹

2. In practical terms, a main consequence of inconsistent data is that the same domain name will identify different computers depending on where the name is used. Put another way, uniform resource locators (URLs) are no longer uniform. Thus, typing in a web site address at two different computers configured to reference different roots can result in reaching different web sites-a particularly disturbing possibility if, for example, money is to change hands or privacy or security concerns are violated. Similarly, the same piece of e-mail sent to the same address from the two computers can be directed to different recipients. The return of inconsistent DNS data defeats the globally consistent resolution of domain names that is vital to the Internet achieving its promise as a universal communications medium for commerce, research, education, cultural exchange, and expressive activities.

3. For a variety of reasons, the set of DNS answers that will be received (standard or alternative) is not predictable by the end user. Most users on the Internet employ a local nameserver that is configured by another person. Few users are likely to appreciate the significance of the nameserver's DNS configuration; even fewer are likely to have detailed knowledge of that configuration.

4. Moreover, some Internet services depend on the actions of DNS resolvers at intermediate hosts. Alternative roots introduce the possibility that the DNS answer obtained by the intermediate host alters the character of the service in an unexpected way. A similar phenomenon occurs where one user sends another a reference to a URL, such as an e-mail reply addresses or a web-site links. If the recipient of an e-mail or the visitor to the web site is using a computer that employs a different DNS root than intended by the sender of the e-mail or the designer of the web site, unexpected results are likely to occur. For example, the email could end up with the wrong person.

5. Alternative roots also introduce the possibility of misdirected Internet activities due to cache poisoning. For performance reasons, the DNS design calls for resource records to be passed around among the nameservers on the Internet, so that a resolver can obtain quicker access to a local copy of the resource record. Because the DNS assumes a single-root system, resource records are not marked to distinguish them according to the root from which they emanate. Thus, the presence of alternative roots introduces the possibility that Internet activities by those intending to use the standard root could be misdirected by a stray resource record emanating from an alternative root. Indeed, some malicious hacking attacks have been based on this principle, prompting the Internet Engineering Task Force to propose a series of not-yet-implemented improvements known as "DNS-Security".

(It should be noted that the original design of the DNS provided a way to operate alternative roots in a way that does not imperil stability. See Section 5 below for details.)

These potentially destructive effects of alternative roots have long been accepted by the vast majority of Internet engineers. Despite this broad-based recognition, some have sought to justify the alternative roots by downplaying these effects. In response, and to document what it referred to as "some of the problems inherent in a family of recurring technically naive proposals," in May 2000 the Internet Architecture Board (IAB) issued RFC 2826, entitled "IAB Technical Comment on the Unique DNS Root." The IAB summarized its comments (in relevant part) as follows:

Summary

To remain a global network, the Internet requires the existence of a globally unique public name space. The DNS name space is a hierarchical name space derived from a single, globally unique root. This is a technical constraint inherent in the design of the DNS. Therefore it is not technically feasible for there to be more than one root in the public DNS. That one root must be supported by a set of coordinated root servers administered by a unique naming authority.

Put simply, deploying multiple public DNS roots would raise a very strong possibility that users of different ISPs who click on the same link on a web page could end up at different destinations, against the will of the web page designers.

<http://www.rfc-editor.org/rfc/rfc2826.txt>

(For some concrete examples of potential failures and instabilities that would likely result from alternative roots prevalently used on the public Internet, see the Internet Draft "Alt-Roots, Alt-TLDs" (K. Crispin May 2001).

In the face of the destabilizing consequences of alternative roots, as articulated by the IAB and others, ICANN's prime directive of preserving the stability of the Internet and DNS requires an unwavering commitment to promote the continued prevalence of a single authoritative root for the public DNS. Any other course of action would be irresponsible.

2. The Public Trust in Coordinated Assignment Functions

The Internet's proper operation requires assignment of unique values to various identifiers for different computers or services on the Internet. To be effective, these assigned values must be made broadly available and their significance must be respected by the many people responsible for the Internet's operation. For example, every computer on the public Internet is assigned unique IP address; this address is made known to routers throughout the Internet to cause TCP/IP packets with that destination address to be routed to the intended computer. Without common agreement to respect the assignment, the Internet would not reliably route communications to their intended destinations.

Beginnings to 1998: Central Coordination as a Public Trust

From the very beginnings of the Internet, the technical community has recognized the need for central coordination of the unique assignment of the values of identifiers. The Internet Assigned Numbers Authority (the IANA, now operated by ICANN) was created to fill this need; it now makes assignments of unique values for approximately 120 different identifier types. This responsibility has always been understood to be a public trust, and the IANA long ago adopted the motto: "Dedicated to preserving the central coordinating functions of the global Internet for the public good."

The most commonly known of the Internet's uniquely assigned identifiers, of course, are domain names. From the time the DNS was deployed, the Internet community made the IANA "responsible for the overall coordination and management of the Domain Name System (DNS), and especially the delegation of portions of the name space called top-level domains." RFC 1591, "Domain Name System Structure and Delegation" (J. Postel Mar. 1994). As in its other assignment responsibilities, the IANA's role is to act in the public interest and neutrally, and without proprietary motives.

Competition as a Value Guiding the Internet's Technical Management

In the Internet's early years, day-to-day registration activities for domain names were done (with the limited exceptions) by a single company (first SRI and later Network Solutions) under the IANA's guidance.

By the mid-1990s, however, the growth and increasing commercialization of the Internet led the U.S. Government's Green² and White³ Papers to note the emergence of "widespread dissatisfaction about the absence of competition in domain name registration." This dissatisfaction prompted the Green and White Papers to include the promotion of competition in registration services as one of the four values (stability; competition; private, bottom-up coordination; and representation) that should guide the Internet's technical management. Both documents made clear that, of these four values, preservation of stability was to be paramount.

Building on the IANA model of a non-profit entity carrying the public trust to perform the vital central coordination functions, the U.S. Government reconciled the need to ensure Internet stability with the desire to introduce competitive domain-name registration services as follows:

In keeping with these principles, we divide the name and number functions into two groups, those that can be moved to a competitive system and those that should be coordinated. We then suggest the creation of a representative, not-for-profit corporation to manage the coordinated functions according to widely accepted objective criteria. We then suggest the steps necessary to move to competitive markets in those areas that can be market driven.⁴

This dichotomy recognizes that the Internet is, after all, a network (albeit a network of networks), and networks require coordination among their participants to operate in a stable and efficient manner. It also reflects the phenomenal success of the Internet's tradition of cooperatively developed open and non-proprietary standards. Those standards have provided an environment of highly interoperable systems that has allowed competition and innovation to flourish.

ICANN Assumes the Public Trust

After public comment on the Green Paper, the United States Government issued the White Paper, which provides the basic charter for ICANN. The White Paper re-emphasized the prime directive of stability and, to that end, the need to avoid creation of alternative roots:

The introduction of a new management system should not disrupt current operations or create competing root systems. During the transition and thereafter, the stability of the Internet should be the first priority of any DNS management system.⁵

It then invited the Internet community to form a not-for-profit corporation (ICANN was the response to this invitation) to perform the "coordinated functions" that should be handled as a matter of public trust, rather than according to a competitive regime that would not be conducive to stability. Among the "coordinated functions" were management of the root-server system and decisions to introduce new TLDs:

Similarly, coordination of the root server network is necessary if the whole system is to work smoothly. While day-to-day operational tasks, such as the actual operation and maintenance of the Internet root servers, can be dispersed, overall policy guidance and control of the TLDs and the Internet root server system should be vested in a single organization that is representative of Internet users around the globe.

Further, changes made in the administration or the number of gTLDs contained in the authoritative root system will have considerable impact on Internet users throughout the world. In order to promote continuity and reasonable predictability in functions related to the root zone, the development of policies for the addition, allocation, and management of gTLDs and the establishment of domain name registries and domain name registrars to host gTLDs should be coordinated.⁶

In response to this invitation, ICANN was established in 1998 by the Internet community as an open, consensus-based organization that, among other responsibilities, acts as the coordinator for operation of the authoritative root-server system and the policy forum for decisions about the policies governing what TLDs are to be included in the authoritative DNS root.⁷ The establishment of ICANN followed extensive dialogs among different constituencies of the Internet community to ensure that ICANN could be responsive to the needs of these different constituencies.

In linking ICANN's formation to the global Internet community, the White Paper established a public trust that requires ICANN to administer the DNS in the public interest as the unique-rooted,⁸ authoritative database for domain names that provides a stable addressing system for use by the global Internet community. This commitment to a unique and authoritative root is a key part of the broader public trust—to carry out the Internet's central coordination functions for the public good—that is ICANN's reason for existence.

3. The Public Trust and the Introduction of New TLDs

It is essential that the centrally coordinated functions be performed in the public interest, rather out of proprietary motives. For this reason, ICANN was founded as a not-for-profit public-benefit organization, accountable to the Internet community. Longstanding Internet principles also require that the policies guiding the coordinated functions be established openly based on community deliberation and input; for these reasons ICANN's structure is representative of the geographic and functional diversity of the Internet, and that relies to the extent possible on private-sector, bottom-up methods.

As the White Paper emphasized, the decisions about the introduction of new TLDs are appropriately done within this open, non-proprietary, and broadly representative framework, rather than by individuals or entities not accountable to the community and that ordinarily act for their own proprietary motives:

As Internet names increasingly have commercial value, the decision to add new top-level domains cannot be made on an ad hoc basis by entities or individuals that are not formally accountable to the Internet community.⁹

Within the framework of its commitment to a unique root system and to the stability of the Internet, last year ICANN launched a process for carefully introducing several new generic TLDs to the DNS. This introduction was fashioned as a proof of concept of the technical and business feasibility of introducing more TLDs into the DNS. Proceeding with an initial proof of concept was in response to the advice of ICANN's Protocol Supporting Organization (PSO) and its Domain Name Supporting Organization (DNSO) to proceed cautiously and in an orderly fashion. The PSO and the DNSO represent the consensus views of the technical and the user/business/other institutional communities, respectively. Generic TLDs had not been introduced for many years, and there were and still are serious questions as to what the effect of introducing new TLDs will be on the stable and reliable of the DNS; and many questions about what should be the appropriate contractual and business context.

In response to an RFP that was issued, forty-seven institutions submitted proposals for the establishment of new TLDs. They chose to work within the community-based ICANN process, even though they knew that only a "limited number" of TLDs would be selected—at least in the first round. In fact, seven were selected, and, following a methodology which allowed for considerable community input, contracts have or will shortly be signed with these initial seven. ICANN looks forward to the successful introduction of these new TLDs and will work with the community to monitor their performance so that a community decision can be made on moving forward with the introduction of more TLDs, should this be the conclusion of the proof of concept.

4. Outside the Process

There are those who are choosing or have chosen not to work within the ICANN process and within the ICANN policy framework. For their own insular motives, they have launched or are launching various "alternative" root systems or systems that emulate alternative roots, without regard to the destabilizing consequences. Some of them have characterized their efforts as an attempt to convince the user community that it is possible to launch new TLDs rapidly. The underlying thesis is that if it looks like a TLD, walks like a new TLD, and quacks like a new TLD—then it must be a new TLD. Unfortunately, this is not the case. As a result a number of third parties (fortunately not that many) are registering with these alternative systems under the misguided belief that this entitles them to preferential rights to these domain names as though they were part of the authoritative DNS.

The backers of these systems seem to work under the philosophy that if they get there first with something that looks like a TLD and invite many registrants to participate, then ICANN will be required by their very presence to recognize in perpetuity these pseudo TLDs, inhibiting new TLDs with the same top-level name from being launched through the community's processes. Nothing could be further from the truth. Regardless of hyperbole fueled by the self-interest of those who would advocate or, inadvertently or otherwise, nurture the fragmentation of the DNS, ICANN is committed to stability, a unique DNS, and orderly consensus-based processes for making policy decisions about the management of that DNS.

One prominent example, described in recent testimony before the US Congress, was the activation of a previously dormant TLD within an "alternative" root after other companies had already expressed interest in establishing a TLD of the same name through the ICANN process, and after several detailed proposals were submitted for community consideration. In an apparent effort to preempt the community-based process, a number of registrations were created in the alternative TLD by a small number of registrants (indeed, 60% of the first wave of registrations were made in the operator's own name), and various public statements were made, including in Congressional testimony, that were clearly intended to create the illusion of long-established and continuous operation. In fact, an analysis of registrations in this "alternative" TLD shows that, as of April 2001, there were only slightly over 3,600 names registered, a significant number of which are obviously names captured by speculators (such as cnn.biz and disney.biz). On the basis of this opportunistic record, this operator has claimed global priority over the community decisions through the ICANN process. This episode illustrates the wisdom of the White Paper's warning that "decision[s] to add new top-level domains [must not] be made on an ad hoc basis by entities or individuals that are not formally accountable to the Internet community."¹⁰

As previously stated, ICANN operates under a public trust that derives from the wishes of the community. It would be a supreme violation of that trust for ICANN to accede to any notion that those who bypass these community-based processes for their own purposes (profit-driven or otherwise) should gain any preferential treatment over those who work within these community processes.

As already noted, "alternative" roots inherently endanger DNS instability—that is, they create the real risk of name resolvers being unable to determine to which numeric address a given name should point. This violates the fundamental design of the DNS and impairs the Internet's utility as a ubiquitous global communications medium. Some of these systems also employ special technologies that—ingenious as they may be—may well conflict with future generations of Internet standards. Those who choose to work outside the system now can make no credible claim that their technologies can be adapted to these futures standards, or even that they will be around to adapt them even if that were possible.

5. Experimentation

Experimentation has always been an essential component of the Internet's vitality. Working within the system does not preclude experimentation, including experimentation with alternative DNS roots. But these activities must be done responsibly, in a manner that does not disrupt the ongoing activities of others and that is managed according to experimental protocols.

DNS experiments should be encouraged. Experiments, however, almost by definition have certain characteristics to avoid harm: (a) they are clearly labeled as experiments, (b) it is well understood that these experiments may end without establishing any prior claims on future directions, (c) they are appropriately coordinated within a community-based framework (such as the IETF), and (d) the experimenters commit to adapt to consensus-based standards when they emerge through the ICANN and other community-based processes. This is very different from launching commercial enterprises that lull users into a sense of permanence without any sense of the foregoing obligations.

Moreover, it is essential that operations involving "alternative" DNS roots be conducted in a controlled manner, so that they do not adversely affect those who have not consented to participate in them. Given the design of the DNS, and particularly the intermediate-host and cache poisoning issues described in Section 1 above, special care must be taken to insulate the DNS from the "alternative" root's effects. For example, "alternative" roots are commonly operated by large organizations within their private networks without harmful effects, since care is taken to prevent the flow of the alternative resource records onto the public Internet.

Moreover, it should be noted that the original design of the DNS provides a facility for future extensions that accommodates the possibility of safely deploying multiple roots on the public Internet for experimental and other purposes. As noted in RFC 1034, the DNS includes a "class" tag on each resource record, which allows resource records of different classes to be distinguished even though they are commingled on the public Internet. For resource records within the standard root-server system, this class tag is set to "IN"; other values have been standardized for particular uses, including 255 possible values designated for "private use" that are particularly suited to experimentation.¹¹

As described in a recent proposal within the IETF,¹² this "class" facility allows an alternative DNS namespace to be operated from different root servers in a manner that does not interfere with the stable operation of the existing authoritative root-server system. Those that have deployed alternative roots have not used a different class designation, however, choosing instead to have their resource records masquerade as emanating from the standard root, and creating the potential for disruption of other's operations.

In an ever-evolving Internet, ultimately there may be better architectures for getting the job done wherethe need for a single, authoritative root is not an issue. But that is not the case today. And the transition to such an architecture, should it emerge, would require community-based approaches. In the interim, responsible experimentation should be encouraged, but it should not be done in a manner that affects those who do not consent after being informed of the character of the experiment.

Conclusion

The success of the Internet and the guarantee of Internet stability rest on the cooperative activities of thousands, even millions, of people and institutions collaborating worldwide towards a common end. This extraordinary—even unprecedented—community effort has served to impel the incredible growth of the Internet. Their collective efforts provide a policy framework for technical and entrepreneurial innovation, and the advancement of economic, social, and educational goals.

Most members of the global community and most institutions with which they are associated recognize that it is in their best long-term interests to work within these community-based processes, even if that means foregoing illusory short-term advantages. The over-arching principles outlined in this document override exclusive and narrowly focused self-interest.

Community-based policy development is not perfect. It may proceed slower than some would wish. The introduction of new TLDs has proceeded at deliberate speeds. Impatience in the context of Internet timescales is perfectly understandable. The outcome of orderly processes based on the wishes of the community, however, is assurance that the Internet will continue to function in a stable and holistic manner that benefits the global community, and not become captured by the self-interests of the few. That, in the minds of most, is a price worth paying.

ICANN—in deference to its public trust—will continue to collaborate with these citizens of the Internet community to advance the notions of a unique root system as a rerequisite to Internet stability, and to ensure that community-based policies take precedence.

---

Notes:

1. Ironically, to avoid name conflicts in a multi-root system, a single-root system would need to be created-adding a higher level to the hierarchy.

2. Improvement of Technical Management of Internet Names and Addresses (Green Paper), 63 Fed. Reg. 8825, 8827 (20 Feb. 1998).

3. Management of Internet Names and Addresses (White Paper), 63 Fed. Reg. 31741, 31742 (10 Jun. 1998).

4. Green Paper, 63 Fed. Reg. at 8827.

5. White Paper, 63 Fed. Reg. at 31749. The Green and White Papers both made additional references to the need for a single authoritative root system. For example, in response to comments received from the Green Paper, the White Paper notes:

In the absence of an authoritative root system, the potential for name collisions among competing sources for the same domain name could undermine the smooth functioning and stability of the Internet.

6. White Paper, 63 Fed. Reg. at 31749 (emphasis added).

7. ICANN's corporate charter emphasizes its role in overseeing operation of the unique DNS root:

. . . the Corporation shall . . . pursue the charitable and public purposes . . . of promoting the global public interest in the operational stability of the Internet by . . . (iv) overseeing operation of the authoritative Internet DNS root server system . . . .

ICANN Articles of Incorporation, para. 3. The phrase "the authoritative Internet DNS root server system" is decidedly in the singular.

8. The Memorandum of Understanding between the United States Government and ICANN that governs the transfer of responsibilities from the U.S. Department of Commerce to ICANN also makes reference to the authoritative root in the singular, not in the plural:

In the DNS Project, the parties will jointly design, develop, and test the mechanisms, methods, and procedures to carry out the following DNS management functions: . . .

b. Oversight of the operation of the authoritative root server system;

c. Oversight of the policy for determining the circumstances under which new top level domains would be added to the root system . . . .

9. White Paper, 63 Fed. Reg. at 31742.

10. Id.

11. RFC 2929, "Domain Name System (DNS) IANA Considerations," section 3.2 (D. Eastlake, E. Brunner-Williams, and B. Manning Sep. 2000).

12. Internet Draft, "Internationalizing the DNS-A New Class" (J. Klensin Dec. 2000).