Controlling the Internet:
Legal and Technical Aspects of the
Domain Name System

Gordon Irlam
(noreply@base.com)

Draft of July 13, 1997

Confidential Edition

http://www.base.com/gordoni/thoughts/dns-control.html

Work: (408) 542-9660, Home: (415) 903-0811
2310 Rock St #10, Mountain View, CA 94043

Confidential: Confidential information is contained in italics. Information contained in this document should not be made available to Network Solutions, or parties affiliated with Network Solutions. Limited distribution and access to this document by the government and other trusted key parties is permitted. All confidential information is removed from public editions of this document. Copyright 1997 Gordon Irlam.

Overview

This document first reviews the Internet Domain Name System (DNS). It then explains how control of DNS effectively provides control over the entire Internet. It examines the current balance of power in the control of DNS, and explores ways the situation may evolve in the future. Finally, it recommends actions necessary to ensure continued public control of the Internet.

The important findings discussed in this document are:

Public policy recommendations that follow from these findings are:

An expanded version of these findings, and the resulting public policy recommendations, appear at the end of this document, prior to the Appendices.

Parties with a limited amount of time in which to review this document should just read the Summary of Important Findings and the Public Policy Recommendations.

Disclaimer: The balance of power in the control of DNS may change rapidly. The analysis and recommendations contained in the current version of this document may not be valid in six months' time. It is intended that this document will be periodically updated. The latest version of this document is obtainable from the above listed URL.

Table of Contents

1. The Domain Name System

1.1 TCP/IP

At the lowest level, the computers forming the Internet communicate through the exchange of packets of information. These packets pass from one system to the next until they reach their final destination. Analogous to the postal system, each packet has an address printed on it that identifies the final destination. These addresses are 32-bit numbers, and are known as IP (Internet Protocol) addresses. IP addresses are typically written in "dotted notation", as a sequence of four 8-bit numbers (eg. 199.79.128.4).

A protocol known as TCP (Transmission Control Protocol) typically runs on top of the IP protocol, and provides for reliable service. Host addresses in TCP are identical to host addresses in IP. The TCP and IP protocols are often not differentiated, and simply referred to together as TCP/IP. Most Internet services are layered on top of TCP. The services layered on top of TCP include SMTP (Simple Mail Transport Protocol), used to deliver email, and HTTP (Hypertext Transfer Protocol), used to transfer documents on the Web.

1.2 DNS

Users on the Internet are not required to know the IP addresses of the hosts to whom they are talking. Instead, they refer to computers through textual names, such as "www.base.com". The Domain Name System (DNS) is the component of the Internet's infrastructure responsible for translating textual host names into IP addresses. Packets are then sent to these addresses.

Translation from textual host names to IP addresses occurs dynamically, and the IP address returned by DNS for a given host name may change over time. This provides the flexibility necessary for the same service to be provided by a different machine, for old machines to be replaced by new machines, and to change network providers if required. In most cases however, the IP address associated with a given host name is unlikely to change more frequently than once a year.

The domain name system is administered by Network Solutions Incorporated under a time limited contract with the National Science Foundation (NSF). This contract requires Network Solutions manage an Internet accessible database. This database contains the information necessary for DNS to obtain the IP address of any host on the Internet. When establishing hosts in a new domain, the party registering the new domain contacts Network Solutions, and requests that the information they provide about the new domain be added to the database.

The contents of the DNS database are made available by Network Solutions to 13 specialized systems known as root name servers. Whenever a computer on the Internet needs to translate a host name to an IP address, it contacts one of these root name servers. The root name servers do not always know the requested IP address. However, the root name servers do always know the name server that needs to be contacted to determine the required IP address. Most of the root name servers are owned and operated by independent third parties. These independent third parties consist of three government agencies, two educational institutions, one professional society, one private company, and one overseas organization.

1.3 Email and the Web

The two most important and popular applications on the Internet today are email and the World Wide Web. Both email and the Web are built on top of the infrastructure provided by DNS.

When sending an email message to a recipient (eg. noreply@base.com), the last component of the email address (eg. base.com), is the DNS host name of the computer that handles email intended for the recipient. DNS is automatically used when sending email to determine the IP address of the computer to which to send the message.

When retrieving a document via the Web (eg. http://www.base.com/gordoni/gordoni.html), the first component of a Web URL (eg. www.base.com), is the DNS host name of the computer on which the document is stored. DNS is automatically used when accessing documents on the Web to determine the IP address of the computer from which to request the document.

2. The Economics of DNS

2.1 Network Effects

The tremendous economic value of the Internet is a result of the global interconnection of documents, email addresses, computers, and ultimately people. The value of the Web is derived not from the individual documents available, but from the fact that these documents are cross linked and indexed via a uniform framework. This cross linking and indexing makes it possible to find documents, and to rapidly jump from one document to another. Most of the economic value of email is likewise derived from the possibility of sending messages to anyone else with access to email. If there were several different networks, in which different documents were available on each network, and it was only possible to exchange email with people on the same network, then the total economic value of these networks would be far less than that of the Internet. The interconnection of people via email is the result of the use of a global email address space. The interconnection of documents on the Web is the result of the use of a global document URL space. Both the global email address space, and the global document URL space, are constructed using DNS. Without the interconnection provided by DNS, much of the economic value of the Internet would be lost.

From an economic perspective, DNS displays what are termed "network effects" (Katz and Shapiro, Systems Competition and Network Effects, Journal of Economic Perspectives, 8:2, p. 93, 1994). The value of using DNS increases in proportion to the number of people using it. Great economic value is derived from the fact that a single authoritative DNS database exists, and that all host names are interpreted within this single context. This makes email addresses and web sites universally accessible by everyone on the Internet. If multiple non-cooperating DNS authorities ever come to exist, the net will be split into multiple incompatible domains, between which the effective exchange of information could be difficult or even impossible. The utility of the Internet would drop sharply. Thus, there are strong economic reasons to favor the existence of a single authoritative DNS database.

Today, the existence of a single authoritative DNS database is largely viewed as synonymous with the existence of a single DNS authority in control of that database. The two are actually different concepts. The existence of a single authoritative DNS database means all the computers on the Internet agree as to the meaning of a particular host name. The existence of a single DNS authority means a particular organization or individual has control over changes to, and possibly also the availability of, the DNS database.

2.2 Monopoly Power

In a competitive market, the market based price for a service reflects the cost of provision of that service. Whenever the value of the service to a particular consumer exceeds the cost of provision of the service, the value of the service also exceeds its price. This is economically efficient. Competition ties cost and price together. This ensures, the economically inefficient situation, in which the value of the service exceeds its cost of provision, but does not exceed its price, never arises. The difference between the value of a service and the cost of its provision represents wealth that has been created. In a competitive market the consumer reaps the benefits of this wealth.

In a monopoly, prices are set by the monopoly to reflect the perceived value to consumers of the services provided. Frequently the value to a particular consumer exceeds the cost of provision of the service, but the value of the service does not exceed its price. Consequently transactions from which both parties would have benefited, fail to occur. As a result, monopolies are economically inefficient. Consumers may be able to reap the benefits of some of the wealth created, depending on the ability of the monopoly to accurately assess the value of the service to individual consumers, the spread in value of the service between different consumers, and the ability of the monopoly to price discriminate. However, most of the wealth created, will typically be reaped by the monopoly.

If there is only a single DNS authority, that authority has monopoly power. The monopoly would be able to charge both for registering a domain name, and for looking names up in the DNS database. The cost of providing the DNS service is negligible, but the economic value of DNS is enormous. As a result monopoly control of DNS would be extremely inefficient. The economic value of DNS is the result of network effects. Economists describe economic value resulting from network effects, as representing a "network externality". The value of this network externality would be unfairly reaped by the monopoly. The term "unfairly" is used because the economic value of DNS is the result of wealth the monopoly did not create. Ideally, the value of this network externality, should be reaped by the contributors to the network. The contributors to the network are the parties actually responsible for the creation of this wealth.

The fees a DNS monopoly could impose are extremely large. It probably would not be able to charge end users directly, but it could certainly pass these charges on to end users by levying network service providers. How much might such a monopoly be able to charge? Currently, there are approximately 50 million Internet users in the US. As a rough estimate, a monopoly might be able to extract somewhere in the range $10-20 per month from each Internet user. The precise amount would probably be higher for business users, but lower for consumers. Total fees imposed by the monopoly would thus amount to $5-10 billion per year. The cost of providing DNS registration services is very low, and so nearly the entire amount of any such fees would translate into profits. As a point of comparison, in 1996, Microsoft recognized $3.1 billion in income on $8.7 billion in revenue.

Consider a large ISP (Internet Service Provider), such as Netcom. Netcom has approximately 600,000 subscribers. If monopoly control of DNS was technically and legally secure, Netcom might be required to pay around $100 million dollars per year for the right to access the DNS database. This is a major expense, comparable in magnitude to Netcom's present total annual revenue. Netcom would have no alternative but to pay this fee. If they refused, Netcom's subscribers would be unable to exchange email with, or access the web sites of, other Internet users. If they did not pay these fees, the value of Netcom's service would be essentially worthless. Netcom would be forced to pass such charges on to their users. Today, faced with such an increase in fees, most users would simply switch providers. However, if all providers were subject to similar charges, end users would have little option but to pay the resulting increased fees.

Today, no one party has full control over DNS, and an absolute monopoly would not be possible. Faced with the suggested charges, most ISPs would probably revolt, and attempt to establish an alternative name space. This would however lead to the partial fragmentation of the Internet. Many sites would cease to be accessible from other sites, resulting in a significant loss of economic value. Today, it might be possible to charge no more than perhaps $1-2 billion per year, before triggering a backlash.

Whether monopoly control of the provision of DNS service runs afoul of US anti-trust legislation is an interesting question. A recent case filed by PGP Media on March 20, 1997, is the first case likely to start exploring some of these issues: PGP Media, Inc. v. Network Solutions, Inc. (http://namespace.pgpmedia.com/ns./litigation_cont.html, copy as of March 24, 1997).

Network Solutions is the current provider of DNS registration services under the terms of a contract with the NSF. Network Solutions' ability to charge for domain name registration is presently limited as a result of this contract. Despite this limitation, PGP Media still alleges Network Solutions' actions are in violation of Federal anti-trust laws.

2.3 Public Policy

There are two apparently conflicting goals. Strong network effects argue in favor of a single name space, but the problems inherent in a monopoly argue for multiple competitive naming authorities. To be efficient, some form of government intervention is required. The role of the government in such circumstances should be to define an appropriate framework within which competition can occur. Such a framework needs to be structured to both ensure the existence of a single name space, and ensure that naming services will be provided competitively.

It could be argued, that the creation of an appropriate framework for DNS service provision is the role the government has played up until this point, and which role it is vital that the government continue to play. To date, the government, through the NSF, has ensured the existence of a single name space by selecting a single party to provide naming services. At the same time, the government has partially achieved the competitive provision of naming services, through a contractual bidding process for the right to temporarily operate the naming authority. In the future the mechanisms by which the government achieves these goals may change, but the goals themselves, a single name space, and competitive service provision, should not change.

It is worth noting that the Federal Communications Commission's (FCC) role in regulating long distance phone service is broadly similar to the role the government is required to play with respect to DNS. Local phone companies are required to provide long distance companies access to their local network. This includes incorporating all phone numbers into a single nationwide phone number space (single name space). In addition, long distance phone service is provided competitively through the requirement that consumers be able to switch long distance providers (competitive service provision).

3. Administration of DNS

The administrative control of the DNS name space today reflects the history origins of the Internet. The Internet evolved from three federally created networks: MILNet, which carried military traffic, ARPANET, which carried defense related research traffic, and NSFNET, which carried non-defense research traffic.

3.1 The FNC

The Federal Network Council (http://www.fnc.gov/) (FNC) claims ultimate policy level ownership of the DNS name space (FNC's Role in the DNS Issue, http://ksgwww.harvard.edu/iip/fnc.html). The Federal Network Council is made up of representatives of 16 Federal agencies, including the NSF, NIST, NTIA, DARPA, NASA, NSA, and DOE. The FNC is responsible for coordinating and ensuring federal funding of the various Internet related bodies. These bodies include the IETF (Internet Engineering Task Force) Secretariat, CERT (Computer Emergency Response Team), and most importantly here, the IANA (Internet Assigned Numbers Authority). The FNC acquired policy level ownership of the DNS name space in 1993. Prior to this, policy level ownership of the DNS name space resided with the DOD (Department of Defense).

To date the FNC has essentially exercised a hands-off policy regarding administration of the DNS name space, with all administrative actions delegated to the IANA.

3.2 The IANA

The Internet Assigned Numbers Authority (http://www.iana.org/iana/) (IANA) exercises authority over the assignment of domain names. The IANA is operated by the Information Sciences Institute (ISI) of the University of Southern California (USC). From a legal point of view, the IANA is an activity performed by USC. The IANA is not a legal entity in its own right. Jon Postel is in charge of the IANA. The IANA is chartered to perform its work by the FNC, as well as by the Internet Society (ISOC). Jon Postel is widely seen as playing a responsible, neutral, role of public stewardship. IANA's perceived position of authority by the Internet community is largely the result of its history of managing the assignment of Internet identifiers. IANA delegates much of the authority to perform administrative DNS actions to third parties (RFC 1591: Domain Name System Structure and Delegation, http://www.internic.net/rfc/rfc1591.txt).

Most of the funding for the IANA is provided by DARPA (http://www.darpa.mil/) (Defense Advanced Research Projects Agency). DARPA is an agency of the DOD. The most recent funding for the IANA appears was provided by the Gigabit Network Communications Research (http://ito.darpa.mil/Summaries96/8420--USC_ISI_GigNet.html) project, funded by the DARPA Information Technology Office (http://ito.darpa.gov/). This contract expired March 31st, 1997. A new contract is presently being negotiated. These contracts include other tasks besides the operation of the IANA. The amount of funding required is presently around $500,000 per year. In accordance with Cooperative Agreement Amendment 4 (http://rs.internic.net/nsf/agreement/amendment4_dg.html, copy as of March 15, 1997) between the NSF and Network Solutions, partial funding of the IANA is also to be provided by Network Solutions. In 1996, this funding amounted to around $60,000. Network Solutions also provides funding to USC to have ISI manage the US domain. According to Jon Postel, Network Solutions is required to manage the US domain as part of the Cooperative Agreement. Recently, the provision of IANA funding by Network Solutions to USC was reconstituted as an amendment to the US domain contract. The IANA funds continue to be separately identified.

3.3 The InterNIC

Network Information Services management for the Internet was originally contracted out by the military DDN (Defense Data Network) DISA (Defense Information Systems Agency). SRI International was the first contractor. They were followed by GSI (Government Systems, Inc.). In 1992, GSI created a new company, Network Solutions, Inc., that took over from GSI in operating the DISA NIC. Later on in 1992, the NSF issued a request for proposals for one or more parties to operate network information services for the NSFNET for a five year period. Following the establishment of the NSF NREN (National Research and Educational Network), the NSF needed to find a party to perform Network Information Services management for the NREN. This would allow much of the work previously performed by the DISA contractor to be performed by an NSF contractor, as was more appropriate. At the time of the NSF request for proposals, Network Solutions was the incumbent contractor for the provision of Internet registration services, and submitted a proposal in response to the NSF request.

On the basis of the proposals received the NSF made awards to three separate parties to perform different aspects of network information services management. The three parties awarded agreements were required by the NSF to cooperate to provide a single network information center, known as the InterNIC (http://www.internic.net/) (Internet Network Information Center). The contract with General Atomics to provide InterNIC Information Services was subsequently terminated by the NSF. InterNIC services are now entirely provided by the two remaining contractors, Network Solutions, and AT&T. InterNIC Registration Services (http://rs.internic.net/rs-internic.html) are provided by Network Solutions. InterNIC Directory and Database Services (http://ds.internic.net/ds/dspg01.html) are provided by AT&T.

Network Solutions was awarded the role of Registration Services manager for the NSFNET. Under the terms of the contract (Article 3 part C), and for the duration of the contract, Network Solutions is required to operate the Internet Registry. The IANA has delegated to the Internet Registry responsibility for performing most administrative DNS actions.

IANA delegates the bulk of the work involving the administration of Internet domain names to a central Internet Registry. Among other tasks, the Internet Registry is responsible for administering names within the COM, NET, ORG, EDU, GOV, and ARPA domains. The registry cooperates with IANA in the assignment of top level country domains, such as DE, UK, FR, NL, and AU, but plays no part in assigning names within those domains. The registry is not responsible for the MIL, INT, or US domains.

The transition of registration services from various NICs is documented in the following IETF (Internet Engineering Task Force) RFCs (Request For Comments):

Over time, the NSF has ceased to provide Internet backbone service. The NSF has also allowed private networks to connect with, and become part of, the Internet. However, the agreement with Network Solutions to provide Registration Services for the entire Internet has remained in place. This agreement, as far as the provision of operational Registration Services is concerned, ends on March 31, 1998. On April 1, 1998 a six month "flexibility period" commences that terminates on September 30, 1998. This flexibility period is intended as a time during which any problems associated with the transfer of registration services to a future contractor can be solved.

3.4 Network Solutions

Network Solutions, Inc. (http://www.netsol.com/) is the current registrar for the COM, NET, and ORG domains. The CEO of Network Solutions is Gabe Battista, former president of Cable and Wireless, Inc. At Cable and Wireless, Battista was responsible for managing an annual revenue of $736 million. Network Solutions registration services related revenue is currently around $70 million dollars annually, and is thus small by comparison.

In March of 1995 Network Solutions was acquired by SAIC (http://www.saic.com) (Science Applications International Corp.). SAIC specializes in the provision of contracting services to the government. SAIC is privately held by its employees. SAIC appears to cultivate close ties to the government. The current President of SAIC, William Owens, is a former vice-chairman of the Joint Chiefs of Staff. He joined SAIC after retiring from the navy 12 months ago. SAIC currently has close to 23,000 employees.

Information on Network Solutions' operation of the InterNIC Registration Services is contained in the following documents:

Network Solutions employs approximately 300 people. As of December 31, 1996, 158 employees were responsible for operating the InterNIC registration services (Annual Report 3, section 2.1, Status of Objectives 3 and 30). The rest work on various other projects, including Intranet consulting.

Beginning September 14, 1995, and with the approval of the NSF, Network Solutions instituted the collection of a $50 annual fee for each registered domain name. An initial two year payment is required when a domain is first registered. Network Solutions is continuing to collect two years advance payment today, although the contract with the NSF is due to terminate in less than a year. This could potentially represent a significant financial liability.

Network Solutions does not make its financial results public. Public information contained in Annual Report 4 allows reasonably good estimates of the monthly financials for the InterNIC Registration Services:

Estimated InterNIC Registration Services Monthly Financials (Month of December 1996)

Financial Category

Formula

Amount / $

Registrations - New

72,000 x $100

7 200 000

Registrations - Renewals

4,000 x $50

200 000

Non-collectible Fees

20%

1 480 000

NSF Internet Infrastructure Fund

30% x (1 - 20%)

1 780 000

Total Revenue

 

4 140 000

Permanent employees

89 x $80k / 12

590 000

Temporary hires

69 x $30k / 12

170 000

Per employee overheads (rent, computers, travel, conferences, trade shows, telephones, office supplies)

158 x $15k / 12

200 000

Equipment

$500k / 12

40 000

Legal

$500k / 12

40 000

Subcontracts (ISI, University of Wisconsin)

$400k / 12

30 000

Total Expenses

 

1 070 000

Operating Income

 

3 070 000

Profit as a percentage of revenue

 

74%

Through February 28, 1997, $58 million in registration fees have been collected. Registration fees currently total around $8 million per month. As per the agreement with the NSF, 70% of the registration fees go to Network Solutions, and 30% goes into an Internet trust account administered by the NSF. Network Solutions' profit margin on these fees is probably 70-80%. At a 75% profit margin, these fees would have created $30 million in income for Network Solutions, and be generating an additional $4 million income per month. This represents a significant amount of money that can potentially be used to fight legal battles, either with domain name applicants, or with any party that attempts to restrict their current monopoly position.

In its role as contractor for the provision of InterNIC Registration Services, Network Solutions increasingly appears to be acting as a private entity, rather than a government contractor. An example of this appears in the following press release, available on the InterNIC Registration Services web site: Network Solutions and Leading ISPs Launch Premier Domain Registration Service Program (http://rs.internic.net/announcements/premier.html). This press release does not mention the InterNIC or the NSF. As such it is in violation of Cooperative Agreement article 14, which requires acknowledgment of the role played by the NSF. In addition, all news releases are required to be coordinated with, and approved by, the NSF prior to release. Given the lack of NSF acknowledgment, it seems unlikely that this happened. This press release also raises the question of the authority of Network Solutions to take advantage of its current position as the InterNIC Registration Services contractor, in order to enter into private agreements with third parties regarding the provision of InterNIC registration services. Lastly, there is the question of the appropriateness of publishing what appears to be a private press release on an InterNIC web site.

The September 12, 1996, New York Times reported SAIC is considering splitting Network Solutions off as a public company via an IPO (Initial Public Offering) (Internet Address Registry Might Take Its Stock Public, http://www.base.com/gordoni/thoughts/dns-control/nyt-1996-09-12.txt, copy as of September 12, 1996, also available at http://search.nytimes.com/web/docsroot/library/cyber/week/0912name.html, account required). The IPO would primarily be based on Network Solutions role as domain name registrar. Potentially, this is very disturbing. To date, the InterNIC has worked successfully because the relevant parties have performed roles of stewardship, rather than the role of monopolizers. Network Solutions is currently a government contractor. The consideration of an IPO suggests Network Solutions is considering attempting to play the role of monopolist. If an IPO ever does occur Network Solutions would be firmly entrenched in this role. The possibility of an IPO was recently mentioned in the April 1997 Cook Report (http://pobox.com/cook/06.01.shtml). It is also mentioned in the ARIN Frequently Asked Questions (http://www.arin.net/arin_faq.html) article 4, which was written in January 1997, and is sponsored by Network Solutions. Presumably an IPO will not be attempted around the time of the March 31, 1998 termination of the NSF contract, since the associated uncertainty would harm the offering price. It seems highly plausible, that if executed at all, any plans to go public will occur sometime within the next six months.

Network Solutions' monopolist inclinations are also shown through their leading of an effort to establish an organization known as ARIN (http://www.arin.net/) (American Registry for Internet Numbers). ARIN seeks to gain control over the assignment of network addresses in the US. ARIN itself would be organized as a non-profit organization. ARIN would determine the fees to be paid for allocation of IP addresses. These fees would then be passed on to Network Solutions, ostensibly for the services it provides as the registry. It is reasonable to impose fees for the allocation of a limited resource, such as the IP address space. It is also reasonable to impose fees as a signal to the market that the allocation of IP addresses imposes costs upon the top level routers. However, the fees proposed by ARIN are totally out of line with the underlying economics. The first problem is ARIN's prices are only weakly sensitive to the amount of address space requested. ARIN proposes charging ISPs $2,500 for a block of 8,000 IP addresses, $10,000 for 250,000 IP addresses, and $20,000 for an unlimited number of IP addresses. This pricing structure fails to send sufficiently strong economic signals to ISPs to ensure conservation of the IP address space. The second economic problem with ARIN's proposal is the proposed fee of $2,500 for the minimum amount of address space purchasable is perhaps 100-1000 times more than the cost imposed by such address space assignments on the top level routers. This will result in large undeserved monopoly profits for the registrar. Economic efficiency dictates the minimum amount of address space purchasable, and its price, should be close to the underlying economic cost of its provision on the top level routers. The minimum amount of address space purchasable should be made sufficiently small that the linear fee desired to ensure conservation of address space becomes negligible. As a result the price should just reflect the underlying costs imposed on the top level routers. Having a higher than necessary minimum amount of address space purchasable will result in the wasteful consumption of IP address space. The third economic problem is that by not catering to users requiring fewer than 8,000 IP addresses, and forcing such users to obtain address space from an ISP, ARIN will be making it more difficult for such users to switch ISPs. The economic inefficiencies resulting from this, will more than likely offset any savings in cost to the top level routers. ARIN organizational structure is largely that of a self perpetuating oligarchy. Neither the authority of ARIN to control the assignment of network addresses, nor its authority to place Network Solutions in charge of the administration of such assignments is addressed by ARIN's proposal.

3.5 Future Naming Authorities

There is a widely perceived need for DNS to be administration within the context of a solid international legal framework. The recent report to the Department of State Advisory Committee on International Communications and Information Policy (http://ksgwww.harvard.edu/iip/acicip.html), Report to the Advisory Committee on International Communications and Information Policy on the Working Group on Intellectual Property, Interoperability and Standards (http://ksgwww.harvard.edu/iip/acifinal.html), contains the following resolution:

"The regime for management and maintenance of Internet identifiers at the global level should transition toward international administration in an open and public manner. Global administration of Internet identifiers should be open, broadly representative, and internationally accepted. It should provide for policy oversight and effective coordination of registration services."

This report summarizes commonly identified problems with the current situation as:

"... 1) these domains are international and therefore should not be administered by the U.S. alone; 2) the U.S. agencies involved are mission agencies which lack expertise in policy issues; 3) NSI is perceived as a government-sanctioned monopoly, which no longer makes sense given the explosion of the commercial Internet; 4) ISI is seen as handful of technical experts who should not be making policy decisions."

Clearly, there is a need for change. Unfortunately there is not a clear consensus as to who within the government is responsible for driving such changes, nor is there an appropriate international body to which control can be passed.

Potential government players include:

Potential international players include:

Potential non-governmental players include:

Governmental organizations reported to be investigating the issue of DNS governance include the Federal Communications Commission, Federal Trade Commission, Federal Networking Council, Office of Management and Budget, and the Working Group on Intellectual Property, Interoperability and Standards.

The IAHC is currently the only organization with a set of mature plan for DNS governance. The main objection to the IAHC proposals is not so much the contents of the proposals themselves, but simply that governance would remain in the hands of a group of technologists, rather than the international community. The work of the IAHC includes:

The IAHC proposes to create seven new top level domains, and to develop the technology necessary to permit multiple registrars to register names in each of these new domains. The ability for multiple registrars to be able to register names within a single shared top level domain is highly desirable. It provides the competition necessary to prevent monopoly pricing and control of the DNS name space. The IAHC has mainly concerned itself with the definition of a suitable legal framework for the provision of DNS service. So far, the IAHC has not created the necessary underlying technology, nor addressed the many operational issues associated with its plans. The IAHC has also not sufficiently addressed how it will manage the existing top level domains currently administered by the InterNIC. The technical specification of how registrars will share in the administration of top level domains is being worked on by theIETF coredb working group (http://www.imc.org/ietf-coredb/). This technical specification is not expected to be completed until April 1998. Thus, while the IAHC appears to be on the right track, its plans currently appear to be 1-2 years from becoming an operational reality.

A recent abstract of an article (Domain Name System Under Stress, IAHC Position Weak, http://pobox.com/cook/06.01.shtml) from the Cook Report (http://pobox.com/cook/) assesses the IAHC chances of success as follows:

"While we think the goals set by the IAHC are worthy of support, we believe that they face very difficult odds that may scuttle their effort. ...

In evaluating at IAHC's chances of success one must ask two things. Where are we to assume that it will get the considerable sum of money required to build its infrastructure and make it work in a very short period of time? Second who will register what domains and how quickly will the data from the new Registrars', IAHC- sponsored, seven top level domains start being added to the data bases of the root DNS servers? The IAHC side has indicated that it would like NSI to join CORE and add .com to the domains registered by the CORE Registrars.

As soon as the IAHC CORE system has an operational shared database, we'd like to see NSI join and do just this. However when one looks at the stark reality that NSI would have to give up control over its pre-eminent cash cow in order to do so, we think it very unlikely that this will occur in the short term. After all the shared database system has to be built first and it is not clear where the sponsors are going to find the money necessary to do so. If they do succeed in building a working system that gains acceptance, IANA and community pressure could force some changes. The biggest immediate question is how the entire system will weather a legal challenge."

The first of these legal challenges against the IAHC's plans was filed February 27, 1997: Image Online Design, Inc. v. Internet Assigned Numbers Authority and International Ad-Hoc Committee (http://www.iodesign.com/complaint.html, copy as of March 24, 1997). This complaint alleges the IAHC's actions violate an agreement made by IANA to assign the WEB domain to Image Online Design. It is not clear whether the IAHC has the financial resources to defend against such legal challenges. This legal challenge may be able to be weathered, but a legal challenge from a better funded party, such as Network Solutions, may prove harder to withstand. This would not be on the merits of any such case, but merely a result of the time and expenses associated with such litigation. Network Solutions recently released a document opposing the IAHC's plans for the provision of competitive registration services (Secure Internet Administration and Competition in Domain Naming Services, http://www.netsol.com/papers/internet.html). This document also proposes an alternative model for DNS governance in which top level domains are exclusively owned, and registration databases are proprietary.

A brief opposing the IAHC's circulation of a Memorandum of Understanding at the ITU was recently submitted to several US government agencies by Anthony Rutkowski (In Re: Establishment of a Memorandum of Understanding on the Generic Top Level Domain Name Space of the Internet Domain Name System, http://www.wia.org/pub/dns-brief.html). This brief alleges that the IAHC is seeking to secure international agreement to its proposals through signature by the member states of the ITU, and that in doing so its actions are unlawful. The Memorandum of Understanding itself does not currently make clear whether it is intended to be signed by the member states of the ITU, or merely by interested private individuals.

RIPE is mainly interesting from an operational perspective. RIPE offers various European registration services. The administration of the IP address space for Europe is delegated by the IANA to RIPE. RIPE currently employs 20 people, and is run on a non-profit basis. If a replacement for the current provider of InterNIC Registration Services ever had to be found on short notice, RIPE may be a suitable candidate. RIPE does not however currently have any DNS registration experience.

It should be mentioned that the provision of registration services is not a technically difficult task. Undoubtedly, many parties could, in an emergency situation, raise the capital and find the staff necessary for the provision of core registration service in a matter of 2-3 months. The main issues are simply matters of logistics. These issues include obtaining office space, network connectivity, and telephone call processing capabilities. The technical issues associated with the provision of registration services are relatively minor.

One of the main weaknesses, both of current and future possible registration authorities, is an almost complete lack of economic policy expertise. Both domain names and IP addresses are limited resources, and as such their allocation needs to be properly managed. Today, both domain names and IP addresses are allocated without any consideration of the fundamental economic policy issues. Contrast this with the role of the FCC in managing the radio spectrum, another limited resource. The FCC draws upon a wealth of internal economic policy experience and conducts auctions for spectrum rights according to economically sophisticated bidding rules (McMillan, Selling Spectrum Rights, Journal of Economic Perspectives, 8:3, p. 145, 1994). There are many issues relating to the Internet that require an understanding of the underlying economics. How should multiple registries be structured to ensure competition? What pricing model makes the most sense for domain names? How should domain name disputes be resolved? Should new top level domains be created? Should a portion of the namespace within new top level domains be reserved for future allocation? Should an auction be held for desired names in new top level domains? Should the price of domain names be managed to limit the rate at which the name space is consumed? How should domain name speculation be handled? How should the IP address space be allocated and managed? What sorts of regulations are appropriate for peering agreements? These are all questions that can most appropriately be answered using an economic framework. It would be far easier to answer many of these questions now, than to wait until the Internet becomes a mature technology, and then be forced to step in and implement policy. An analogy exists with the phone system. It would have been far easier and far preferable, to have prevented monopoly control of the phone network, than to have to attempt to introduce competition after it has been extinguished. Not all of the above questions need answering today, but they are all questions that should start to be considered. The economic underpinnings of the Internet need to be far better understood. Unfortunately, neither the IANA, the InterNIC, nor the IAHC, appear to have any economic policy expertise.

4. Technical Analysis

4.1 Registration Database Contents

The ability of third parties to provide either name resolution services, or to take over the role of providing registration services, is in large part dependent upon the public availability of information contained in the domain name database.

The InterNIC requires the InterNIC: Domain Template (ftp://rs.internic.net/templates/domain-template.txt) be filled out whenever a new domain is registered, or the information for an existing domain is changed. In filling out this form the InterNIC requires an applicant agree to Network Solutions: Domain Name Dispute Policy (ftp://rs.internic.net/policy/internic.domain.policy).

The information gathered on the Domain Template comprises:

All of this information is stored in an internal database by Network Solutions. Portions of this database are then made public.

4.2 Availability of Registration Data

The task of setting up a replacement registry is greatly simplified if the data currently managed by the existing registry is readily available.

The most important information contained in the registration database is the list of domain names and the name servers for these domains. This information is presently made available by the InterNIC in the Zone Files that are updated three times a week:

The information contained in the Zone Files is:

At the very least, for DNS to continue to function, the InterNIC will need to continue to make these Zone Files available to the root name servers, although they need not make these files publicly available.

The InterNIC also currently makes available and regularly updates two other files containing domain name information, although the InterNIC need not continue to do so in the future. These two files are:

These two files contain:

It seems highly plausible that making this information available is a historical procedure that Network Solutions continues to perform, without fully re-examining the reasons for doing so. This is suggested by these files only containing the old registration fields that have existed for some time, and none of the more recently added registration fields. The existence of these files is documented in RFC 1032: Domain Administrators Guide (http://www.internic.net/rfc/rfc1032.txt), which dates back to 1987 when SRI was operating the NIC. When Network Solutions started running the NIC they probably just duplicated and automated the same procedures as SRI. At the strategic level, Network Solutions may be unaware they continue to make such data publicly available.

Finally the InterNIC currently offers the ability to query and retrieve single entries from its database using the Whois Application (http://rs.internic.net/tools/whois.html). Whois provides:

Whois also provides the date a record was created, and the date it was last updated.

Unfortunately, Whois can only be used to provide information about individual records one at a time, rather than provide the contents of entire InterNIC registration database. A single Whois query takes of the order of one second. To retrieve the contents of the entire InterNIC database, with its one million or so records, would therefore take around two weeks. Changes made during this time period would result in minor inconsistencies in the data. It may be possible to speed the rate of retrieval up by performing multiple Whois queries in parallel.

Information contained in the InterNIC registration database that appears to not be available through any means consists of:

4.3 Feasibility of Establishing a New Registrar

The primary factor in the setting up of any new or replacement registrar is whether the net would make use of the DNS data provided by the new registrar. This key issue will be considered later in this document. The present question is whether sufficient information is available for a new registrar to to incorporate the existing domains into a new registration database, and to perform administrative actions on these domains.

Today it appears that it would be relatively easy to establish a new replacement registrar without requiring the cooperation of Network Solutions. However, Network Solutions could at any time limit the availability of the necessary data, making this task substantially more difficult. With the cooperation of, or with control over, the root name servers, Network Solutions could make the Zone Files inaccessible. This would then make the task of establishing a replacement registrar impossible.

Today it would be possible to establish a replacement registry using only the Zone Files and the Domain Contacts file. It is not even necessary to to look up every domain using Whois. This minimalist approach would provide insufficient information for the operation of a complete registry, but because the email address of the administrative and technical contacts are available, it would be possible to email them requesting they provide any additional desired information. Additional desired information includes the name and address of the registered organization, and information on the billing contact.

The main issues to be dealt with in establishing a new registry are not technical issues, but simple logistical issues related to the size and scope of any such effort. The large number of domains that presently exist make it essential that registration activities be automated and streamlined to the maximum extent possible. Many domains can probably be administered with little or no actual human involvement, but those small fraction of domains that need to be handled specially will end up consuming a significant amount of time. Disputes over trademarks and domain name ownership are likely to be one such contributor to these costs. The number of domains in dispute is not known, but Network Solutions has, to date, been named as a defendant in 17 trademark related lawsuits (Annual Report 4, section 4). Most domain name disputes are probably resolved without direct recourse to the legal system, but their resolution probably still requires the active participation of Network Solutions. Invoicing, and the collection of fees, also undoubtedly involve significant amounts of effort. Other tasks to be performed include updating domain registration records, processing customer email, and providing customer telephone support.

Most domain name applications can probably be fully automated. However, with the overhead of a few lawsuits, and the need to handle various other special cases, it might be reasonable to assume each registrant will on average require between 5 and 10 minutes of processing time per year. With currently around one million domain names in existence, this translates into requiring between 50 and 100 employees. This is a substantial number, but even a $20 annual fee for each domain would be able to cover these costs.

On a short term basis it would probably be possible to perform 98-99% of the work required of a registry with a small staff of perhaps ten people, and have all registry actions performed via a simple web based interface. During this time any special cases that needed to be dealt with would backlog, but this would not incur any noticeable impediments to the overall smooth functioning of the Internet. Doing this would provide the few months breathing room necessary to develop an organization capable of dealing with the full range of registration activities.

Additional issues to be resolved in considering the establishment and operation of a replacement registry include the registration and administration of network address, autonomous system numbers, and the IN-ADDR.ARPA domain. These are not trivial problems, nor are they fundamental obstacles to setting up a replacement registry. Compared in magnitude to the possible importance of a replacement registry, these issues are fairly insignificant.

4.4 The Role of the Root Name Servers

If a new registry was established, would users of the Internet use the new registry's data to resolve host names? Before answering this question, it is necessary to explain, in a little more detail, how DNS is used maps from a host name to an IP address. Consider a computer wishing to map a domain name into an IP address. To do this it contacts a DNS server. The IP address of the DNS server has to be configured before connecting to the Internet. For computers permanently connected to the Internet, the address of the DNS server must normally be configured by a system administrator before the computer can be used. For computers that connect to the Internet via a modem, the address of the DNS server is often configured when the modem establishes a connection with the ISP. The DNS server is usually a particular designated computer on either the local network, or at the ISP.

How does a DNS server know how to map a domain name into an IP address? Some DNS servers, known as forwarders, simply contact another DNS server. The DNS server to contact is statically configured. This is especially prevalent in Europe because of a desire to minimize the amount of inter-continental traffic. It is also common within companies because of the blocking of DNS traffic by firewalls. Perhaps 40-80% of DNS servers are configured as forwarders.

How does a non-forwarding DNS server know how to map a domain name into an IP address? At least initially, it contacts a root name server. A list of root name server IP addresses gets statically configured when a DNS server is first installed. Any one of these root name servers may be contacted by the DNS server. If the first root server it attempts to contact does not respond, which should normally be a rare event, the system will simply attempt to contact another of the root servers on the list. The InterNIC maintains a list of root servers (InterNIC: List of Root Name Servers, ftp://rs.internic.net/domain/named.root).

Name server software is shipped by manufacturers with a default standard list of root name servers, although this list can be readily changed. Manufacturers invariably use the list of root name servers maintained by the InterNIC. Only perhaps 10% of systems ever have the default list of root name servers changed by the end administrator. On those systems for which the list of root name servers has been changed, it has almost invariably simply been changed to a newer version of the list maintained by the InterNIC.

For the last three or four years there have been nine root name servers on the InterNIC list of root name servers. The root name servers on this list have seldom changed. In January 1997, Jon Postel announced that four new root name servers (NameDroppers: two new root only servers, http://www.base.com/gordoni/thoughts/dns-control/new_rootservers.msg) have been added to this list. Two of these new machines are located at Network Solutions (the InterNIC), and two of them are located at ISI (the IANA). Currently, very few systems are configured to initially consider contacting any of these four new root name servers. The significance of this will be explained later.

Excluding these four new servers, changes to the official list of root servers have been as follows:

Official Root Servers

Owner

1990

(http://www. base.com/ gordoni/dns- control/root- servers/ named.root. 1990-04-29)

1993

(http://www. base.com/ gordoni/dns- control/root- servers/ named.root. 1993-04-21)

1994

(http://www. base.com/ gordoni/dns- control/root- servers/ named.root. 1994-05-11)

1995

(http://www. base.com/ gordoni/dns- control/root- servers/ cache.dns. 1995-09-01)

1997

(http://www. base.com/ gordoni/dns- control/root- servers/ named.root. 1997-02-28)

InterNIC

none

198.41.0.4

unchanged

unchanged

unchanged

UMD.EDU

128.8.10.90

unchanged

unchanged

unchanged

unchanged

ISI

26.3.0.103 (dead), 128.9.0.107

removed

128.9.0.107

unchanged

unchanged

NASA

128.102.16.10, 192.52.195.10

unchanged

unchanged

192.203.230.10

unchanged

DDN.MIL

192.67.67.53 (dead)

192.112.36.4

unchanged

unchanged

unchanged

ARMY.MIL

128.20.1.2, (dead) 192.5.25.82 (dead)

128.63.4.82 (dead), 192.5.25.82 (dead)

unchanged

128.63.2.53

unchanged

AF.MIL

26.1.0.13 (dead)

removed

none

none

none

NORDUnet

one

192.36.148.17

unchanged

unchanged

unchanged

ISOC

none

none

none

39.13.229.241 (dead)

192.5.5.241

PSI.NET

192.33.4.12

unchanged

unchanged

unchanged

unchanged

SRI.COM

none

192.33.33.24 (dead)

removed

none

none

Control of the Internet name space should be viewed as a function of control of the root name servers. All of the root name servers are essentially run on a volunteer basis. Looking at the current nine root name servers, three are run by government agencies, two by educational institutions, one by a professional society (The Internet Society), one by a private company (PSI), one by an overseas organization (NORDUnet), and one is run by the InterNIC which is the result of a cooperative agreement between the government and a private company. Thus, most parties are likely to be sympathetic to the public and/or government interest. The balance might slowly change following the introduction of the four new root servers, but not too drastically. It is important to note, as will be explained in the next section, that not all of the root name servers exert the same degree of control over the Internet name space.

Today, all the root servers make information available from the zone files created by the InterNIC. The InterNIC updates the zone files three times a week. If any of these root name servers were to start presenting different data than the others, the Internet would start to become fragmented. Known bugs in many name servers might make this situation even worse than might initially be imagined. These bugs cause name servers to fail to fully confirm the authority of the data they receive. This could potentially result in systems seeing a confusing and inconsistent mixture of DNS data from different authorities.

4.5 Control of the DNS Name Space

Based on the previous list of root name servers, widely believed, but actually incorrect estimates as to the degree of control over the Internet name space exerted by different parties are as follows:

Incorrect Estimates as to Control over the DNS Name Space

Group

Parties

Proportion of Control

US Government

DoD, Army, NASA

33%

Educational institutions

ISI, UMD

22%

Professional societies

ISOC

11%

Private companies

PSI

11%

Overseas organizations

NORDUnet

11%

Other

InterNIC

11%

Note that control is not determined on a "voting" basis. Each of the above listed systems simply exercises control over the DNS name space as seen by some proportion of the total number of systems on the Internet.

The remainder of the information contained in this section should be treated as highly confidential.

BIND (Berkeley Internet Name Daemon) is the most popular DNS implementation today. A flaw exists in the scheme BIND uses to determine which root name servers to contact. This flaw is explained in the Appendix, Determination of the Root Name Servers in BIND.

As a result of the flaw in BIND, not all name servers have an equal degree of control over the DNS name space. Many name servers exert almost no control, and one name server in particular gets to exert control over roughly half the Internet name space. Estimates as to the degree of control of different root name servers over the Internet name space are made in the Appendix, Estimates as to Control over the DNS Name Space, and reproduced below:

Best Guess Estimates as to Control over the DNS Name Space

Owner

IP Addresses

Proportion of Control

InterNIC

198.41.0.4

46%

ISI

128.9.0.17

24%

NORDUnet

192.36.148.17

17%

ISOC

192.5.5.241, 39.13.229.241

9%

unknown

unknown

4%

The above are best guess estimates, and significant margins of error seem likely.

The root name server 198.41.0.4 exercises control over roughly half the Internet name space. Whois reports this network address is owned by Network Solutions. However, precisely who legally "owns" this network address is uncertain. It might legally belong to Network Solutions, or it might legally belong to the NSF and may merely be administered by Network Solutions. This will be explored in great detail later.

Part of the control over the DNS name space is listed as controlled by NORDUnet. Using Whois to determine the owner of the network address for this name server, one finds that it is actually owned by the Swedish Royal Institute of Technology in Stockholm. Over the next 12 to 24 months control will transition from NORDUnet, to a network owned by The RA Project (http://www.ra.net/). This follows the recent addition of the four new root name servers, which will change the control derived from implementations of BIND that contact the last listed name server. The RA Project has the same postal address as IANA and ISI, and is an NSF funded collaborative venture between Merit Network, Inc. and ISI.

Whois also shows that the Internet Society name server is currently actually owned by Paul Vixie, one of the maintainers of BIND. The previous network address for this name server is now owned by IANA.

If the initial proportion of name servers controlled by any one party was in the 60-70% range, an attempt to gain full control over the DNS name space would probably succeed. This assumes any such attempt is performed slowly, gradually, and without initially imposing any financial barriers to access. The reason such an attempt would succeed is because parties that presently contact other name servers would have a strong interest in seeing the same names as seen by the rest of the net. They would thus, over time, switch their name server configuration files to point to the same root name servers as everyone else.

According to Annual Report 3 section 2.1:

"Root server maintenance cost support has been offered to each of the organizations owning the servers; two have expressed interest and terms are being negotiated."

It is not known which two organization expressed an interest in receiving funding to cover the costs of operating a root server, whether agreement was reached with Network Solutions or the InterNIC to provide such funding, nor the terms of any such agreement. Depending on all of these factors, it is conceivable that Network Solutions could already have control over the DNS name space. No evidence has so far been found to be able to either support or refute this possibility.

Today, it seems no one party has sufficient control over the DNS name space to be able to seize full control, although Network Solutions appears to come dangerously close. Indeed, given the margins of error in the estimates made, it is quite possible Network Solutions already has sufficient power, and this power has simply been underestimated. Network Solutions, operating in conjunction with ISI or any one or two other parties, would have the necessary degree of power. The possibility of a relationship between Network Solutions and one of the other parties exists, although this can presently be neither confirmed, nor refuted. Lastly, if there was ever a three way split over the question of authority, Network Solutions would appear to exert sufficient power to achieve control.

Both the flaw in BIND, and the control over the DNS name space that results, should be treated as highly confidential. Knowledge that just a few root name servers control the Internet name space, rather than nine root name servers controlled by different independent parties, significantly alters strategic goals, bargaining positions, and the overall balance of power.

4.6 Likelihood of Root Servers Using Data From a New Registrar

If a new or replacement registrar came into being, would the net use the data provided by the new registrar? It depends entirely on the behavior of the parties in control of the root name servers. Or more precisely, it depends upon the behavior of the parties in control of the four key root name servers: the InterNIC, ISI, NORDUnet, and the ISOC.

In the context of implementing IAHC's plans it has been claimed the operators of the root name servers would all follow the lead of Jon Postel and the IANA. (An authoritative conformation of this claim has not been found, although there seems no reason to doubt it.)

It seems likely the operators of the root name servers would likewise follow any other clearly stated public policy. This would probably include any policy in respect of a future registrar that was to provide the authoritative source of registry data. Many of the current root servers are run by the government and various other public bodies. The operators of the root name servers also have a clear understanding of the dangers of the Internet fragmenting. These two facts make it appear highly likely that any stated government public policy will be followed. Before promulgating any such public policy though, it would clearly be wise to seek Jon Postel agreement.

Summarizing, provided a clear public policy regarding the provision of registration services in the future is established and clearly articulated, it seems its implementation should not prove too difficult.

This analysis is predicated on the belief Network Solutions is unaware 198.41.0.4 appears to exert control over half the Internet name space. It assumes Network Solutions believes 198.41.0.4 is just one of nine current key root name servers, and only exerts around 10% control over the entire Internet name space. Strong evidence that Network Solutions is unaware of the importance of 198.41.0.4 is provided by Network Solutions' recent response to the IAHC's plans (Secure Internet Administration and Competition in Domain Naming Services , http://www.base.com/gordoni/thoughts/dns-control/nsi-iahc.msg). In this document Network Solutions discusses the importance of the root name servers, and proposes that the root name servers should be administered by one or more neutral third parties.

If Network Solutions believes 198.41.0.4 exerts 10% control, they will not believe they have any chance of gaining control over the DNS name space, and will thus acquiesce to the terms of any public policy. This public policy could even include the decision to replace them as the current registrar. They would see little value in attempting to hold on to 198.41.0.4. Presumably, they would be willing to pass control of this root name server on to a third party, or agree to an amended contract under which they operate this root name server in accordance with any new policy.

The above would likely still be true even in the presence of any previously mentioned possible agreement between Network Solutions and the providers of two of the other root name servers. At most, Network Solutions would imagine themselves in control of 30% of the Internet name space. This degree of control might be tempting, but hopefully would appear too far from the possibility of gaining full control to justify any attempt to do so.

If Network Solutions believes 198.41.0.4 exerts control over half the Internet name space, then an attempt to establish a new registrar will probably run into some very serious problems. The possibility of gaining full control over the DNS name space would seem within reach, and this IP address would be seen as extremely strategically valuable. Network Solutions would likely attempt to claim legal ownership and control over this IP address, and delay, block, and resist, any attempts to make it pass control over to a future registrar. Network Solutions would not configure any name servers they controlled with data provided by a new registrar. Instead, Network Solutions would attempt to provide name registration services for the half of the Internet they control.

This would be a nightmare scenario that would result in a splitting of the net. There would be two registries each providing registration services for perhaps half of the net. Initially, any such fragmentation would not be very severe, because the two registries would start off with the same data. The two registries would likely add new domains that conflicted with each other. Changes to domains might also not be submitted to both registries, especially if one of the registries began to dominate, and as a result increased its fees. Over time, the net would become increasingly divided. Web sites and email addresses accessible to a person using one registry would not be accessible to a person using the other registry. This situation would be very unstable, and within a year or two a clear winning registry would emerge. Everyone would switch to using that registry, which would then be in full control of the net. During this time, as a strategic option, Network Solutions could use the existing profits it has earned to eliminate all fees for registration services in the hope that by doing so it would become the winning registry, and ultimately gain monopoly control over the Internet.

The operators of the root name servers would likely see the splitting of the net as a worst case outcome, and do everything they could to avoid this scenario. Consequently, if Network Solutions was to threaten such a scenario, the operators of the root name servers might refuse to implement a policy that would cause Network Solutions to carry out its threat, and instead cede to continuing to carry registration data provided by Network Solutions. In effect, it may be sufficient for Network Solutions to threaten to fragment the net if not given monopoly control, in order for it acquire monopoly control.

In summary, if Network Solutions is not aware that 198.41.0.4 might be in control of half the Internet name space, it should be easy for a new registry to replace them. Network Solutions is probably unaware of this fact, though this is not certain. If Network Solutions is aware that 198.41.0.4 may be in control of half the Internet name space, replacing them could prove extremely difficult. With a little luck, legal maneuvering, threats of fragmentation, and delaying tactics, they may be able to leverage their existing position into one whereby they acquire monopoly control over the Internet.

5. Legal Analysis

5.1 Property Rights in the Registration Database

It is important to understanding any property rights that might reside in the DNS registration database presently administered by Network Solutions. Whether domain names are a form of property is an interesting, but separate, legal question, and not something that will be addressed here.

In what can only be viewed as an alarming development, Network Solutions recently started making claims as to ownership of the DNS database. This is reported on in the following articles:

This section will consider what property rights, if any, reside in the DNS database. A later section will consider who owns those rights.

Key to determining whether a work is eligible for copyright is the constitutionally derived requirement for originality. Originality requires that both the work be independently created by its author, and some very minimal degree of creativity be involved in its creation. The requirement of originality means that facts themselves can not be copyrighted. A compilations of facts may however be copyrighted, provided the compilation displays originality, and Congress chooses to grant such copyrights. Congress has chosen to grant such copyrights. 17 USC 101 (http://www.law.cornell.edu/uscode/17/101.html) defines a compilation as:

"a work formed by the collection and assembling of preexisting materials or of data that are selected, coordinated, or arranged in such a way that the resulting work as a whole constitutes an original work of authorship."

Thus, for a compilation of facts to be eligible for copyright, the "selection", "coordination", or "arrangement" of those facts must meet the requirement of originality. In the context of a database, it would appear that selection involves deciding on the fields and records included in the database. Coordination is not relevant to the DNS database by itself, but in the case of a database with multiple tables, it might be argued coordination has to do with the relationships between those different tables. Arrangement has to do with the order of the fields and records in the database. A database made up entirely of non-copyrightable facts must meet two tests in order for it to be copyrightable. First, the selection, coordination, or arrangement of some of the facts in the database must have been independently performed by the author. Second, this selection, coordination, or arrangement must contain the modicum of creativity necessary to provide originality. If a database meets these two tests, the database is eligible for copyright. The elements of the database that meet these tests can not be copied without permission from the author. However, the underlying non-copyrightable facts contained in the database may still be freely used.

In Feist Publications, Inc. v. Rural Tel. Service Co., 499 US 340 (1991) (http://www.findlaw.com/scripts/getcase.pl?court=US&vol=499&invol=340) the Supreme Court ruled that Feist's copying of names and phone numbers from Rural's telephone directory white pages was not in violation of the Copyright Act. First, the court affirmed that facts themselves (the names, and phone numbers of Rural's subscribers) are not eligible for copyright. The court then found that neither Rural's selection of facts (choosing to provide the name and phone number of each subscriber in Rural's service area), nor arrangement of facts (listing names followed by phone numbers, and ordering entries alphabetically) possessed the creativity necessary to meet the requirement for originality. The information included in Rural's white pages included four fictitious listings, designed to detect copying. The Supreme Court failed to address the issue of whether these fictitious listings constituted facts. The Supreme Court also did not address whether, if the fictitious elements had been more sophisticated, involving the necessary level of creativity to themselves be eligible for copyright, would it still be legal to copy the data.

The necessary degree of creativity involved in the selection, coordination, and arrangement of facts in a database for the database to be eligible for copyright is extremely low, but some degree of creativity is none the less required:

As previously mentioned, the registration database currently comprises the following information:

This information is recorded for every domain name administered by the InterNIC. In RFC 1032: Domain Administrators Guide (http://www.internic.net/rfc/rfc1032.txt), which was written at the time SRI operated the NIC, the following information was requested on the registration form:

Comparing this with the current registration form, the following information can be seen to have been added:

The following information has been removed:

And the following information has been changed:

It thus seems prudent, given the existing case law, to be cautious. A credible claim of compilation copyright may be exertable on the fields of the current InterNIC database, over and above any claims exertable on the previous SRI NIC database.

For a simplified database such a claim seems far less feasible. For example, the following fields appear to represent the minimum set of information necessary to properly administer the registration database:

The above fields were not arrived at by shuffling around the existing fields. They were obtained through consideration of the information necessary for the smooth administrative operation of a registration database. Since this is probably the minimal set of information necessary, not only would a copyright infringement claim probably fail on the grounds that no copying has occurred, but also on the grounds that the selection of fields lacks the creativity necessary for copyright protection.

A separate issue is whether a copyright claim could be made regarding the selection of domain names included in the InterNIC database. The situation here appears analogous to the Feist case, and thus it seems no such claim could be made. One possible counter argument to this might be that the InterNIC's domain name approval policies have actively shaped and selected the resulting name space. However, these policies are fairly weak. Domain names are granted on the basis of whoever first requests them. Besides this, the only other known policies are a policy on offensive domain names, and a policy on domain names subject to a trademark dispute. Another rebuttal to this counter argument would be that the selection criteria used in creating the new registration database was not to use the same list of domain names as are managed by Network Solutions. Instead, it could be argued the selection criteria used, was to select all registered domain names within appropriate top level name spaces, according to IANA's definition of what constitutes a registered domain name. The strength of such rebuttals might depend on whether a domain name is a form of property, or is simply a mapping between a character string and an IP address chosen by the InterNIC from the applications it receives. If a domain name is a form of property, then it is reasonable to select on this basis without infringing any compilation copyright. Suppose a domain name is simply considered to be a suggested mapping between a character string and an IP address, that the InterNIC has arbitrarily chosen to accept. Then, justifying the selection of the same domain names is harder to argue, but the situation may still be seen as analogous to Feist. Fortunately, it has been reported Network Solutions took the position that a domain name is a form of property in Network Solutions, Inc. v. Clue Computing, Inc., 41 U.S.P.Q.2d 1062 (D.Colo. 1996) (Is a domain name property?, http://www.patents.com/pubs/jmls.sht#prop).

Additional background material on the legal scope of copyright in databases is contained in Practical and Legal Protection of Computer Databases (http://www.seamless.com/rcl/article.html).

The Feist case does not consider what happens if some of the records in the database are invalid records containing copyrighted material deliberately inserted to prohibit copying of the database. It is not clear how the courts would view this. Would this be seen as a form of obstruction, or as a shrewd business practice? This is an issue, because following US ascension to the Berne convention, a copyright notice is no longer needed to obtain a copyright. If this was considered to be a serious issue, a solution might be to send email to the technical contact for each record, informing them of the intention to copy the record. This email could state the belief that the record is not subject to copyright, but if this belief is incorrect, request the technical contact reply, and the record will be removed. In reality, this is probably not a serious issue, since the lack of a copyright notice allows assertion of the defense of innocent infringement. Searching the data for copyright notices is probably sufficient to guard against the risk of fictitious listings.

In summary, it seems the registration database may be ownable as a form of property. However, this can not be used to prevent the creation of a new database constructed from facts contained in the existing database.

It must be stressed that this analysis is based upon the law as it stands today. There have been both legislative proposals and an international diplomatic conference that suggested creating a intellectual property right in databases. Under such a proposal there is little doubt but that the registration database would be a form of property, and unauthorized use of the database could be prohibited (Software Developers Comments on the WIPO Database Treaty, http://www.base.com/gordoni/thoughts/wipo-db.html).

5.2 Ownership of the Registration Database

It is not clear whether the registration database is ownable as a form of property. However, it seems prudent to ask, if a property right did exist in the database, would the database belong to the NSF or to Network Solutions? This is especially important given the possibility that database treaty legislation may be enacted.

Who owns these rights is determined by the terms of the contract between the NSF and Network Solutions:

This contract make reference to the following documents:

The Cooperative Agreement states that the terms contain in GC-1 apply to the contract. GC-1 article 18(a) defines the term "subject writing" to include databases, and GC-1 article 18(b) then provides:

"Except as otherwise specified in the grant or by this paragraph, the grantee may own or permit others to own copyright in all subject writings."

GC-1 article 1(b)1 provides that OMB A-110 apply to contracts with commercial organizations. OMB 36(a) provides:

"The recipient may copyright any work that is subject to copyright and was developed, or for which ownership was purchased, under an award."

Thus, assuming the registration database is eligible for compilation copyright, it would appear Network Solutions is permitted to copyright it. In addition, OMB 36(d) provides that were a property right in databases created, Network Solutions would also own the title in that.

Cooperative Agreement article 9 requires:

By December 31 each year, the Awardee shall submit both electronically and in 10 hard copies an Annual Report, Program Plan and Budget to the Foundation for approval. ... Each submission should contain narrative information indicating (for the past year's activities) ... patents, copyrights, or other innovations resulting from the activities ...

A FOIA (Freedom of Information Act) request was filed with the NSF to learn of any such copyright claims made by Network Solutions (NSF FOIA No. 97-041 Request, http://www.base.com/gordoni/thoughts/dns-control/nsf-foia-97-041-request.html). The NSF response was no copyright claims have so far been reported by Network Solutions to the NSF (NSF FOIA No. 97-041 Response, http://www.base.com/gordoni/thoughts/dns-control/nsf-foia-97-041-response.html):

"You asked for copies of any Annual Reports/Program Plans/Budgets that include mention of any "patents, copyrights, or other innovations resulting from the activities" of NSI. There have been no filed reports that included such mention."

This failure to report any such claims to the NSF seems at odds with Network Solutions' previously discussed public claim to ownership of intellectual property rights in the registration database.

In summary, if there is a property right to the registration database, Network Solutions is probably the owner of that right. Network Solutions is supposed to, but so far has failed to, document claims to any such property rights.

5.3 Fees for Copies of and Title to the Registration Database

GC-1 article 19(b) provides:

"The grantee shall have no obligation to NSF with respect to (1) license fees and royalties for copyrighted material ..."

In GC-1 (10/95) this clause has been changed slightly to make it clear that these terms might be overridden by the provisions of the grant.

Cooperative Agreement article 3B provides that the work be performed in accordance with the Awardee's Proposal, and Awardee's Proposal Q.1 provides:

"Under guidelines set forth by NSF, we will provide as much or as little service as individual countries want or need, but the information we collect and dispense will be freely available to all."

GC-1 article 19(b) and Cooperative Agreement article 3B, thus appear to be in conflict. Cooperative Agreement article 13 makes it clear that in the event of a conflict between the terms of the Special Provisions of the Cooperative Agreement and GC-1, the Special Provisions have precedence. These Special Provision include article 3B, and so Cooperative Agreement article 3B has precedence, and GC-1 article 19(b) is effectively inoperative.

Thus, during the contract, if it chooses to make copies of the database available, Network Solutions is barred from charging any fees for doing so. Note that the term "freely available" might seem to imply not subject to copyright, but would probably be more strictly interpreted as simply meaning without fee. This difference is significant. If it meant "not subject to copyright", on termination of the contract, the database as it then exists would remain in the public domain. If, as is more likely, it means "without fee", then on termination of the contract, Network Solutions will hold copyright in the database as it then exists and be able to charge for it.

OMB 36(d) provides that when no longer needed for the originally authorized purpose, all intangible property be disposed of in accordance with OMB 34(g). Presumably then, upon termination of the contract, title in the registration database would no longer be needed for the originally authorized purpose. The originally authorized purpose being the provision of InterNIC Registration Services for the duration of the contract. OMB 34(g) provides:

"... the recipient may retain the equipment for other uses provided that compensation is made to the original Federal awarding agency or its successor. The amount of compensation shall be computed by applying the percentage of Federal participation in the cost of the original project or program to the current fair market value of the equipment."

A solid interpretation of this can not be given. It would however seem that fees generated from the registration of domain names count as "Program Income", and are not seen as part of the Federal share in the project. These fees constitute the bulk of the revenue earned by Network Solutions under the contract. Consequently the percentage of Federal participation in the cost of the project might only be around 5-10%. This percentage will decrease as revenue from domain registrations increases. Thus, on termination of the contract, Network Solutions will be permitted to retain title in the registration database by probably paying somewhere in the range of 1-3% of the database's fair market value.

5.4 Availability of Registration Data

The issue of availability is separate from the issue of copyright. Copyright has to do with the existence and ownership of rights that exclude the making of copies of the database. Availability deals with contractual provisions requiring the data contained within the database be made accessible to various parties. Even if a database is not copyrighted, the data in it may not be available, because limited access is provided to some or all the data in the database. Conversely, a database could be copyrighted, but the owner of the copyright may have entered into a contractual agreement requiring they make the data in the database available to particular parties, possibly on terms involving the payment of a stipulated fee.

Cooperative Agreement 3(C) requires the InterNIC provide registration services in accordance with RFC 1174. RFC 1174 article 1.3 requires:

"Copies of the aggregate Internet registration database(s) should be maintained by the IR and copies provided to each delegated registry to improve redundancy and access to this information. Updates to the database, however, would still be centralized at the IR with complete copies redistributed by file transfer or other means on a timely basis."

Also, as previously mentioned, Awardee's Proposal Q.1 contains:

"Under guidelines set forth by NSF, we will provide as much or as little service as individual countries want or need, but the information we collect and dispense will be freely available to all."

This thus seems to require that for the duration of the contract any data collected be made freely available to all parties. The only doubt might be whether "freely available to all" refers to any individual desiring the data, or just to countries that desire the data. The originally intended meaning at the time the contract was written is made clear by referring to a press release that the three awardees jointly released upon being awarded the contract, as described in InterNIC Midterm Evaluation and Recommendations: A Panel Report to the National Science Foundation (http://rs.internic.net/nsf/review/review-toc.html, copy as of March 15, 1997) section 2:

"Below we provide excerpts from a press release issued jointly by the InterNIC awardees in January 1993 ... NSI agreed to:

``... [provide the information from these assignments] to the directory and database services provider to be made available to the entire Internet community.''"

From which it is clear that the originally intended meaning of "freely available to all" was freely available to any individual that might desire the data.

GC-1 article 35(a) (article 36(a) in GC-1 (10/95)) contains a similar provisions requiring:

"NSF expects ... investigators to share with other researchers, at no more than incremental cost and within a reasonable time, the data, samples, physical collections and other supporting materials created or gathered in the course of the work."

NSF Grant Policy Manual (ftp://stis.nsf.gov/nsf9526.txt) article 734(d), while apparently not a formal part of the contract, goes into this matter in more detail, explaining that while the NSF allows grantees to retain the rights to intellectual property, this does not relieve them of a requirement to make available their data.

OMB 36(c) also contains the following provision:

"Unless waived by the Federal awarding agency, the Federal Government has the right to ... 1. Obtain, reproduce, publish or otherwise use the data first produced under an award."

In addition to the foregoing, Cooperative Agreement article 10(E) specifies that upon termination of the Cooperative Agreement, the NSF has the right to request, as part of the final report, a copy of the database:

The Awardee shall submit ... a final report to NSF at the conclusion of the Cooperative Agreement. The final report shall contain a description of all work performed and problems encountered (and if requested a copy and documentation of any and all software and data generated) in such form and sufficient detail as to permit replication of the work by a reasonably knowledgeable party or organization.

In responding to a FOIA request submitted by Corsearch in 1996 requesting a copy of the domain name database (NSF FOIA No. 96-090 Request (http://www.base.com/gordoni/thoughts/dns-control/nsf-foia-96-090-request.html, previously available at http://infolawalert.com/corsearch/request.html, currently inaccessible), the NSF claimed (NSF FOIA No. 96-090 Response (http://www.base.com/gordoni/thoughts/dns-control/nsf-foia-96-090-response.html, previously available at http://infolawalert.com/corsearch/denial.html, currently inaccessible):

"NSF does not possess or control the domain name database ..."

An administrative appeal of this decision was made (NSF FOIA No. 96-090 Appeal (http://www.base.com/gordoni/thoughts/dns-control/nsf-foia-96-090-appeal.html, previously available at http://infolawalert.com/corsearch/appeal.html, currently inaccessible). This appeal was rejected. "Possess" and "control" are used here in the context of the Freedom of Information Act to determine if the database is an "agency record", and not in respect of claims to ownership of intellectual property. These are the same terms used in the FLITE case (Baizer v. Department of the Air Force, 887 F. Supp. 225 (N.D. Cal. 1995), http://www.base.com/gordoni/thoughts/dns-control/legal/flite.txt). The FLITE decision has been criticized for its "broad assertion of an exemption from FOIA for 'library' materials, and its questionable use of legal precedent" ( Supreme Court Decisions in FLITE database, Information Policy Notes, Taxpayers Assets Project, http://www.essential.org/listproc/tap-info/0185.html). The Flite decision draws upon the Supreme Court decision in Department of Justice v. Tax Analysts, 492 US 136 (1989) (http://www.findlaw.com/scripts/getcase.pl?court=US&vol=492&invol=136).

The NSF has the right to obtain a copy of the database from Network Solutions, but because the NSF has not chosen to obtain the database, it is not possible to obtain the database from the NSF under the FOIA. Even if the NSF did have a copy of the database, it is not clear, in the light of the FLITE decision, whether the NSF would be required to make the database available under the FOIA.

In summary then, although Network Solutions might well own an intellectual property rights in the domain name database, for the duration of the contract, they are under an obligation to make the data contained in the database freely available to anyone that requests it. The NSF also has the right to obtain the database from Network Solutions, but is not required to do so under the FOIA.

5.5 Ownership of the Root Servers

As previously mentioned, because of a flaw in the way BIND operates, control over roughly half of the Internet name space results from control of a single IP address 198.41.0.4. This is probably not widely known.

Strictly speaking, "ownership" is not the correct term to use to describe the legal control of a network address. No form of intellectual property right for title in a network address exists. A registry of networks forming the Internet, and a designated contact person for each such network, is maintained by the Internet Registry. "Ownership" is simply the state of being the designated contact for a particular IP address. The Internet Registry assigns a set of IP addresses to each network in the registry. When faced with a request to route packets destined for a particular set of IP addresses to a particular machine, the operators of the routers that form the Internet all, purely by informal convention, follow the determination of the Internet Registry in deciding whether to do so. The operators of the routers choose to only implement the request if the person that made it is the designated contact for the network to which the requested IP address belongs.

IANA delegates administrative responsibility for the assignment of network numbers to the Internet Registry. As previously mentioned the Cooperative Agreement requires Network Solutions operate the Internet Registry for the duration of the contract. This is specified by Cooperative Agreement 3(C) which requires adherence to RFC 1174, which requires:

"The IR would continue to be the principal registry for all network and autonomous system numbers. It would also continue to maintain the list of root Domain Name System servers and a database of registered nets and autonomous systems."

To request a network address from the Internet Registry it is necessary to fill out the InterNIC : Internet Number Template (ftp://rs.internic.net/templates/internet-number-template.txt).

Information on the assignment of network addresses is available from the InterNIC:

These databases report 198.41.0.4 as having been assigned to Network Solutions on January 4, 1993. Two overlapping assignments for this address actually exist. In both cases the organization that will be using the network is listed as Network Solutions. For NETBLK-INTERNIC the technical point of contact / coordinator is listed as "Kosters, Mark A. (MAK21) markk@NETSOL.COM". For "INTERNIC-BLK1" the technical point of contact / coordinator is listed as "Network Solutions, Inc. (HOSTMASTER) hostmaster@INTERNIC.NET". According to DNS, the host names NS.INTERNIC.NET and A.ROOT-SERVERS.NET both map to 198.41.0.4. According to Whois, the domain INTERNIC.NET is assigned to Network Solutions, and the domain ROOT-SERVERS.NET is assigned to IANA, but administered by Network Solutions. Based on all of the above it seems fair to say 198.41.0.4 might be assigned to Network Solutions, but that there is a lot of confusion among the databases regarding whether it is assigned to Network Solutions itself, or it is assigned to Network Solutions in its role as the current provider of InterNIC Registration Services.

According to Awardee's Proposal Appendix B.1.3.1:

"The NREN NIS network will be segmented in much the same manner as the DISA NIC with a public segment with the NREN NIS host and new root DNS server and several other segments for internal NIS operations. The hosts attached to these private segments will be used for processing the registration and information data. ... Network Solutions will also utilize a SUN SPARC IPX to serve a root Domain server. This system will also be located on the public segment of our network."

This indicates that the provision of a root name server is a required part of the Cooperative Agreement. Until recently 198.41.0.4 was the sole root server provided by Network Solutions, and so this root name server must be the one Network Solutions is contractually required to provided. As a result, it is reasonable to assume that the request to obtain a network address for the root name server was performed by Network Solutions acting in its role as provider of InterNIC Registration Services. Consequently, on termination of the current contract, any new Internet Registry contractor would, as part of its role, be authorized to control this network address.

One of the things that complicates the issue, is 198.41.0.4 is not the only host on the 198.41.0 network. Using the Unix DIG application to query the 198.41.0 network, shows 184 hosts on the same class C network as 198.41.0.4 (Output of Unix command: "dig @noc.cerf.net 0.41.198.in-addr.arpa. axf", http://www.base.com/gordoni/thoughts/dns-control/confidential/dig-198.41.0.txt). Of these 184 hosts, 180 of them are in the internic.net domain, 3 are in the root-servers.net domain, and 1 is in the netsol.com domain. This tends to strengthen any claim that both the 198.41.0 network, and the 198.41.0.4 host, were acquired by, and are being operated by Network Solutions as part of its responsibilities in operating the Internet Registry.

Were a property right to exist in a network address, the situation would be different. OMB Circular No. A-110 would classify the network address as intangible property. According to OMB 36(d) title in the property would vest with the awardee. On termination of the contract, the property would be subject to disposition criteria in accordance with OMB 34(g).

One final note, according to RFC 2050: Internet Registry IP Allocation Guidelines (http://www.internic.net/rfc/rfc2050.txt) article 3.1:

"The IANA reserves the right to invalidate any IP assignments once it is determined the the [sic] requirement for the address space no longer exists."

However, the legal authority of this claim is open to question.

Summarizing this section, it appears a reasonable argument can be made that control of the key network address, 198.41.0.4, resides with the Internet Registry, but this is far from certain. It is possible Network Solutions has a valid legal claim to this network address. This address is key to control of DNS, which in turn is key to control over the entire Internet.

6. Summary of Important Findings

A brief summary of the key findings:

7. Public Policy Recommendations

The following actions are recommended to safeguard DNS:

8. Conclusion

Any party that gains control over DNS, will gain control over the entire Internet. Today, the possibility of monopoly control over DNS is a very real and immediate threat. It is therefore vital that public policy be implemented to ensure the continued public control of the Internet.

A. Appendices

Determination of the Root Name Servers in BIND

The BIND (http://www.vix.com/isc/bind.html) (Berkeley Internet Name Daemon) DNS implementation is the most widely used name server on the Internet today. It is very difficult to estimate, but perhaps somewhere in the range of 80-95% of all non-forwarding name servers are BIND based servers. BIND primarily runs on Unix hosts. Other, non-BIND based name servers include the newly introduced Microsoft Windows NT 4.0 DNS server, and QuickDNS on the Macintosh. The reason for the predominance of BIND is historical. Originally the Internet was very much a Unix based network, and the first systems connected to the Internet in most large organizations were Unix based systems. As the Internet has evolved, most organizations have added a large number of PCs to the Internet. However, it is still commonly a Unix based host, possibly straddling a firewall, that acts as the main name server for an organization.

When BIND starts it references a static file to locate the root name servers. This occurs whenever the name server machine is rebooted. According to Name Server Operations Guide for BIND Release 4.9.5 (http://www.base.com/gordoni/thoughts/dns-control/confidential/bind-4.9.5-P1/doc/bog/file.txt) section, 6.1.6 Cache Initialization:

"All cache files listed will be read in at named boot time and any values still valid will be reinstated in the cache. The root name server information in the cache files will be used until a root query is actually answered by one of the name servers in the cache file, after which that answer will be used instead of the cache file until the answer times out."

Thus, the first root name server contacted gets to specify which, if any, other root name servers are subsequently contacted. Therefore, the first root name server the client name server chooses to contact, has full control over the name space as subsequently seen by the client. The reason for this design is presumably so that name servers can be made to only contact the current root name servers. This overcomes problems associated with name servers operating with an out of date list of root name servers. This behavior appears to be a feature of BIND, rather than a requirement imposed by the DNS specification.

How does BIND decide which root name server to first contact? According to comp.protocols.tcp-ip.domains: Frequently Asked Questions (FAQ) (ftp://rtfm.mit.edu/pub/usenet/news.answers/internet/tcp-ip/domains-faq), question 2.21, Selecting a nameserver/root cache:

"Every recursive BIND name server (that is, one which is willing to go out and find something for you if you ask it something it doesn't know) will remember the measured round trip time to each server it sends queries to. If it has a choice of several servers for some domain (like "." for example) it will use the one whose measured RTT is lowest.

Since the measured RTT of all NS RRs starts at zero (0), every one gets tried one time. Once all have responded, all RTTs will be nonzero, and the "fastest server" will get all queries henceforth, until it slows down for some reason.

To promote dispersion and good recordkeeping, BIND will penalize the RTT by a little bit each time a server is reused, and it will penalize the RTT a _lot_ if it ever has to retransmit a query. For a server to stay "#1", it has to keep on answering quickly and consistently.

Note that this is something BIND does that the DNS Specification does not mention at all. So other servers, those not based on BIND, might behave very differently."

An examination of the BIND source code reveals the process through which BIND contacts the root name servers. When BIND is first started it invokes the prime_cache() routine. prime_cache() then invokes sysquery() to look up and download the name servers for the root domain. sysquery() is a general purpose routine for looking up name server and other records for a specified domain. sysquery() in turn first invokes findns() to obtain a list of name servers for the domain in question. Normally, this will be the list of root name servers returned by the first root name server contacted. For the very first query, findns() returns the list of root name servers read from the static "named.root" configuration file. Next, sysquery() invokes nslookup() to sort these name servers, and to return their IP addresses. In sorting this list, nslookup() invokes the Unix qsort() routine, ordering the name servers in accordance with their RTTs. sysquery() then attempts to contact the first name server in this list. For the call to sysquery() that was made by prime_cache(), sysquery() will request from the name server a list of servers for the root domain. When the root server returns this list, ns_req() will be invoked. ns_req() invokes ns_resp() to process the results. In BIND 4.8 and 4.9.3, ns_resp() invokes doupdate(). In BIND 4.9.5, ns_resp() invokes rrsetupdate(). Both doupdate() and rrsetupdate() invoke db_update() to save the returned list of root name servers for all future use.

Ultimately then, in determining the initial root name server to contact, BIND performs several simple actions. First, BIND reads the list of root name servers from its static configuration file. These candidate name servers are read into memory in the same order as they appear in the static configuration file. BIND then invokes the Unix qsort() routine upon this list. At the time qsort() is invoked none of the name servers have been contacted, and so each name server has an RTT of zero. BIND contacts the first candidate root name server from the sorted list. The list of root name servers returned by the chosen candidate root name server will then be used by BIND from then on.

The ordering returned by qsort() when sorting a list of elements all having the same value is intentionally undefined in Unix. Using a small specially created test program, qstest.c (http://www.base.com/gordoni/thoughts/dns-control/confidential/qstest.c), and in some cases also through examination of the relevant source code, the behavior of various different Unix qsort() routines in this situation was determined to be as follows:

Behavior of qsort() for Identical Items

Platform

First Element in Result

Source Code

SunOS 4.1.3, 4.1.4

Unchanged

 

Solaris 2.4, 2.5, 2.5.1

Unchanged

 

Linux 1.2.13 (libc 5.0.9), 2.0.28 (libc 5.3.12)

Unchanged

 

BSD Net 1 release, Net 2 release

Unchanged

Net 1 release qsort() routine (ftp://ftp.digital.com/ pub/BSD/net1/ src/lib/ libc/gen/qsort.c), Net 2 release qsort() routine (ftp://ftp.digital.com/ pub/BSD/net2/ lib/ libc/stdlib/qsort.c.Z).

NetBSD 1.1, NetBSD Current (1997-03-28), FreeBSD Current (1997-03-28)

Last element (for 8-12 elements; different if fewer)

NetBSD Current qsort() routine (ftp://ftp.digital.com/ pub/BSD/NetBSD/ NetBSD-current/src/lib/ libc/stdlib/qsort.c), FreeBSD Current qsort() routine (ftp://ftp.digital.com/ pub/BSD/FreeBSD/ FreeBSD-current/src/lib/ libc/stdlib/qsort.c).

AIX 3.2.5, 4.1.3

Second element

 

Digital Unix 2.0, 3.2, 4.0

Second element

 

HPUX 10.01, 10.10, 10.20

Second element

 

IRIX 4.0.5

Second element

 

IRIX 5.3, 6.2

Semi-random (last for 6-8 elements; 6th for 9; 7th for 10-11; 8th for 12)

 

The de facto dependence of BIND implementations on a single name server undoubtedly represents one of the most serious security flaws in the Internet today, and it destroys one of the significant advantages of having multiple root servers. Fortunately, not all Unix qsort() routines behave the same way, or the problem would be even more serious than it currently is. It is not known whether this design flaw is also present in other name servers, in particular the Windows NT 4.0 DNS server.

This behavior of BIND should be treated as highly confidential. Network Solutions might not currently be aware of it, and even if it is known by them, it might only be known as a technical glitch. The strategic ramifications may not have been thought through. Knowledge that just a few root name servers control the Internet name space, rather than nine root name servers controlled by different independent parties, significantly alters strategic goals, bargaining positions, and the overall effective balance of power.

Estimates as to Control over the DNS Name Space

The root name server BIND first contacts, specifies the root name servers BIND contacts from then on. The first contacted root name server thus has full control over the name space seen by BIND.

The name server BIND contacts first is determined by the behavior of the Unix qsort() routine. The effect of this depends on the relative popularity of different name server implementations. As previously mentioned, BIND is the most popular name server implementation today. BIND is also widely perceived as the name server implementation that most precisely adheres to the DNS specification. This is exemplified by RFC 2010: Operational Criteria for Root Name Servers (http://www.internic.net/rfc/rfc2010.txt), which mandates the use of BIND on root name servers. Consequently, as the size of an organization increases, so to does the likelihood that they will be using BIND as their main name server. Equally, as the size of an organization increases, so to does the likelihood that they will use Sun hardware for their main name server, because Sun systems have historically been seen as providing the de facto standard commercial implementation of TCP/IP. An example of this is in Awardee's Proposal Appendix B.1.3.1, in which Network Solutions specify the use of Sun hardware for the root name server they will operate under the terms of the Cooperative Agreement

It is difficult to gather even rough statistics on the relative popularity of different name server implementations. This is because it is not possible to query a DNS server to determine its implementation, and because this information is something that normally very few people would be interested in. Consequently all that can be done is to attempt to intelligently guess at this data. Best guess estimates as to the relative importance of different DNS implementations are presented below:

Best Guess Estimates as to the Popularity of Different DNS Implementations

DNS Implementation and Platform

Internet Connected Systems

DNS Servers

Non-forwarding DNS Servers

Large Organization Non-forwarding DNS Servers

Effective Weighted DNS Server Popularity

NT DNS NT/95/3.1/DOS

85%

20%

7%

3%

4%

Mac

10%

2%

1%

-

-

BIND SunOS/Solaris

1%

30%

35%

45%

43%

BIND AIX/Digital/HPUX

1%

20%

23%

24%

24%

BIND NetBSD/FreeBSD

1%

10%

15%

18%

17%

BIND IRIX

1%

8%

9%

9%

9%

BIND Linux

1%

10%

10%

1%

3%

Combining these estimates with previous findings on the behavior of BIND on different platforms, as well as InterNIC maintained lists of root name servers, leads to the following conclusions:

Best Guess Estimates as to Control over the DNS Name Space

Implementations

Initial Root Server Selection Criteria

IP Addresses

Owner

Proportion of Control

SunOS, Solaris, Linux

First listed name server.

198.41.0.4

InterNIC

46%

AIX, Digital, HPUX

Second listed name server.

128.9.0.17

ISI

24%

NetBSD, FreeBSD

Last listed name server.

192.36.148.17

NORDUnet

17%

IRIX

Sixth listed name server when the list contains nine name servers.

192.5.5.241, 39.13.229.241

ISOC

9%

NT

Unknown.

unknown

unknown

4%

It must be emphasized that the above are best guess estimates, and significant margins of error seem likely.

These estimates as to the control over the DNS name space should be treated as highly confidential.

Bibliography

In addition to the documents cited in the text, the following documents provide further additional background material relating to DNS:

Additional Research to be Performed

The following additional research should be performed:

Acknowledgments

Grateful acknowledgment is made of the assistance provided by:

Many, many, thanks!