Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 79
Signposts in Cyberspace: The Domain Name System and Internet Navigation 3 The Domain Name System: Current State The Domain Name System (DNS) in 2005 serves aglobal Internet far larger and more diverse, in users and in uses, than the relatively small homogeneous network for which it was first deployed in the early 1980s. To meet the needs of this expanded and enhanced Internet, the DNS has developed into a complex socio-technical-economic system comprising distributed name servers embedded in a multilayered institutional framework. This chapter describes the DNS as it exists in 2005 to establish a base for consideration of the future of the DNS and of navigation on the Internet. The chapter begins with an explanation of how the DNS responds to queries, illustrating the process with a query about the Internet Protocol (IP) address that corresponds to a particular domain name. It then describes the basic architecture of the DNS: its domain name space, its hierarchical structure, its basic programs, and its key standards and protocols. The core of the chapter is a description of the implementation of this architecture at three levels of the DNS hierarchy: the root, the top-level domains, and the second- and third-level domains. The distinctive characteristics of each level are examined first, followed by descriptions of the technical system and its institutional framework. The committee’s conclusions about the current performance of the DNS architecture and the implementation of each level are presented at the end of each section. Open issues affecting the future of the DNS are collected and analyzed in Chapters 4 and 5.
OCR for page 80
Signposts in Cyberspace: The Domain Name System and Internet Navigation Many of the contentious issues that arise in the context of the DNS concern domain names themselves—in particular, the definition of permissible names and the rights to their use. Some of those issues are introduced and discussed in Chapter 2. 3.1 OPERATION OF THE DOMAIN NAME SYSTEM1 Many things happen when a query to the DNS is initiated. If the DNS were a centralized database, such as HOSTS.TXT,2 every query would go directly to a central file where the answer would be found (or its absence noted). However, because the DNS is a hierarchical, distributed database, a search in response to a query generally requires several steps. If necessary, it can begin at the root and traverse a course through the tree of files to the one in which the sought-for answer resides. However, frequently the search can begin further down the tree because previous answers are stored and reused by the querying client. The design of the DNS ensures that the path down the tree will be followed without detours or false starts, leading directly to the desired file because the structure of the domain name spells out the route. This process may best be understood through an example, shown in Figure 3.1, which illustrates the use of the DNS to find the IP address corresponding to the hypothetical domain name indns.cstb.nas.edu.3 This is what would happen if, for example, the user wanted to access a Web site at that name, in which case the requesting application would be a browser. However, the same process would be followed for, say, an e-mail application or any other application supported by a host4 on the Internet. Two versions of the process are described below: first, the version shown in Figure 3.1, which would be followed if this were a new query from a computer that was not on the same DNS subtree as the cstb.nas.edu server; and then a version shortened by taking advantage of additional information from shared servers or previous queries. 1 This section elaborates on the high-level explanation in Chapter 2. It draws extensively on material in Paul Albitz and Cricket Liu, DNS and BIND, O’Reilly & Associates, Sebastopol, Calif., 2001. 2 HOSTS.TXT is the predecessor of the DNS and is described in Section 2.1. 3 The process shown in Figure 3.1 assumes that the querying client has stored no relevant previous answers. 4 A “host” is a network computer on which applications run providing services, such as computation or database access, to end users on the network.
OCR for page 81
Signposts in Cyberspace: The Domain Name System and Internet Navigation FIGURE 3.1 Operation of the Domain Name System without a local name server.
OCR for page 82
Signposts in Cyberspace: The Domain Name System and Internet Navigation 3.1.1 A New, Remote Query When a domain name is used in a Web browser, e-mail program, or otherwise, the applications program forms a request—a query. The example query, “What is the IP address corresponding to the domain name indns.cstb.nas.edu?,” goes first to a piece of software called a resolver. Resolver software is ordinarily incorporated as part of other software resident on the user’s computer5 or in a host to which it is linked. There are two kinds of resolvers: stub resolvers and iterative resolvers. Both types of resolver send queries to name servers (see below), but they differ in how the resolver selects the name servers to which it sends the query and how much of the work of answering the query is performed by the resolver. A name server is a computer running one of a small number of name-serving programs, the most common of which is the Berkeley Internet Name Domain (BIND) software.6 A stub resolver simply forwards the query to a local name server and awaits a reply. It places on the name server the burden of searching the DNS for the answer. An iterative resolver, in contrast, retains control of the search by using the answer from each successive name server to guide its search. This example assumes that the query comes from a stub resolver. Name servers are located throughout the Internet: at the root and the top-level domain registries, in organizations’ intranet infrastructures, and at Internet service providers (ISPs). Name servers can perform two important functions: First, they are designed to reply directly to queries concerning the portion of the domain name space for which they have complete information, which is called their zone and for which they are said to be authoritative (see Section 3.1.2). Second, they can, by incorporating an iterative resolver, reply to queries concerning zones for which they are not authoritative, obtaining information from other name servers in the DNS (described in this section). The incorporated iterative resolver will in almost all cases also contain a file or cache of answers obtained as a result of processing previous queries (see Section 3.1.3). In this case, the combination of name server and iterative resolver is said to be a caching or recursive name server. 5 For example, this is part of the Transmission Control Protocol/Internet Protocol (TCP/IP) stack in Microsoft Windows software, but some applications incorporate their own resolvers. Consequently, a computer may contain more than one resolver. 6 This name server program was originally written in 1983-1984 by a group of graduate students at the University of California, Berkeley, with funding from the Defense Advanced Research Projects Agency. Name servers are discussed further in Section 3.2.3.
OCR for page 83
Signposts in Cyberspace: The Domain Name System and Internet Navigation In practice, name servers with a heavy query demand or at the top levels of the DNS hierarchy are often configured to be authoritative only and not to offer caching/recursive services, except through a separate server. The name servers at ISPs, however, will offer caching/recursive services to their customers’ stub resolvers, but may not be authoritative for any domain. In Figure 3.1, the query is shown as going first to a name server offering recursive services located at the user’s ISP.7 Since in this example the iterative resolver incorporated into the ISP’s name server has not recently seen this query or any portion of it and the name server is not authoritative for any portion of the query, it sends the query on to the DNS root. It is able to find the root because the IP addresses of the name servers for the root, called the root hints data, were manually entered into a file on the computer, the hints file. Some systems automatically detect changes to the list of root name servers and make use of them, but the software never changes the file because to do so might eliminate the fallback in case of an attack that maliciously delivered an incorrect list. There are 13 root name servers (and many satellite copies of them)8 distributed around the world, and the querying name server will go to one chosen by an algorithm that, although differing among name server implementations, usually takes the shortest response time into account. The multiple computer copies of some of the 13 name servers employ a technology called “anycast” addressing (see Box 3.1). Although geographically distributed, each satellite is capable of responding to queries to the same IP address. If, for some reason, one root name server (or its closest satellite) does not respond, the iterative resolver will continue to try other servers according to its selection algorithm, and so on, until it receives a response. Similar behavior is common to all iterative resolvers at whatever level in the DNS hierarchy they are searching. The response of a root name server, which is configured to be authoritative only, takes the form: “The address of indns.cstb.nas.edu is not in my zone’s name file, but here are the names or addresses of name servers that are authoritative for .edu.” The ISP’s iterative resolver then sends the same query to one of the .edu name servers, which responds: “The address of indns.cstb.nas.edu is not in my zone’s name file, but here are the names or addresses of the name servers that are authoritative for nas.edu.” 7 Where a query goes first is a consequence of an explicit configuration choice made by the user, an ISP, an enterprise IT department, or by a dynamic configuration protocol whose values are supplied by one of those sources. 8 See Table 3.1 for a listing of the 13 root name servers and their base and satellite locations. See Box 3.1 for a description of satellite servers.
OCR for page 84
Signposts in Cyberspace: The Domain Name System and Internet Navigation BOX 3.1 Anycast Addressing Anycast addresses, a special type of Internet Protocol (IP) address, were invented in the early 1990s to simplify the process of finding replicated services (i.e., services that are provided by multiple and identical servers).1 Some of the operators of root name servers have implemented anycast addressing as a way to facilitate load sharing, to improve service, and to reduce vulnerability to attacks. The use of anycast addresses allows a root name server operator to install copies of the root zone file at different servers (in this report, those servers that replicate the root zone file are called satellites). Properly configured and located, each of the satellites will get a share of the traffic for the root name server. Although the shares will, in most cases, not be equal, the load of queries will be distributed and thus relieve the load burden on the root name server. Satellites that are located at the same physical site are using local anycast addressing, also known as load balancing, which is widely deployed among the root name server operators. From the user’s perspective, the great advantage derived from the adoption of anycast addressing is improved service. The satellites are typically placed at topologically diverse locations in the Internet. Queries can therefore be answered more swiftly. An additional benefit is that the DNS queries use, in the aggregate, fewer network resources, because servers will tend to be “closer” on the network to the sources of the queries. The use of anycast addressing can sharply reduce the impact of an attack on a root name server: In the short run, physically disabling a root name server does not affect the operation of its satellites, and physically disabling a satellite disables only that satellite. In the long run, there is the question of how satellites would obtain updated root zone information. It is also much harder to mount an effective electronic attack—because queries are routed to the closest satellite (or the root name server itself, if it is the closest). An attacker would need to place (or acquire) machines close to The ISP’s resolver then queries one of the nas.edu name servers, which refers it to a cstb.nas.edu name server, which is authoritative for the requested domain name and replies with the corresponding IP address. 3.1.2 Local Query A name server can answer many queries quickly when these queries request the address of a domain name for which the name server is authoritative. This is often the case, for example, for name servers on organizational intranets, where most of the requests are for IP addresses of other computers on the intranet. In such a case, the name server can respond to the query without going to the larger DNS, simply by looking up the an-
OCR for page 85
Signposts in Cyberspace: The Domain Name System and Internet Navigation each of the satellites and the root name server if the attacker wished to disable all access to the service.2 A single attacking machine might disable the closest server—whether a satellite or the root name server itself. The other servers would be affected only in a minimal way, through a slightly increased load if one server were rendered inoperative. Therefore, the adoption of anycast addressing by the root name server operators is a positive development. However, more general use of anycast addressing is problematic because current methods for deploying these addresses waste a number of IP addresses.3 Given the importance of a robust DNS, this wastage is acceptable for the operation of the root name servers, but not necessarily for other domain name servers. Monitoring the performance of satellites presents root name server operators with a difficult problem. Such monitoring involves the placement of monitoring devices within the part of the Internet that each satellite serves and can represent a significant logistical challenge because the satellites may be widely dispersed. 1 The initial motivation for the creation of anycast addressing was to reduce the need manually to configure information about basic services such as DNS resolvers. The basic idea is that a “host transmits a datagram [a data packet carrying its own address information so it can be independently routed from its source to the destination computer] to an anycast address and the internetwork [Internet] is responsible for providing best effort delivery of the datagram to at least one, and preferably only one, of the servers that accept datagrams for the anycast address.” See Craig Partridge, Trevor Mendez, and Walter Milliken, “Host Anycasting Service,” Request for Comments (RFC) 1546, November 1993, available at <http://www.rfc-editor.org>. See Box 3.3 for an explanation of RFCs. All RFCs are available at <http://www.rfc-editor.org>. 2 And even then other root name servers and their satellites would be accessible. 3 As of April 2004, anycast addresses were not fully supported in the current version of IP (version 4). In particular, the Border Gateway Protocol (BGP; the cross-provider routing protocol) was not designed to accommodate anycast addresses and, therefore, a workaround is used that wastes about 256 IP addresses for each root name server that employs anycast addressing. swer in its local database. For example, if the local name server in the previous example was authoritative for cstb.nas.edu, it could provide the response directly. 3.1.3 Repeat Query A caching name server can answer many other queries quickly when it has responded previously to queries that were identical or matched at a higher level of the tree. (For example, in 2005 virtually every caching name server is highly likely to have cached the IP address for www.google.com.) It maintains those answers in a cache of information containing the addresses of name servers (and other data) it has previ-
OCR for page 86
Signposts in Cyberspace: The Domain Name System and Internet Navigation ously obtained. Before going to the root, it searches its cache to find the known name servers closest (in the DNS hierarchy) to the domain being sought. For example, if the ISP’s caching name server in the previous example were to receive a query for the address of tdd.cstb.nas.edu, it would check to see if it already knew the address of the name server authoritative for cstb.nas.edu. If it did, its iterative resolver would send the query directly to that server, shortening the path that must be taken to obtain an authoritative response. If it did not, it would then check to see if it had the address of the name server authoritative for nas.edu, and finally .edu. Only if it had none of those addresses would it go to the root. This property of caching—that it limits the number of queries that are sent to the root name server—has been crucial to the manageability of the growth in the query load on the root system. If all DNS queries were to start at a root name server, the capacity of the root system (as a whole) would have to be of an entirely different magnitude, posing more formidable technical and economic challenges as a consequence. The Internet and the many services on it are subject to constant, sometimes rapid change. As a result, cached information can become outdated. To reduce that problem, the administrator of each zone assigns a time to live (TTL) to each datum that it sends out in reply to a query. After the corresponding amount of time has passed, the name server is expected to eliminate the datum from its cache. Often a name server will receive information that a domain name being sought does not exist. That can happen because the query is ill formed, contains a typographical error, is based on a user’s incorrect guess about a desired domain name, refers to a name that does not exist or no longer exists, or refers to a domain name on a private network that is not on the public DNS.9 Since such inquiries do not correspond to a cached address, even the caching name server system will not normally relieve the load on the root name servers related to such requests. To minimize the load on the network and improve response time, however, it is desirable that name servers store information about such non-existent domains. That practice is referred to as negative caching (as introduced in Section 2.3.1). The need to assign a TTL also applies to negative caching, since a previously non-existent domain may come into existence and would be missed if the negative cache did not eliminate responses regularly. 9 A significant portion of queries to the root name servers are ill formed or in error according to studies by researchers. See, for example, Duane Wessels and Marina Fomenkov, “Wow, That’s a Lot of Packets,” Proceedings of Passive and Active Measurement Workshop, 2003, available at <http://www.caida.org/outreach/papers/2003/dnspackets/>.
OCR for page 87
Signposts in Cyberspace: The Domain Name System and Internet Navigation 3.2 ARCHITECTURE OF THE DOMAIN NAME SYSTEM The architecture of the DNS—its conceptual design—comprises its name space, its hierarchical structure, and the software that specifies operations within that name space and structure.10 The software comprises two components: programs, which implement the resolver and name server functions on various computers; and technical standards, which define the formats of the communication between the programs, as well as the logical structure11 of the files in a name server. 3.2.1 Name Space The name space for domain names is the set of all symbol strings that adhere to the rules for forming domain names specified in the design of the DNS. Those rules define a standard format that imposes a tree structure on the name space. Each node on the tree has a label, which consists of 1 to 63 characters drawn from a restricted subset of ASCII12 comprising the 26 letters of the Roman alphabet, the 10 numerals from 0 to 9, and the hyphen. Labels may not begin or end with a hyphen.13 The fully qualified domain name of a node is the list of the labels on the path from the node to the root of the tree written with the deepest node on the left and with those to the right getting successively closer to the root. In external presentation form, the labels are separated by dots (.). By convention, the root label has null length and is written as a dot (.), but its presence is optional. Thus, “www.nas.edu.” (with a trailing dot) and “www.nas.edu” (without a trailing a dot) are equivalent domain names. The total length of a domain name must be less than 256 characters. Each node on the tree (including the leaves) corresponds to a collection of data, which may be empty at the internal nodes, unless they constitute a delegation point. The data are represented by resource records, which are described in Box 3.2 in Section 3.2.4. 3.2.2 Hierarchical Structure The hierarchical, tree structure of the DNS facilitates both an efficient response to queries and the effective decentralization of responsibility for 10 The evolution of the DNS is described in Chapter 2. 11 They will be stored in whatever data structures the local database software requires. 12 American National Standards Institute, “USA Code for Information Interchange,” X3.4, 1968. 13 The limitation to the 37 ASCII characters is not a strict requirement of domain names but results from the constraints placed on domain names by other protocols.
OCR for page 88
Signposts in Cyberspace: The Domain Name System and Internet Navigation its maintenance and operation. That is accomplished through the division of a domain into subdomains, which taken together need not directly include all of the hosts in the domain. The responsibilities for maintaining the name files for some or all of the subdomains can then be delegated to different organizations. They, in turn, can further divide and delegate, a process that can be repeated as often as necessary. The parent domain need only retain pointers to the subdomains so that it can refer queries appropriately. The hierarchical delegation of responsibility is one of the great strengths of the DNS architecture. It is up to the organization responsible for a zone to maintain the corresponding zone file (thus, the organization has considerable motivation to provide satisfactory maintenance)—the data file in the zone’s name servers that contains pointers to hosts in the zone and to the name servers for delegated zones (see “DNS Zone Data File” in Section 3.2.4). The work of keeping the DNS current is, thereby, distributed to organizations throughout the entire DNS tree, down to the lowest leaves. Instead of a central organization being responsible for keeping the DNS data current and accurate, which would have been an impossible task, there are millions of organizations and individuals across the globe doing the work. Figure 3.2 illustrates the delegation of responsibility from the root to the .edu domain, whose name servers are said to be authoritative for the .edu zone. The .edu domain in turn delegates responsibility, in this limited illustration, for the subdomains to three universities—the University of California at Los Angeles (UCLA), Southern Methodist University (SMU), and the Massachusetts Institute of Technology (MIT), whose name servers are authoritative for their corresponding zones—ucla.edu, smu.edu, and mit.edu. In Figure 3.2 the MIT subdomain is further delegated to two departments for illustrative purposes—Sloan School and Electrical Engineering and Computer Science, whose name servers are authoritative for their zones—sloancf.mit.edu and eecs.mit.edu. Note that in the example, the mit.edu zone includes a pointer directly to a host—web.mit.edu—in addition to pointers to the delegated zones. This distribution of responsibility, combined with the distributed handling of tasks by the technology, is why the DNS scales, or handles growth so well. 3.2.3 Programs: BIND and Others The DNS requires only two types of programs to operate within the context of the existing Internet. First, there must be resolver software. The resolver, recall from Section 3.1, is a client that accepts a query, passes the query to a name server, interprets the response, and returns the response to the source of the query. Generally, resolvers are just a set of library routines within a name server, a browser, or an operating system.
OCR for page 89
Signposts in Cyberspace: The Domain Name System and Internet Navigation FIGURE 3.2 The .edu domain divided into zones. SOURCE: Based on Figures 2-8 and 2-9 of Paul Albitz and Cricket Liu, DNS and BIND, 4th edition, O’Reilly Media, Sebastopol, Calif., 2001.
OCR for page 141
Signposts in Cyberspace: The Domain Name System and Internet Navigation evident. This was especially true for .com at first, and then for .net and .org as they were more widely marketed to general users. For the reasons described in Section 2.5.1, they were the most visible names on signposts on the Web. Possible Remedies to Conflicts Over Names There are basically two approaches to resolving conflicts over rights to names: one approach incorporates policies and regulations into the actual administration of the naming system and its assignment rules. The other approach relies on dispute resolution mechanisms that are external to naming system administration. Internal Remedies. In a completely internalized naming system administration, a single manager owns the naming system and decides who is entitled to which name. Hence there are no rights conflicts. Public or quasi-public naming systems, such as the DNS, can also attempt to link the assignment of names to strict policies and regulations. The available techniques include imposing policies on the assignment of names at the point of registration, name reservations94 or exclusion, and so-called sunrise proposals. Policies Imposed at the Point of Registration. Such policies must rely on rules or procedures to determine eligibility for a name. It is difficult to mechanize such rules. Thus, prior review of registration is likely to be expensive and slow if it is administered manually and prone to be crude and unfair if it is not. Name Exclusions. Name exclusions withdraw specific names or entire classes of names from the available database. For a time, Network Solutions did not allow registration of six of the Federal Communication Commission’s “seven dirty words” in the domain name space.95 The World Intellectual Property Organization (WIPO) recommended eliminating a list of “famous” trademarks from the DNS database and reserving their use to the trademark holder.96 ICANN has provided all of its 94 The deployment of internationalized domain names involves new processes and challenges with respect to the reservation of names to prevent some conflicts over domain names. See Section 5.6.3 for discussion. 95 For example, see “Seven Dirty Words,” Wikipedia online encyclopedia, available at <http://en.wikipedia.org/wiki/Seven_dirty_words>. 96 See “The Problem of Notoriety: Famous and Well-Known Marks,” in The Mangement of Internet Names and Addresses: Intellectual Property Issues, First Report of WIPO Internet Domain Name Process, April 30, 1999, available at <http://wipo2.wipo.int/process1/rfc/3/interim2_ch4.html>.
OCR for page 142
Signposts in Cyberspace: The Domain Name System and Internet Navigation newly authorized registries with a list of reserved names that consisted of names and acronyms of organizations related to the IETF and ICANN.97 Name exclusion is an effective method of protecting the reserved names from abuse, but it is also a crude instrument, and in a global, public name space its crudeness raises significant public policy concerns. With-drawing words from circulation is in effect a form of automated censorship. Exclusions do not make any distinction between legitimate and illegitimate users; they simply make it impossible to use the names. A rigid exclusion deprives these organizations of the right to register domain names corresponding to their acronyms or trademarks. Exclusions and other regulations are less significant when they are part of the practice of a private naming system, where the owner can be assumed to have property rights over the naming system as a whole. Such exclusions also ignore the fact that certain words have a particular meaning only in a particular language. A “dirty” word in English may have no such meaning in another language. Sunrise Proposals. Sunrise proposals, in general, establish a period at the start-up of a new name space within the DNS during which certain entities may register names in which they have established rights (e.g., famous trademarks) before the space is opened for public registration. External Remedies. External methods of resolving rights conflicts include litigation through the courts or alternative dispute resolution procedures, such as the ICANN Uniform Domain Name Dispute Resolution Policy (UDRP), which is discussed below. The advantage of these methods is that they are based on case-specific analysis. Thus, they are sensitive to the specific facts of the conflict and can employ “soft” interpretive principles to adjudicate a dispute. Their disadvantage, of course, is that they are more time-consuming and expensive, and litigation is subject to jurisdictional limitations that may not match the scope of the affected naming system. Litigation is particularly expensive and cumbersome, although it offers a reliably neutral tribunal in many countries. Alternative dispute resolution techniques such as the UDRP greatly reduce the cost of external dispute resolution but sacrifice thoroughness in compiling and verifying facts, and their rapid procedures can put respondents at a disadvantage. 97 For the list of reserved names, see ICANN, “Appendix K, Schedule of Reserved Names,” available at <http://www.icann.org/tlds/agreements/unsponsored/registry-agmt-appk26apr01.htm>.
OCR for page 143
Signposts in Cyberspace: The Domain Name System and Internet Navigation Remedies to Conflicts Over Names in the DNS Since the remedies to domain name conflicts differ somewhat between the gTLDs and the ccTLDs, each is described separately below. gTLDs. Although there are other uses of trademarks with international spillover effects, second-level domains in gTLDs are unusual in the extent to which they are visible in almost every jurisdiction in the world, with the resulting difficulty in making either geographic or sectoral distinctions. Ordinarily, the same trademarks can be used in a single geographic region so long as they are in different economic sectors where confusion is unlikely. On the Internet such distinctions cannot be made. As a result, the question arises as to the means to be used to make decisions about domain name conflicts and disputes that cross national and business sector boundaries and, since such decisions inevitably involve matters of commercial or political or social importance, to ensure that those decisions are regarded as legitimate and enforced. Normally, trademark and related disputes are resolved by the courts of the nation in which they arise, and those in many nations have shown themselves capable of handling domain name disputes. In addition, the United States has passed specific legislation at both the federal and the state levels addressing the rights of trademark owners to domain names. (These are discussed further below.) As noted above, however, legal proceedings can become expensive and time-consuming. Therefore, many in the Internet community felt the need for a less expensive and quicker means of resolving domain name disputes. Uniform Domain Name Dispute Resolution Policy. An answer, implemented by ICANN in December 1999, based on a recommendation from WIPO, was the Uniform Domain Name Dispute Resolution Policy. The UDRP has been adopted, as ICANN requires, by all registrars in the .aero, .biz, .com, .coop, .info, .museum, .name, .net, and .org top-level domains, as well as voluntarily by managers of several global ccTLDs, such as .tv, .cc, and .ws. In addition, managers of other ccTLDs, such as .ca, have adopted their own policies based on modified versions of the UDRP. The policy takes effect through agreements between registrars (or other registration authorities) and their registrants. Each registrant agrees to be bound by the provisions of the policy when it registers its domain name.98 In agreeing to the registration agreement, the registrant also must 98 The policy conditions, examples of bad-faith actions, and other provisions listed below are paraphrased from the UDRP text available at <http://www.icann.org/dndr/udrp/policy.htm>.
OCR for page 144
Signposts in Cyberspace: The Domain Name System and Internet Navigation represent that to its knowledge its registration of the domain name does not infringe any third party’s rights, nor is it for an unlawful purpose, nor will it be used in violation of any applicable laws or regulations. By registering the domain name, the registrant is then bound by the policy to submit to a mandatory administrative proceeding if a complainant asserts that: Registrant’s domain name is identical or confusingly similar to a trademark or service mark in which the complainant has rights; and Registrant has no rights or legitimate interests in respect of the domain name; and Registrant’s domain name has been registered and is being used in bad faith. The complainant must demonstrate all three of these conditions for the complainant to prevail. The policy asserts examples of actions that would demonstrate bad faith that include registering and using the domain name: For the purpose of transferring the registration to the complainant, or to one of its competitors, for more than the documented out-of-pocket costs of the domain name; or To prevent the owner of the trademark or service mark from using the mark in a domain name (provided that registrant engaged in a pattern of such conduct); or Primarily for the purpose of disrupting the business of a competitor; or Intentionally to attract, for commercial gain, Internet users to registrant’s Web site or other online location, by creating a likelihood of confusion with the complainant’s mark on registrant’s Web site or location. It also describes circumstances that would enable the registrant to demonstrate its rights and legitimate interests in the domain name. These are as follows: Before any notice to registrant of the dispute, its use of, or demonstrable preparations to use, the domain name or a name corresponding to the domain name in connection with a bona fide offering of goods or services; or Registrant has been commonly known by the domain name, even if it has acquired no trademark or service mark rights; or
OCR for page 145
Signposts in Cyberspace: The Domain Name System and Internet Navigation Registrant is making a legitimate noncommercial or fair use of the domain name, without intent for commercial gain, to misleadingly divert consumers, or to tarnish the trademark or service mark. The mandatory proceeding—which is electronically based—must be held before an accredited and administrative-dispute-resolution provider that has been approved by ICANN.99 The complainant selects the provider and is required to pay the fees, except in the case when the registrant elects to expand the panel from one to three panelists, in which case the fee is split. The registrar, the registry, and ICANN are not parties to a UDRP proceeding. However, during a UDRP proceeding, the registrar does confirm that the domain name has been registered by the respondent named in the proceeding and is required to execute the outcome of a decision. The only remedy available to the complainant through the proceeding is cancellation or transfer of the domain name. As of May 10, 2004, 9377 proceedings involving 15,710 domain names had been brought under the UDRP.100 Two-thirds (6262) of these proceedings had resulted in a transfer of the disputed domain name to the complainant or in a cancellation of the domain name. Approximately one-fifth (1892) had resulted in a decision for the respondent, and approximately one-tenth (971) of the proceedings had been disposed without decision or terminated. There were 931 proceedings pending. The 15,710 domain names that had been disputed in 4 years represent 0.03 percent of the more than 46 million domain names registered in the gTLDs subject to the UDRP. Approximately 60 percent of these proceedings have been filed with WIPO, approximately 33 percent have been filed with the National Arbitration Forum (NAF), approximately 6 percent were filed with eResolution,101 and approximately 0.7 percent have been filed with the Center for Public Resources Institute for Dispute Resolution (CPR). The Asian Domain Name Dispute Resolution Centre (ADNDRC) began operation in February 2002. 99 The approved providers are listed at <http://www.icann.org/dndr/udrp/approvedproviders.htm>. There were four approved providers in February 2005. 100 ICANN, “Statistical Summary of Proceedings Under Uniform Domain Name Dispute Resolution Policy,” January 30, 2004; latest version available at <http://www.icann.org/udrp/proceedings-stat.htm>. 101 eResolution ceased operating as a dispute-resolution provider for ICANN in late November 2001.
OCR for page 146
Signposts in Cyberspace: The Domain Name System and Internet Navigation FIGURE 3.3 UDRP filings as of April 30, 2004. NOTE: With respect to gTLD UDRP filings commencing during the period from December 1999 through October 2003, data were obtained from the ICANN Web site at <http://www.icann.org/udrp/proceedings-list.htm>. With respect to such filings commencing during the period from November 2003 through April 2004, data were obtained directly from the Asian Domain Name Dispute Resolution Centre Web sites at <http://www.adndrc.org/adndrc/bj_home.html> and <http://www.adndrc.org/adndrc/hk_home.html>, the Center for Public Resources Institute for Dispute Resolution Web site at <http://www.cpradr.org/ICANN_Cases.htm>, the National Arbitration Forum Web site at <http://www.arb-forum.com/domains/decisions.asp>, and the World Intellectual Property Organization Arbitration and Mediation Center Web site at <http://arbiter.wipo.int/domains/statistics/index.html>. Specialized domain name dispute resolution proceedings (e.g., Start-up Trademark Opposition Policy (STOP) and the usTLD Domain Name Dispute Resolution Policy (USDRP)) have been excluded from these statistics. Over time, there has been a decline in the number of UDRP proceedings filed. As shown in Figure 3.3, the number of UDRP proceedings filed each month has been steadily decreasing since August 2000. WIPO explained this decline as suggesting that “an expedited online dispute resolution service has been effective in dissuading Internet pirates from hijacking names.”102 It may also be partly the conse- 102 WIPO, “WIPO Continues Efforts to Curb Cybersquatting,” Press Release PR/2002/303, February 26, 2002, available at <http://www.wipo.org/pressroom/en/releases/2002/p303.htm>.
OCR for page 147
Signposts in Cyberspace: The Domain Name System and Internet Navigation quence of working through the backlog of cases that UDRP faced upon start-up and entering a more normal steady-state condition. To some extent, as well, it may reflect a change in the attitudes of trademark owners, some of whom may have come to feel that their interests are not jeopardized by every similar domain name, which are not worth the cost and effort to maintain. The decline in cases might also be attributed, in part, to learning by cybersquatters about avoiding a finding of bad faith against them. As a first step in a policy development process, in 2003, ICANN prepared a report that lists many of the procedural and substantive issues that have been raised about the UDRP.103 Start-up Registrations. The UDRP was designed to handle an ongoing rate of domain name conflicts arising in already established gTLDs. However, several of the seven new gTLDs have faced unique issues when they entered the start-up phase. Specifically, under the terms of their contracts with ICANN, they needed a process by which intellectual property rights holders could challenge bad-faith claimants in advance of open registration in order to avoid a rush of cybersquatters followed by a heavy demand on the UDRP process as intellectual property holders asserted their rights. The four most significant—.biz, .info, .name, and .pro—each adopted somewhat different policies, but all are adopting or have a UDRP-like dispute resolution policy. ccTLDs. Most ccTLD registries, and their agents and registrars when they exist, publish policies about who is eligible to register in the second-level domain, or in its third-level domains when they are open for direct registration. These policies generally also cover the resolution of conflicts over domain names. Where the TLD limits itself to individuals and organizations that have an association with the country, many potential conflicts are readily addressed through national administrative, regulatory, and judicial institutions. For example, matters of trademark priority are handled through the national regulatory and legal systems, and corporations may have defensible rights only in the names that are legally registered. 103 See ICANN, “Staff Manager’s Issues Report on UDRP Review,” August 1, 2003, available at <http://www.icann.org/gnso/issue-reports/udrp-review-report-01aug03.htm>. ICANN also set up a committee to consider WIPO’s proposed amendments to the UDRP. ICANN has not made the committee’s report public.
OCR for page 148
Signposts in Cyberspace: The Domain Name System and Internet Navigation U.S. Legislation. The United States has passed legislation at both the federal and the state levels addressing the rights of trademark owners to domain names. Federal—The ACPA: On November 29, 1999, President Clinton signed into law the Anti-cybersquatting Consumer Protection Act (ACPA), which provided trademark owners with a further cause of action that was specifically directed to domain names.104 Under the ACPA, a trademark owner can bring a civil action against a person if that person has a bad-faith intent to profit from a mark and registers, traffics in, or uses a domain name that, in the case of a mark that is distinctive, is identical or confusingly similar to that mark; or in the case of a famous mark, is identical or confusingly similar to or dilutive of that mark; or is a trademark, word, or name protected by law.105 Mere registration of such a domain in bad faith may be sufficient to violate the trademark owner’s rights under the ACPA; there is no further requirement for any use of the domain name in association with any goods or services. Under the ACPA, factors affecting the judgment of bad faith include, but are not limited to, whether (1) the registrant holds any intellectual property rights in the name; (2) the domain name consists of the registrant’s name; (3) the domain name was used in connection with the bona fide offering of any goods or services; (4) the domain name was used in a way that could be viewed as a bona fide noncommercial or fair use; (5) the domain name was intended to divert consumers from the mark owner’s online location; (6) the registrant offered to sell the domain name to the mark owner without having used it in a bona fide manner; (7) the registrant provided false contact information in the registration form; (8) the registrant acquired multiple domain names that are identical or similar to the trademarks of others; and (9) the domain name incorporates a mark that is not distinctive and famous. The ACPA also created a cause of action for individuals with respect to domain names. Specifically, a domain name registrant can be held liable if the domain name consists of, or is substantially and confusingly similar to, the name of another living person and the domain name has been registered without that person’s consent with the specific intent to profit from the name by selling it for financial gain. This particular cause of action, however, is not available for domain name registrations that occurred prior to the ACPA’s enactment date. With respect to remedies, the ACPA provided that a court may award injunctive relief, including forfeiture, cancellation, or transfer of the do- 104 15 U.S.C. § 1125(d). 105 18 U.S.C. § 706 (“Red Cross”) or 36 U.S.C. § 220506 (“Olympic”).
OCR for page 149
Signposts in Cyberspace: The Domain Name System and Internet Navigation main name. In addition, if the registration, trafficking, or use of the domain name occurred after the ACPA’s enactment date, a plaintiff can elect to recover, instead of actual damages and profits, an award of statutory damages in the amount of $1,000 to $100,000 per domain name (as the court considers just). Furthermore, if personal jurisdiction over the domain name registrant cannot be obtained, the trademark owner could file an in rem civil action106 against the domain name itself in the judicial district of the domain name registrar, domain name registry, or other domain name authority that registered or assigned the domain name. However, the ACPA limits the remedies in an in rem action to forfeiture, cancellation, or transfer of the domain name. States: California, Hawaii, and Louisiana also passed laws that address the registration, sale, and use of domain names within that state and provide for civil remedies in state courts for violations of these laws. Foreign Legislation. Relatively few countries have chosen to address the rights of trademark holders in domain names in the same legislative manner as the United States. The European Union (EU) has relied largely on new telecommunications laws coordinated at the EU level to provide for the regulation of domain names at the national level. For example, in Spain, the General Telecommunications Act (1998) was modified in July 2001 to impose a number of conditions on the registration of domain names under the ccTLD .es, including a requirement that a domain name to be registered be somehow related to the trademark or name of the company undertaking the registration. In other countries, the judicial process, rather than the legislative process, has been relied on to address conflicts between domain names and trademarks. Since at least 1997, courts within the United Kingdom have been prohibiting the registration of domain names that conflict with trademarks. In 1998, the Delhi High Court in India likewise extended its form of common law trademark protection to domain names, as did the Tribunal de Grande Instance of Draguignan in France. Many ccTLDs, 42 in all, including a number from the EU, have opted to rely on a form of alternative dispute resolution policy.107 Likewise, the new .eu ccTLD will apply the following rules regarding registrations: Governments may reserve geographical and geopolitical names. In a 4-month sunrise phase, “prior rights” holders and public bodies can register .eu domain names before the general public can do so. 106 An in rem action is taken against property directly, in contrast to an action against people (e.g., the owners of a given piece of property). 107 See <http://arbiter.wipo.int/domains/cctld/index.html> for an example.
OCR for page 150
Signposts in Cyberspace: The Domain Name System and Internet Navigation Two months before the sunrise phase starts, technical and administrative measures will be published in detail. In the first 2 months of the sunrise phase, registered national and European Community trademarks and geographical indications as well as names and acronyms of public bodies can be registered as .eu domain names by the holder/public body. Two months later, other “prior rights” holders can also register .eu domain names, but only as far as they are protected under national law in the member state where they are held. This provision concerns unregistered trademarks, trade names, business identifiers, company names, family names, and distinctive titles of protected literary and artistic works. There will be an alternative dispute resolution procedure in place (similar to ICANN’s “Uniform Domain Name Dispute Resolution Policy” UDRP). After the sunrise phase, the domain names will be registered according to the first-come, first served-principle. 3.5.3 Assessment Conclusion: The tens of millions of registered second- and third-level domains are operated by individuals with a broad spectrum of capabilities. It is notable that the DNS has been able to function effectively and reliably despite this range of operator capabilities. Conclusion: The UDRP is a unique cross-border, electronically based process that has resolved thousands of disputes over domain names without the expense and potential delay of court proceedings. The issues of dispute resolution and appropriate Whois balance are examined in Chapter 5, where the alternative approaches are described and the committee’s recommendations presented. 3.6 SUMMARY Conclusion: The domain name technical system reliably and effectively handles the billions of queries it receives every day. The institutions that manage it perform the required functions adequately, in many cases without direct compensation. Conclusion: The DNS technical system can continue to meet the needs of an expanding Internet. Early in the committee’s assessment it became apparent that it would not be fruitful to consider alternate naming systems. As noted, the DNS operates quite well for its intended purpose and
OCR for page 151
Signposts in Cyberspace: The Domain Name System and Internet Navigation has demonstrated its ability to scale with the growth of the Internet and to operate robustly in an open environment. Moreover, significantly increased functionality can be achieved though applications—such as navigation systems—built on the DNS, or offered independently, rather than through changing the DNS directly. Hence, the need did not seem to be to replace the DNS but rather to maintain and incrementally improve it. Furthermore, given the rapidly increasing installed base and the corresponding heavy investments in the technical system and the institutional framework, the financial cost and operational disruption of changing to a replacement for the DNS would be extremely high, if even possible at all. Yet, despite this better than passing grade, the committee’s assessments have identified a number of significant technical and institutional issues whose effective resolution is critical to the DNS’s successful adaptation to the demands on it. Chapters 4 and 5 address those issues.
Representative terms from entire chapter: