Prepublication Copy--Subject to Further Editorial Correction
Signposts in Cyberspace:
The Domain Name System and Internet Navigation
Committee on Internet Navigation and the Domain Name System:
Technical Alternatives and Policy Implications
Computer Science and Telecommunications Board
Division on Engineering and Physical Sciences
NATIONAL ACADEMIES PRESS
Washington, D.C.
www.nap.edu
Prepublication Copy--Subject to Further Editorial Correction
THE NATIONAL ACADEMIES PRESS 500 Fifth Street, N.W. Washington, D.C. 20001
NOTICE: The project that is the subject of this report was approved by the Governing Board of the
National Research Council, whose members are drawn from the councils of the National Academy of
Sciences, the National Academy of Engineering, and the Institute of Medicine. The members of the
committee responsible for the report were chosen for their special competences and with regard for
appropriate balance.
Support for this project was provided by the U.S. Department of Commerce and the National Science
Foundation under Grant No. ANI-9909852 and by the National Research Council. Any opinions,
findings, conclusions, or recommendations expressed in this publication are those of the authors and do
not necessarily reflect the views of the National Science Foundation or the Commerce Department.
International Standard Book Number
Cover designed by Jennifer M. Bishop.
Copies of this report are available from the National Academies Press, 500 Fifth Street, N.W., Lockbox
285, Washington, D.C. 20055, (800) 624-6242 or (202) 334-3313 in the Washington metropolitan area.
Internet, http://www.nap.edu
Copyright 2005 by the National Academy of Sciences. All rights reserved.
Printed in the United States of America
Prepublication Copy--Subject to Further Editorial Correction
The National Academy of Sciences is a private, nonprofit, self-perpetuating society of distinguished scholars
engaged in scientific and engineering research, dedicated to the furtherance of science and technology and to their
use for the general welfare. Upon the authority of the charter granted to it by the Congress in 1863, the Academy has
a mandate that requires it to advise the federal government on scientific and technical matters. Dr. Bruce M. Alberts
is president of the National Academy of Sciences.
The National Academy of Engineering was established in 1964, under the charter of the National Academy of
Sciences, as a parallel organization of outstanding engineers. It is autonomous in its administration and in the
selection of its members, sharing with the National Academy of Sciences the responsibility for advising the federal
government. The National Academy of Engineering also sponsors engineering programs aimed at meeting national
needs, encourages education and research, and recognizes the superior achievements of engineers. Dr. Wm. A. Wulf
is president of the National Academy of Engineering.
The Institute of Medicine was established in 1970 by the National Academy of Sciences to secure the services of
eminent members of appropriate professions in the examination of policy matters pertaining to the health of the
public. The Institute acts under the responsibility given to the National Academy of Sciences by its congressional
charter to be an adviser to the federal government and, upon its own initiative, to identify issues of medical care,
research, and education. Dr. Harvey V. Fineberg is president of the Institute of Medicine.
The National Research Council was organized by the National Academy of Sciences in 1916 to associate the broad
community of science and technology with the Academy's purposes of furthering knowledge and advising the
federal government. Functioning in accordance with general policies determined by the Academy, the Council has
become the principal operating agency of both the National Academy of Sciences and the National Academy of
Engineering in providing services to the government, the public, and the scientific and engineering communities.
The Council is administered jointly by both Academies and the Institute of Medicine. Dr. Bruce M. Alberts and Dr.
Wm. A. Wulf are chair and vice chair, respectively, of the National Research Council.
www.national-academies.org
Prepublication Copy--Subject to Further Editorial Correction
Prepublication Copy--Subject to Further Editorial Correction
COMMITTEE ON INTERNET NAVIGATION AND THE DOMAIN NAME SYSTEM:
TECHNICAL ALTERNATIVES AND POLICY IMPLICATIONS
ROGER LEVIEN, Strategy & Innovation Consulting, Chair
S. ROBERT AUSTEIN, Internet Systems Consortium
STANLEY M. BESEN, Charles River Associates
CHRISTINE L. BORGMAN, University of California, Los Angeles
TIMOTHY CASEY, University of Nevada
HUGH DUBBERLY, Dubberly Design Office
PATRIK FÄLTSTRÖM, Cisco Systems
PER-KRISTIAN HALVORSEN, Hewlett-Packard Labs
MARYLEE JENKINS, Arent Fox Kintner Plotkin & Kahn, PLLC
JOHN C. KLENSIN, Independent Consultant
MILTON L. MUELLER, Syracuse University
SHARON NELSON, Washington State Attorney General's Office
CRAIG PARTRIDGE, BBN Technologies
WILLIAM RADUCHEL, Ruckus Network
HAL R. VARIAN, University of California, Berkeley
Staff
ALAN S. INOUYE, Study Director
CHARLES BROWNSTEIN, Director
MARJORY S. BLUMENTHAL, Director (through June 2003)
MARGARET MARSH HUYNH, Senior Program Assistant
KRISTEN BATCH, Research Associate
v
Prepublication Copy--Subject to Further Editorial Correction
COMPUTER SCIENCE AND TELECOMMUNICATIONS BOARD
DAVID E. LIDDLE, U.S. Venture Partners, Co-Chair
JEANNETTE M. WING, Carnegie Mellon University, Co-Chair
ERIC BENHAMOU, Benhamou Global Ventures, LLC
DAVID D. CLARK, Massachusetts Institute of Technology, CSTB Chair Emeritus
WILLIAM DALLY, Stanford University
MARK E. DEAN, IBM Almaden Research Center
DEBORAH ESTRIN, University of California, Los Angeles
JOAN FEIGENBAUM, Yale University
HECTOR GARCIA-MOLINA, Stanford University
KEVIN KAHN, Intel Corporation
JAMES KAJIYA, Microsoft Corporation
MICHAEL KATZ, University of California, Berkeley
RANDY H. KATZ, University of California, Berkeley
WENDY A. KELLOGG, IBM T.J. Watson Research Center
SARA KIESLER, Carnegie Mellon University
BUTLER W. LAMPSON, Microsoft Corporation, CSTB Member Emeritus
TERESA H. MENG, Stanford University
TOM M. MITCHELL, Carnegie Mellon University
DANIEL PIKE, GCI Cable and Entertainment
ERIC SCHMIDT, Google Inc.
FRED B. SCHNEIDER, Cornell University
WILLIAM STEAD, Vanderbilt University
ANDREW J. VITERBI, Viterbi Group, LLC
CHARLES N. BROWNSTEIN, Director
KRISTEN BATCH, Research Associate
JENNIFER M. BISHOP, Program Associate
JANET BRISCOE, Manager, Program Operations
JON EISENBERG, Senior Program Officer
RENEE HAWKINS, Financial Associate
MARGARET MARSH HUYNH, Senior Program Assistant
HERBERT S. LIN, Senior Scientist
LYNETTE I. MILLETT, Senior Program Officer
JANICE SABUDA, Senior Program Assistant
GLORIA WESTBROOK, Senior Program Assistant
BRANDYE WILLIAMS, Staff Assistant
For more information on CSTB, see its Web site at <http://www.cstb.org>, write to CSTB,
National Research Council, 500 Fifth Street, N.W., Washington, DC 20001, call (202) 334-2605,
or e-mail the CSTB at cstb@nas.edu.
vi
Prepublication Copy--Subject to Further Editorial Correction
Preface
The Domain Name System (DNS), which was developed in the early 1980s, provides a way of
associating alphanumeric names, which are easier for humans to use, with the numerical addresses that
designate every location on the Internet. The system of DNS servers distributed across the Internet
invisibly converts the names--serving as signposts in cyberspace--into the numerical addresses required
by network routers to reach the signposted locations.
The mnemonic quality of domain names became a practical necessity when the rapid increase in
the use of e-mail and the World Wide Web (Web) caused the number of Internet users and uses to
increase tremendously. Web sites often became known to their visitors by their distinctive domain
names--for example, pepsi.com or whitehouse.gov. Carefully chosen domain names often
enabled a searcher to navigate to a site simply by guessing (e.g., www.un.org). Consequently, those
signposts gained economic, social, cultural, and political value and they became the objects of pride,
competition, and dispute. It was fitting, therefore, that the DNS also provided the name--the "Dot Com
Era"--for the period of the 1990s when "gold rush fever" drove frenzied efforts to stake out and exploit
virtually every potentially valuable site on the Web. Inevitably, such efforts led to intense conflicts,
especially disputes involving trademarks, which provided the impetus for the 1998 congressional mandate
to initiate this study (see Box P.1). However, the passage of time, the rapid evolution of the Internet and
the DNS, the additional and differing interests of the funding agencies, and the logic of the committee's
charter have resulted in a report whose scope differs in some respects from the original congressional
request, but is as a result more responsive to the current interests of the report's sponsors and audience.
CURRENT CONTEXT AND STUDY TASK
Although the initial feverish period of Internet exploitation appears to have passed, in its third
decade the DNS will face new challenges arising from continued growth in the size and scope of the
Internet and from its increasing integration into almost every aspect of human activity almost everywhere
on the globe. The Internet will need more signposts, in more languages, to satisfy more uses and users.
And the DNS will have to be carefully developed and managed to ensure that it can meet those needs
while continuing to provide reliable, efficient, and secure service.
Furthermore, even if the DNS successfully adapts and grows, users of the Internet will confront
new challenges in reaching the resources that they are seeking on the Internet, whether they are
educational, social, political, cultural, commercial, or recreational. The challenges will arise not from the
absence of resources or of signposts for them, but from their presence in such volume and variety that
navigating through the maze to find the right ones may become too arduous or too complex for most
users. Reciprocally, those who put resources on the Internet will want to be easily found by their
prospective users in the cluttered bazaar of competing or confusing resources and signposts on the
Internet. Thus, the larger issue of the third decade of the DNS is that of navigation through the Internet--
the need for its users to find their way quickly and confidently to the resources they desire and for its
resources to be easily and reliably found by the users they seek.
This study builds on CSTB's prior work related to the Internet, most notably on The Internet's
Coming of Age and The Digital Dilemma.1 One of the important lessons from this prior work is that
contentious issues in information technology policy (e.g., the domain name trademark issues as described
1 See Computer Science and Telecommunications Board (CSTB), National Research Council (NRC), 2001, The
Internet's Coming of Age, Washington, D.C.: National Academy Press; and CSTB, NRC, 2000, The Digital
Dilemma: Intellectual Property in the Information Age, Washington, D.C.: National Academy Press.
vii
Prepublication Copy--Subject to Further Editorial Correction
BOX P.1
Excerpt from Public Law 105-305
SEC. 6. STUDY OF EFFECTS ON TRADEMARK RIGHTS OF
ADDING GENERIC TOP-LEVEL DOMAINS
(b) Matters To Be Assessed in Study.--The study shall assess and, as appropriate, make recommendations for policy,
practice, or legislative changes relating to
(1) the short-term and long-term effects on the protection of trademark rights and consumer interests of increasing or
decreasing the number of generic top-level domains;
(2) trademark rights clearance processes for domain names, including
(A) whether domain name databases should be readily searchable through a common interface to facilitate the
clearing of trademark rights and proposed domain names across a range of generic top-level domains;
(B) the identification of what information from domain name databases should be accessible for the clearing of
trademark rights; and
(C) whether generic top-level domain registrants should be required to provide certain information;
(3) domain name trademark rights dispute resolution mechanisms, including how to--
(A) reduce trademark rights conflicts associated with the addition of any new generic top-level domains; and
(B) reduce trademark rights conflicts through new technical approaches to Internet addressing;
(4) choice of law or jurisdiction for resolution of trademark rights disputes relating to domain names, including
which jurisdictions should be available for trademark rights owners to file suit to protect such trademark rights;
(5) trademark rights infringement liability for registrars, registries, or technical management bodies;
(6) short-term and long-term technical and policy options for Internet addressing schemes and the impact of such
options on current trademark rights issues; and
(7) public comments on the interim report and on any reports that are issued by intergovernmental bodies.
in Public Law 105-305) are often much more complex and require analysis in a much larger context than
a popular characterization of "us versus them" would suggest. In the interval between the enactment of
Public Law 105-305 and the initiation of this study, CSTB was able to conduct preliminary background
work to develop a statement of task (see Box P.2) that addresses the congressional mandate but also
ensures that the necessary larger context is included explicitly. Moreover, the larger context was
necessary to respond appropriately to the interests of the National Science Foundation, which joined with
the U.S. Department of Commerce as co-sponsors of this study.
COMMITTEE COMPOSITION AND PROCESS
The CSTB convened a cross-disciplinary study committee comprising computer scientists and
engineers, information science/retrieval and navigation experts, lawyers, public policy analysts, a graphic
designer, economists, and business strategists. Many but not all of the members were directly engaged
with the DNS or with Internet navigation (see Appendix A for the biographies of committee members).
The committee members brought different and complementary perspectives to the examination of the
DNS and Internet navigation. In some cases, they also held views that strongly conflicted with those of
other committee members. The conclusions reached and the recommendations developed by the
committee are thus the products of a multidimensional examination of the issues and a careful negotiation
of agreements among members holding contrasting opinions. The sharp discussions and e-mail threads
fueled by the committee's diversity of experience and opinion helped it to avoid overly simple
conclusions or recommendations reflecting just one perspective. Information gathering, discussion,
argument, negotiation, and compromise were the stages the committee passed through in addressing most
of the topics.
viii
Prepublication Copy--Subject to Further Editorial Correction
BOX P.2
Statement of Task
This project will examine the future of Internet navigation and the Domain Name System (DNS)
in light of the evolution and interaction of Internet usage, information technology, the economy, and
society. The original purpose of the DNS was to provide identifiers for network objects that are more
easily remembered and enduring than the numerical addresses and port numbers used by the network
infrastructure. However, domain names are now often used for purposes for which they were not
originally intended, such as searching, corporate identification, and marketing. And certain domain
names, especially those in the .com top-level domain, have acquired substantial economic value, leading
to conflict and competition over their ownership and a perceived scarcity of desirable names.
The continuing increase in the number of Internet users and sites, the deepening integration of the
Internet into the economy and social processes, the growth in embedded computing devices, and the
possible introduction of permanent personal and object identifiers--among other factors--pose
challenges to the continued viability and usefulness of the DNS, as currently constituted. This project
will describe and evaluate emerging technologies and identify how they might affect the ability of users to
find what they are seeking on the Internet and the role of the DNS. Some of the topics to be considered
include extension of the DNS through the addition of generic top-level domains and multilingual domain
names; introduction of new name assignment and indexing schemes (including alternate root servers);
adoption of new directory structures or services for locating information resources, services, or sites of
interest; and deployment of improved user interfaces.
The technologies that support finding information on the Internet are deployed within a complex
and contentious national and international policy context. The "right" to use a particular domain name,
like any name, can often be disputed. These disputes include conflicts among commercial claimants as
well as conflicts between non-commercial and commercial claimants. Effective solutions must consider
the potentially competing interests of domain name registrants and trademark holders; the different
interests of stakeholders including businesses, from small firms to multinational corporations;
educational, arts, and research institutions; not-for-profit charitable and service organizations; government
entities at all levels from town to nation; nation-states and international organizations; and individuals
(i.e., the general public); as well as public interests such as freedom of speech and personal privacy.
The project's report will examine the degree to which the options offered by new technology or
new uses of existing technology can mitigate concerns regarding commercial and public interests (which
will include a discussion of trademark-related issues), facilitate or impede further evolution of the
Internet, and affect steps being taken to enhance competition among domain name registrars, the
portability of Internet names, and the stability of the Internet. For each of the prospective technologies,
the final report is expected to characterize the institutions, governance structures, policies, and procedures
that should be put in place to complement it and will specify the research (if any) required to design,
develop, and implement the technology successfully. Also identified will be the options foregone or
created by particular technologies and the difficulties associated with each technological alternative.
The committee did its work through its own deliberations and by soliciting input from a number
of other experts (see Appendix B for a list of those who briefed the committee) and from the international
public through an open invitation published on the Web.2 It first met in April 2001 and six times
subsequently in plenary session. Additional information was derived from reviewing the published
literature, monitoring selected listservs and Web sites, and obtaining informal input at various
conferences and other meetings. Committee members and National Research Council (NRC) staff made
2 See The Future Of Internet Navigation And The Domain Name System, "An Invitation to Individuals Worldwide
to Provide Input to a Study Conducted by the U.S. National Academy of Sciences." Available at:
<http://www7.nationalacademies.org/cstb/project_dns_input.html>.
ix
Prepublication Copy--Subject to Further Editorial Correction
several site visits, which included participation in meetings of the Internet Corporation for Assigned
Names and Numbers (ICANN), the Internet Engineering Task Force, and the World Summit on the
Information Society. Significant input was also derived from committee members during the course of
their professional activities outside of the committee's work. During the editorial phase of the study, facts
were checked for accuracy with either published sources or subject experts.
At the outset of the study, some conflict and controversy were expected, given the intense debate
about the DNS and its associated institutions such as the ICANN and the rapidly growing interest in the
use of commercially sponsored navigation services. We were not disappointed. However, the committee
was able to achieve consensus in a number of areas as described in the main text. Moreover, the
committee believes that this report represents a contribution to future discussions related to the DNS by
serving as a reference document containing much of the basic, relevant technical and institutional
background material and many of the policy alternatives in as clear and objective a manner as possible.
A number of committee members withdrew from the committee for various reasons. In a few
instances, new employment or professional opportunities raised conflict-of-interest concerns. Several
committee members were simply unable to participate in the committee's work because of increased
professional or personal obligations.
Although the report refers to several companies, products, and services by name, such reference
does not constitute an endorsement by the committee or the National Academies.
ACKNOWLEDGMENTS
The committee appreciates the support and guidance of its sponsors. The committee's initial
contacts at the U.S. Department of Commerce were J. Beckwith Burr, Amy Page, and Karen Rose; in the
latter portion of the study, Cathy Handley and Robin Layton represented the Department. Aubrey Bush
and George Strawn were the committee's initial contacts at the National Science Foundation, with
Darleen Fisher assuming this role during the final months of the project. The committee also appreciates
the financial support of CSTB's core sponsors: the Air Force Office of Scientific Research, Cisco
Systems, the Defense Advanced Research Projects Agency, Department of Energy, Intel Corporation,
Microsoft Research, National Aeronautics and Space Administration, National Institute of Standards and
Technology, National Library of Medicine, National Science Foundation, and Office of Naval Research.
Additional financial support was provided by the National Academies.
In addition, we would like to thank those individuals who provided valuable inputs into the
committee's deliberations. Those who briefed the committee at one of our plenary meetings are listed in
Appendix B. Others who provided us with important inputs include Ronald Andruff (RNA Partners,
Inc.), Carl Bildt (AG Global Solutions and ICANN At-Large Study Committee), Mason Cole
(SnapNames), Shari Garmise (Cleveland State University), Carolyn T. Hoover (dotCoop), Cary Karp
(MuseDoma), Kalpana Shankar (University of California, Los Angeles), Paul Twomey (Internet
Corporation for Assigned Names and Numbers), Anastasia Zhadina (Robin, Blecker & Daley), and
Matthew Zook (University of Kentucky). We would also like to acknowledge those organizations that
hosted committee meetings: AOL Time Warner, Inc.; University of California, Berkeley; University of
California, Los Angeles; Harvard University; and VeriSign, Inc.
The committee appreciates the thoughtful comments received from the reviewers of this report
and the efforts of the NRC's report review coordinator and monitor. The review draft stimulated a
comparatively large volume of comments, each of which was taken into account during revision of the
draft. Many of the comments provided additional reference material, relevant anecdotes, and additional
observations to bolster or counter the committee's earlier thinking. In sum, the comments were
instrumental in helping the committee to sharpen and improve the report. However, the reviewers' are not
responsible for the report's conclusions or recommendations, with which some of them may disagree, or
for its structure and specific content. Those are solely the committee's responsibility.
x
Prepublication Copy--Subject to Further Editorial Correction
Finally, the committee would like to acknowledge the staff of the NRC for their work. Alan
Inouye served as the study director with overall staff responsibility for the conduct of the study and the
development of this final report. Margaret Marsh Huynh had primary responsibility for the administrative
aspects of the project such as organizing meeting logistics. Marjory Blumenthal, as director of CSTB,
and her successor, Charles Brownstein, provided the committee with valuable administrative and
technical guidance. Cynthia Patterson and Kristen Batch provided research and writing support for
various stages of the report drafting and revising process. The committee acknowledges the valuable
contribution of Susan Maurizi of the NRC's editorial staff. The committee would also like to thank Janet
Briscoe and Renee Hawkins of the CSTB staff, Liz Panos of the staff of the Division on Engineering and
Physical Sciences, and Janice Mehler of the Report Review Committee for their support of the
committee's work.
Roger Levien, Chair
Committee on Internet Navigation and the
Domain Name System
xi
Prepublication Copy--Subject to Further Editorial Correction
Acknowledgment of Reviewers
This report has been reviewed in draft form by individuals chosen for their diverse perspectives
and technical expertise, in accordance with procedures approved by the National Research Council's
Report Review Committee. The purpose of this independent review is to provide candid and critical
comments that will assist the institution in making its published report as sound as possible and to ensure
that the report meets institutional standards for objectivity, evidence, and responsiveness to the study
charge. The review comments and draft manuscript remain confidential to protect the integrity of the
deliberative process. We wish to thank the following individuals for their review of this report:
Aristotle Balogh, VeriSign, Inc.
Timothy Bray, Textuality
J. Beckwith Burr, Wilmer, Cutler & Pickering
kc claffy, Cooperative Association for Internet Data Analysis
David Clark, Massachusetts Institute of Technology
Steve Crocker, Shinkuro, Inc.
Bruce Croft, University of Massachusetts, Amherst
Leslie Daigle, VeriSign, Inc.
Graeme Dinwoodie, Chicago-Kent College of Law
Joseph Farrell, University of California, Berkeley
Michael Froomkin, University of Miami
Hector Garcia-Molina, Stanford University
Marti Hearst, University of California, Berkeley
Randy Katz, University of California, Berkeley
Butler Lampson, Microsoft Corporation
F. Thomson Leighton, Akamai Technologies and the Massachusetts Institute of Technology
Michael Lesk, Rutgers University
Lars-Johan Liman, Autonomica
Clifford Lynch, Coalition for Networked Information
M. Stuart Lynn, Independent Consultant
Tom Mitchell, Carnegie Mellon University
Ivan Png, National University of Singapore
Fred Schneider, Cornell University
Paul Vixie, PAIX.net, Inc.
Tan Tin Wee, National University of Singapore
Although the reviewers listed above have provided many constructive comments and suggestions,
they were not asked to endorse the conclusions or recommendations, nor did they see the final draft of the
report before its release. The review of this report was overseen by Alexander H. Flax, independent
consultant, and Joseph Bannister, University of Southern California. Appointed by the National Research
Council, they were responsible for making certain that an independent examination of this report was
carried out in accordance with institutional procedures and that all review comments were carefully
considered. Responsibility for the final content of this report rests entirely with the authoring committee
and the institution.
xii
Prepublication Copy--Subject to Further Editorial Correction
Contents
EXECUTIVE SUMMARY
1
1 INTRODUCTION
1-1
1.1
The
Internet
1.2 The Domain Name System
1.3
Internet
Navigation
1.4 The Dynamics of Change
1.4.1 Increasing
Scale
1.4.2
Technological
Progress
1.4.3
Increasing
Economic
Value
1.4.4
Increasing
Social
Value
1.4.5
Internationalization
1.5 Internet Naming and Navigation
1.6 Objectives of This Report
1.7 Roadmap for This Report
2 THE EMERGENCE AND EVOLUTION OF THE DOMAIN NAME SYSTEM
2-1
2.1 Origin of the Domain Name System
2.2 Designing the Domain Name System
2.2.1 Simple, Mnemonic, and Deeply Hierarchical Names
2.2.2
Experimental
Features
2.3 Deploying the Domain Name System
2.3.1
Caching
2.3.2
Lookup
Timeouts
2.3.3 Convergence in Electronic Mail Systems
2.3.4
The
Whois
Database
2.3.5 The DNS as a Production System
2.4 Continuing Growth and Evolution of the Internet As a Technical Infrastructure
2.5 Economic and Social Value of Domain Names
2.5.1 Demand for Domain Names and Emergence of a Market
2.5.2 The Rise of Conflicts Over Domain Names
Trademark
Conflicts
Beyond
Trademark
Conflicts
Beyond
Second-Level
Domain
Names
2.5.3
Whois
2.6
Globalization
2.7 Administration of Domain Names
3 THE DOMAIN NAME SYSTEM: CURRENT STATE
3-1
3.1 Operation of the Domain Name System
3.1.1 A New, Remote Query
3.1.2
Local
Query
3.1.3
Repeat
Query
3.2 Architecture of the Domain Name System
3.2.1
Name
Space
xiii
Prepublication Copy--Subject to Further Editorial Correction
3.2.2
Hierarchical
Structure
3.2.3 Programs: BIND and Others
3.2.4
Standards
DNS
Zone
Data
File
DNS
Message
Format
3.2.5
Functions
and
Institutions
Maintenance of DNS Standards--The Internet Engineering Task Force
Providing Root Name Server Software--Internet Software Consortium, Inc. and
Other Software Providers
3.2.6
Assessment
3.3 Implementation--The Domain Name System Root Zone
3.3.1 Characteristics of the Root Zone
Defining
Characteristics
Critical
Characteristics
Unique
Characteristics
3.3.2 Technical System of the Root Zone
The
Root
Zone
File
The
Root
Name
Servers
3.3.3 Institutional Framework of the Root Zone
Approving the Root Zone File-- U.S. Department of Commerce and ICANN
Maintaining the Root Zone File--VeriSign
Selecting the Root Name Server Operators--Self Selection
Operating the Root Name Servers--The Root Name Server Operators
3.3.4
Assessment
3.4 Implementation--The Top-Level Domains
3.4.1 Characteristics of the TLDS
ccTLDS
gTLDS
Recharacterizing TLDs
3.4.2 Technical System of the TLDs
3.4.3 Institutional Framework of the TLDs
Selecting new TLDs
Selecting the Organizations Responsible for the TLDs
Selecting the TLD Registry Operators
Operating the TLD Registries
3.4.4
Assessment
3.5 Implementation--The Second- and Third-Level Domains
3.5.1 Technical System of the Second- and Third-Level Domains
3.5.2
Institutional
Framework
of
the Second- and Third-Level Domains
Selecting the Organizations to Register Domains
Registering Domain Names
Resolving Domain Name Conflicts
3.5.3
Assessment
3.6
Summary
4 THE DOMAIN NAME SYSTEM: TECHNOLOGY PROSPECTS
4-1
4.1
Introduction
4.2 Improving Security of the Domain Name System--DNSSEC
4.2.1
Mechanics
of
DNSSEC
4.2.2
Deployment
of
DNSSEC
4.3 Linking the Telephone and Internet Naming System--ENUM
xiv
Prepublication Copy--Subject to Further Editorial Correction
4.3.1 Mechanics and Operations of ENUM
4.3.2 Technical and Public Policy Issues
4.3.3
Alternate
Models
4.4
Internationalized
Domain
Names--IDNs
4.4.1 Internationalizing Domain Names in Applications
Client-Side Support
4.4.2
Registries
and
Registrars
4.4.3 Chinese, Japanese, and Korean Scripts
4.4.4
Conclusions
4.5 Responding to Domain Name Errors--Aggregation and Site Finder
4.5.1
Traffic
Aggregation
4.5.2 Site Finder by VeriSign
Technical Issues
4.5.3
Conclusions
5 THE DOMAIN NAME SYSTEM: INSTITUTIONAL ISSUES
5-1
5.1 Governance of the Domain Name System
5.1.1 Relationship to Governance of the Internet
5.1.2 Where Should Stewardship of the DNS Reside?
5.1.3
Alternatives
Alternative A: Existing Intergovernmental Organization--International
Telecommunication Union
Alternative B: International Treaty Organization
Alternative C: Private Organization with International Participation
5.2 Management of the Domain Name System
5.2.1 Scope of ICANN's Authority
5.2.2 Composition of the ICANN Board
5.2.3 Nature of ICANN's Management Processes
5.2.4
Alternatives
Alternative A: Markle Foundation Proposal (2002)
Alternative B: Non-governmental Organization and Academic ICANN Study
Proposal (2001)
Alternative C: ICANN as Registry for the Root (2004)
Alternative D: New.net Proposal--ICANN as a Private Trade Association (2002)
Alternative E: Center for Democracy and Technology Proposal--Narrowed Scope
with Broad Participation (2004)
Alternative F: Reformed ICANN--Narrowed Scope with Broad Participation
(2003)
Summary of the Alternatives
5.2.5
Conclusions
and
Recommendations
5.3 Oversight and Operation of Root Name Servers
5.3.1 Current Situation: Diverse Autonomy
Description
Evaluation
5.3.2
Alternatives
Alternative A: Funding and Regulation
Alternative B: Competitive Market
Alternative C: Distributed Root Zone File
Alternative D: DOC Relaxes MoU Requirement
Summary of the Alternatives
5.3.3 Conclusions and Recommendations
xv
Prepublication Copy--Subject to Further Editorial Correction
5.4 Regulation of Generic Top-Level Domains
5.4.1 Should New gTLDs Be Added? If So, How Many New gTLDs and How Fast?
Technical and Operational Performance Issues
User Needs and Economic Issues
Recommendations
5.4.2 If New gTLDs Are to Be Added, What Types Should They Be and How Should
They and Their Operators Be Selected?
Which Types of gTLDs Should Be Added?
How Should the Operators of gTLDS Be Selected?
What Selection Process Should Be Used?
5.4.3
Recommendations
5.5 Oversight of Country Code Top-Level Domains
5.5.1
Current
Situation
5.5.2
Alternatives
Alternative A: "Thick" ICANN
Alternative B: "Thin" ICANN
Alternative C: International Oversight
Alternative D: Self-governing Root Management Organization
Comparison of the Four Alternatives
5.5.3
Conclusions
5.6 Resolution of Conflicts Over Domain Names
5.6.1 Assessment of the UDRP
5.6.2 Proposed Improvements to the UDRP
5.6.3 Disputes Concerning Internationalized Domain Names
5.7 Provision and Protection of Whois Data
5.7.1 Assessment of Whois Data Issues
Data
Accuracy
Data
Privacy
5.7.2 Whois and Internationalized Domain Names
5.7.3 Conclusions and Recommendations
6 INTERNET NAVIGATION: EMERGENCE AND EVOLUTION
6-1
6.1 The Nature of Internet Navigation
6.1.1 Vast and Varied Resources for Multiple Purposes
6.1.2
Two-sided
Process
6.1.3 Complexity and Diversity of Uses, Users, and Providers
6.1.4 Lack of Human Intermediaries
6.1.5 Democratization of Information Access and Provision
6.1.6 Lack of Context or Lack of Skill
6.1.7
Lack
of
Persistence
6.1.8
Scale
6.1.9 The Sum of the Differences
6.2 Internet Navigation Aids and Services--History
6.2.1 Aiding Navigation via the Internet
6.2.2 Aiding Navigation Through the World Wide Web
6.3 Addendum--Searching the Web Versus Searching Libraries
7 INTERNET NAVIGATION: CURRENT STATE
7-1
7.1 Navigation Aids and Services
7.1.1 Direct Access via a Uniform Resource Locator or Domain Name
7.1.2 Direct Access via Hyperlinks
xvi
Prepublication Copy--Subject to Further Editorial Correction
7.1.3 Direct Access via Bookmarks
7.1.4 Direct Access via KEYWORDS
7.1.5 Direct Access via Metadata
7.1.6 Navigation via Directory Systems
7.1.7 Navigation via Search Engines
Algorithmic Search
Monetized Search
Search Engine Marketing and Optimization
The Deep, Dark, or Invisible Web
Metasearch Engines
7.1.8 Use of Navigation Aids
7.2 Internet Navigation--Institutional Framework
7.2.1 The Commercial Providers of Navigation Services
7.2.2 The Business of Internet Navigation
7.2.3 The Navigation Services Market
Consolidation
Innovation
8 INTERNET NAVIGATION: SELECTED PROSPECTS AND ISSUES
8-1
8.1
Technological
Prospects
8.1.1 Navigation Service Algorithms and Operations
8.1.2
Navigation
Interfaces
8.1.3 Navigation to Audio and Visual Materials
8.1.4 Making Greater Use of Contextual Information
8.1.5
Improving
Persistence
8.1.6
Understanding
User
Behavior
8.2
Institutional
Issues
8.2.1
Regulation
8.2.2
Privacy
8.2.3
Trademarks
and
Copyright
Trademark
Copyright
9 THE DOMAIN NAME SYSTEM AND INTERNET NAVIGATION
9-1
APPENDIXES
A Biographies of Committee Members, A-1
B Speakers and Participants at Meetings and Site Visits, B-1
xvii
Prepublication Copy--Subject to Further Editorial Correction
Executive Summary
Most of the Internet's users rely on the Domain Name System (DNS) and navigation aids or
services to find the resources they seek or to attract users to the resources they provide. Yet, although they
perform well, both the DNS and Internet navigation services face challenges arising from technological
change and from institutions with a wide variety of commercial, cultural, social, and political agendas.
Individually, or together, those pressures could force operational changes that would significantly reduce
access to Internet-linked resources by segments of the user community, reducing the Internet's value as a
global resource.
This document reports the conclusions of an assessment of the current state and the future
prospects of the DNS and its interactions with Internet navigation, including its uses as a means of
navigation itself and as an infrastructure for navigation by other means. The assessment is the result of the
deliberations of a committee that encompasses a wide range of disciplines, experience, and viewpoints.
The report is addressed to the technologists, policy makers, and others whose decisions will affect the
future of the DNS and Internet navigation aids and services. The specific conclusions and
recommendations of the Committee on Internet Navigation and the Domain Name System appear
throughout this summary in boldface type.
DOMAIN NAME SYSTEM
Domain names are commonly used to designate services and devices on the Internet, as a more
memorable and more permanent alternative to the numerical addresses employed by its routing
computers. They are the valued, often valuable, and often user-friendly names on the signposts that
designate many things connected to the Internet. Consequently, which names are available, who controls
their allocation, what is charged for their use, how their uses are managed, and the answers to many
related questions are important to virtually everyone who uses the Internet, whether as information seeker
or provider.
Overall, the DNS's technical system and institutional framework have performed reliably
and effectively during the two decades of the DNS's existence. The DNS has coped with the extremely
rapid expansion of Internet usage driven by the wide deployment of the World Wide Web in the 1990s
and the widespread adoption of e-mail. The hierarchical, distributed structure of the DNS technical
system, operated collaboratively by a group of mostly autonomous organizations, has proven to be
scalable, reliable, secure, and efficient.
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 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
replacing the DNS would be extremely high, if even possible at all.
However, the continued successful operation of the DNS is not assured; many forces, driven
by a variety of factors, are challenging the DNS's future. Required and desirable technologies to
ES-1
Prepublication Copy--Subject to Further Editorial Correction
increase security and enable the use of non-Roman scripts for domain names are not being incorporated
into the technical system as quickly as many would like. There are persistent and substantial controversies
concerning the structure and policies of the DNS's institutional framework. Moreover, there have been
many efforts to use the DNS, because it exists and is so widely deployed, for many purposes for which it
may not be appropriate. In addition, national legislation and court decisions are addressing Internet and
domain name issues with potentially conflicting and disruptive consequences for the operation of the
DNS.
Security Challenges
Like all public networked systems, the system of public domain name servers is threatened
by a variety of purposeful attacks, both malicious and mischievous, by individuals or groups that
aim to disable or divert their operations. The operators of the DNS are responding to these threats, but
not all the desirable steps to ensure security have yet been implemented.
Denial-of-Service Attacks
Denial-of-service attacks attempt to overwhelm key name servers and their links to the Internet
with so much traffic that they are incapable of responding to legitimate queries. The root name servers
have the capacity and capability to respond to many times the normal number of queries they receive, and
have alternate connections to the network if some are blocked. Their ability to respond to attacks has been
improved by some operators' recent addition of multiple distributed copies (called "anycast" servers) of
the base name servers, increasing both capacity and connectivity. In anticipation of future denial-of-
service attacks and normal growth in demand, and to improve service globally, anycast server
deployment should be expanded.
Physical Vulnerability
Notwithstanding the deployment of anycast servers and installation of backup servers at remote
locations, there remain concentrations of base root name servers in the Washington, D.C., area and, to a
lesser extent, in the Los Angeles area. This is a system vulnerability, since anycast servers depend on the
13 critical root name servers to obtain root zone information. There should be a further physical
diversification of the location of root name servers, ideally into hardened locations.
Message Alteration
In response to the threat of alteration of messages being transmitted among name servers, the
technical community has developed DNS Security Extensions (DNSSEC), which uses digital signatures
to verify that the content of a message to or from a name server arrives unaltered and that its origin is as
stated. DNSSEC only gives assurance that what was sent was not changed during transmission; it cannot
and is not intended to assert that the message is factually correct. For example, DNSSEC has no
capability to guarantee that it is communicating the address for a given domain name. The security of the
DNS would be significantly improved if DNSSEC were widely deployed among name servers for
the root zone and top-level domains in particular, and throughout the DNS in general.
ES-2
Prepublication Copy--Subject to Further Editorial Correction
Performance Monitoring
Although some steps have been taken, more could be done to continuously monitor the
performance and traffic flows of the DNS so as to enable rapid detection of and response to attacks or
outages.
Governance Challenges
The DNS works through the voluntary cooperation of its autonomous component entities.
That cooperation, in turn, depends on their tacit agreement on two principles that together enable
the Internet and the DNS to evolve and remain effective:
Universal open standards. The first principle is that the protocols and standards defining
operation of the Internet and the DNS will be open and established by the Internet Engineering Task
Force (IETF), an international voluntary organization of technical specialists. This technical framework
enables every device on the Internet to connect to and communicate with every other, and it has been
critical to the success of the Internet and the DNS. Because changes in Internet and DNS protocols,
standards, and practices are matters of consequence beyond specific Internet services, alterations to the
functions of or modifications to established standards and practices have traditionally been vetted by the
IETF before being implemented.
Innovation at the edges. The second principle is that applications should be offered by
devices on the edges of the Internet, rather than at the Internet's internal nodes or on its links. In general,
applications located at the edges have little effect on the stability of the Internet, so there is no need to
regulate them. The DNS is not, strictly speaking, internal to the Internet (the translation service is
performed by computers at the edges), but functions as though it were. It can thus be thought of as a core
service, which although not absolutely necessary, is extremely useful in giving a relatively user-friendly
face to Internet resources, and for enabling access to those resources even when their Internet addresses
change. Moreover, it is a deeply embedded and ubiquitous service that enables other services and
functions, including most aids to Internet navigation.
This tacit agreement governs the basic behavior of the many autonomous operators of the DNS,
but there is also a need for an authority to make decisions about the allocation of limited resources central
to DNS operations. The most critical of these decisions are the determination of which top-level domains
(TLDs) shall appear in the root zone file of the DNS, which organizations shall be designated as
responsible for their operation, and the terms under which those organizations shall operate.
The principal organizations that constitute this authority are, currently, the U.S. Department of
Commerce (DOC) and the Internet Corporation for Assigned Names and Numbers (ICANN), although
national bodies have considerable influence over the operations of the associated country-code top-level
domains (ccTLDs). Both the DOC and ICANN face significant challenges to their authority and
legitimacy in management of the DNS.
Stewardship of the DNS
As the Internet has become an increasingly important component of the international
infrastructure, there has been growing pressure to introduce some form of international political control
over the DNS. This pressure comes both from existing international organizations seeking authority over
the Internet or the DNS, and from individual countries that would like to end the stewardship role of the
United States.
ES-3
Prepublication Copy--Subject to Further Editorial Correction
Governance of the DNS is part, but not all, of governing the Internet. Efforts to leverage it
to influence broader Internet policy are, therefore, likely to be ineffective and could also be
detrimental to the DNS. Many of the governance issues that concern governments control of spam and
uses of the Internet for illegal purposes; resolving the disparities between developed and developing
countries in Internet usage; protection of privacy, freedom of expression, and intellectual property other
than domain names; and the facilitation and regulation of e-commerce have little or nothing to do with
the DNS per se. The DNS would not be an effective vehicle for addressing such issues. Attempts to
change the DNS or extend its management and administrative processes to do so could interfere with
reaching agreements on the already contentious issues concerning the DNS itself.
Governance of the DNS is not an appropriate venue for the playing out of national political
interests. One valued and essential quality of the DNS institutional framework has been its relative
freedom from direct pressures arising from conflicts among competing national interests and policy
agendas (apart from sovereignty-associated issues such as ccTLD delegations and redelegations).
International disputes arising in other contexts have largely been kept away from the DNS as they
should be.
For that reason: The committee does not support efforts to put the DNS directly under the
control of governments or intergovernmental agencies. In practical terms, the U.S. government, which
must agree, has not supported turning DNS stewardship over to other governments or an international
organization, although that could change. Although the 2005 U.N.-sponsored World Summit on the
Information Society (WSIS) may produce proposals for a non-governmental agent an internationally
negotiated convention or multi-stakeholder organization with oversight or other influence over the
DNS, no proposal that can be evaluated for either practicality or feasibility has yet (in December 2004)
been made.
One way to respond to concerns about the U.S. government's role as steward of the DNS is
for it to transfer its stewardship role to a non-governmental body specifically, ICANN. In the
September 2003 revision of its agreement with ICANN, the DOC stated its intent to transfer its
stewardship to ICANN if within 3 years ICANN is able to fulfill a mutually agreed set of tasks.
If ICANN does not fulfill the agreed tasks, and a proposal for creation of a non-governmental
organization having Internet governance responsibilities results from the WSIS process before the transfer
date, the DOC could consider transferring the stewardship role to the proposed organization. That would
entail comparing a not-yet-existing organization to one with 8 years of experience and evolution.
Life without the stewardship of the U.S. government will open ICANN to political and
commercial pressures. A free-standing ICANN would lack the oversight and, importantly, the protection
provided by the U.S. government's stewardship. If ICANN becomes steward of the DNS, legitimacy
based on the "consent of the governed" would be the principal basis for its continued authority and its
ability to resist inappropriate pressure from governments and other powerful interests. Final responsibility
for satisfying the needs of its constituencies in an equitable, open, and efficient manner would lie with its
board.
Before completing the transfer of its stewardship to ICANN (or any other organization), the
Department of Commerce should seek ways to protect that organization from undue commercial or
governmental pressures and to provide some form of oversight of performance.
Legitimacy of ICANN
ICANN is a work in progress; its long-term success is not assured. After a troubled start, it has
introduced several innovations to the institutional framework of the DNS, including competition among
registrars and an arbitral process for resolving disputes over domain names, the Uniform Domain Name
Dispute Resolution Policy (UDRP). In 2003 it had to undertake a major reform of its own organization,
stimulated by dissatisfaction with its operation under its initial structure. It is working on the revision of
ES-4
Prepublication Copy--Subject to Further Editorial Correction
key decision processes in response to complaints about their lack of transparency and fairness.
Furthermore, ICANN has been unable to conclude formal agreements with many of the organizations
critical to its responsibilities, notably the root name server operators and the vast majority of the ccTLD
registries. Nevertheless, through its responsibility for recommending changes in the root zone file, which
defines which TLDs are in the DNS and where their operators are located on the Internet, ICANN has
been able to exercise authority over the coherence and stability of the DNS.
Since its beginning, ICANN has been the subject of controversy and contention flowing from the
many diverse constituencies that have been attracted to it and their correspondingly diverse views. The
critics' concerns have been with ICANN's scope, its organizational structure, and its management
processes. The concern about scope has been principally the extent to which ICANN has exceeded its
technical-administrative responsibilities, for example, to regulate TLD registry operations; but others
have been disappointed by its unwillingness to take on broader issues. The structural concerns have
included perceptions of imbalance in the historical composition of ICANN's board, of failings in the
board selection processes, and of inadequate representation of certain constituency groups. The process
concerns have been the perceived lack of transparency, effectiveness, accountability, and recourse in
ICANN's electoral and decision processes.
ICANN is more likely to improve its perceived legitimacy by narrowing its scope and by
improving its processes rather than by seeking an ideally representative composition of its board.
No composition of its board is likely by itself to confer the perception of legitimacy on ICANN
among its constituency groups. A narrowing of scope and improvement of processes are elements of the
path that ICANN claims to be following in carrying out its 2003 reform. However successful its reform,
ICANN faces the challenge of reaching an effective modus operandi with three critical sets of participants
in the DNS's institutional framework: the root name server operators, the generic TLD registries, and the
ccTLD registries.
Root Name Server Operators
No greater oversight of the root name server operators will be necessary so long as they
continue to operate effectively and reliably and to improve the DNS's security, stability, and
capability. The effective daily operation of the root, and therefore the DNS, lies in the hands of the
operators of the 13 critical root name servers. They have provided reliable and efficient service as the
Internet has undergone rapid growth in the numbers of its users and providers. Although the DOC has
assigned ICANN responsibility for the stability and security of the root name server system, ICANN's
authority has not been sufficient for it to manage or regulate the root name server operators directly, nor is
it clear that doing so is desirable or necessary. The real challenge to ICANN is to identify how it can best
ensure the stability and security of the root name server system, given the long-standing autonomy of the
operators and the effectiveness of their operations.
More formal coordination of the root name server operators is desirable in the longer term.
ICANN is currently the most appropriate organization to assume the coordination role. Although
direct management or oversight may be neither necessary nor feasible, with continued growth in the
Internet and demands on the DNS, a more formal process of coordination of the root name server
operators with ICANN's facilitation will become desirable so as to ensure rapid response to persistent
security needs and to other challenges.
The present independent funding arrangements for the root name servers are advantageous
and should continue, because the multiplicity of sources contributes to the resilience, autonomy,
and diversity of the root name server system. The root name server operators do not receive direct
compensation for the service they perform. While running a root server may only add an incremental cost
in the range of tens of thousands of dollars for an organization already operating a secure Internet site,
fully loaded costs have been estimated at up to $1 million or more depending on numerous factors
including the number of locations, bandwidth requirements, and staffing levels. The costs are covered by
ES-5
Prepublication Copy--Subject to Further Editorial Correction
each organization as part of other operations. Although a central source of funds to compensate all the
root name server operators for their services might appear desirable, it is likely to be accompanied by an
unacceptable regulatory or control role for the funding organization and would reduce the robustness of
the current arrangement.
ICANN should work with the root name server operators to establish a formal process for
replacing operators. that directly engages the remaining root name server operators. Under the
process, ICANN would be responsible for the final decision on the basis of recommendations from
the root name server operators. One or more of the current root name server operators may withdraw
for organizational or performance reasons, and it would be reasonable to have in place an agreed process
to deal with such eventualities.
Generic Top-Level Domain Registries
A major challenge to ICANN since its founding has been deciding whether, when, and how to
add generic top-level domains (gTLDs) and, if any are added, how many. It has faced strong pressures
both to add gTLDs and to stop or, at least moderate, the pace of such additions. The committee addressed
the issue of gTLD addition broadly in terms of both effects and constituencies affected, but for simplicity
the multidimensional arguments for and against new gTLDs were clustered into two groups: technical and
operational performance, and user needs and economic benefits.
Considering technical and operational performance alone, the addition of tens of gTLDs per
year for several years poses minimal risk to the stability of the root. However, an abrupt increase
(significantly beyond this rate) in the number of gTLDs could have technical, operational, economic, and
service consequences that could affect domain name registrants, registries, registrars, and Internet users.
From the standpoint of user needs and economic benefits, neither the arguments in favor of
nor those against additional gTLDs are conclusive. Thus, the decision to add gTLDs is one requiring
judgment and cannot be determined by formal analysis alone.
If new gTLDs are added, they should be added on a regular schedule that establishes the
maximum number of gTLDs (on the order of tens per year) that could be added each time and the
interval between additions. Addition of gTLDs should be carried out cautiously and predictably, so that
on the one hand, the stability and reliability of the system can be protected, and on the other hand, those
considering acquiring a gTLD can do so with a realistic view of future prospects.
A mechanism to suspend the addition of gTLDs in the event that severe technical or
operational problems arise should accompany a schedule of additions. It should explicitly specify
who has the authority to suspend additions and under what conditions.
A neutral, disinterested party should conduct an evaluation of new gTLDs approximately 1
or 2 years after each set of new gTLDs is operational to make recommendations for improving the
process for selecting and adding gTLDs.
If new gTLDs are to be created, the currently employed comparative hearing or expert
evaluation processes should not be assumed to be the only processes for selecting their operators. In
its addition of gTLDs in 2000, ICANN used a comparative hearing process to select 7 from the 44
applicants. In its 2004 addition of sponsored gTLDs, ICANN used a non-competitive process that
replaces subjective judgments by its staff and board with judgments by expert groups that are insulated
from lobbying, but whose decision-making processes are not transparent. By doing so, it has reduced a
few of the potential sources of dissatisfaction with the resultant selections compared with the process used
in 2000. However, the question remains as to whether it is necessary for ICANN to qualify new gTLDs,
as this process does, on such matters as sponsorship by a community, business and financial plans, and
addition of new value to the name space.
For creation of new gTLDs, ICANN should consider alternate processes that are less reliant
on expert, staff, or board judgments. One such approach would be pre-qualification of applicants only
on technical capability, basic financial viability, and adherence to registrant protection standards and
ES-6
Prepublication Copy--Subject to Further Editorial Correction
ICANN policies. (ICANN should establish requirements to minimize the dangers of domain name
registrants losing their service and the value invested in their domains if a registry fails and should
carefully consider possible side effects.) If the number of qualified applicants turns out to be less than the
number of available slots, all would be chosen; if not, a market-based selection process an
auction could be used to select among them. Because of the wide range of intents and corresponding
designs of such processes, they must be carefully designed, drawing on the wide range of previous
experience in the design of auctions.
Country-Code Top-Level Domain Registries
Resolution of ICANN's role vis-á-vis the ccTLDs is one of the critical challenges to
establishing an ICANN that is viewed as a legitimate and appropriate steward for the DNS.
Although the ccTLDs represent 243 of the 258 TLDs, ICANN had formal agreements with only a dozen
of the ccTLD operators as of December 2004.
The ccTLDs as a group now operate only partially under the oversight of any higher authority,
ICANN or government. A number of ccTLDs are overseen by their national governments; some have
established non-governmental bodies to represent the local Internet community and exercise varying
degrees of oversight; some are completely autonomous non-profit bodies that operate voluntarily to meet
local Internet community interests; and some are commercial bodies with some contractual linkage to the
national government.
The only body that currently has an opportunity to exercise oversight over all the ccTLDs is
ICANN. The principal way in which it exercises that authority is through recommendations to the DOC
about which organization should be delegated responsibility for a specific ccTLD. Yet this issue arises
only when the present delegatee resigns or is challenged or a new ccTLD is established.
The relationship between ccTLDs and ICANN has been difficult from the beginning of ICANN.
First, a large number of the ccTLDs felt no need to contribute to ICANN's budget, since they did not
think that they received any corresponding benefits. Second, many ccTLDs resented ICANN's major role
in deciding on delegations and redelegations--essentially a policy role that they felt would be better
performed locally. They also believed that their position as one constituency within ICANN's initial
Domain Names Supporting Organization, whose other constituencies primarily addressed gTLD issues,
did not adequately reflect their importance.
Under its 2003 reorganization, ICANN attempted to respond to their concerns by replacing the
Domain Names Supporting Organization with two organizations, the Generic Names Supporting
Organization (GNSO) and the Country-Code Names Supporting Organization (ccNSO). ICANN intends
thereby to draw the ccTLDs more actively into its operations and build a stronger basis for their support.
Furthermore, ICANN's Governmental Advisory Committee was (in August 2004) working on a revision
of its Principles for the Delegation and Administration of Country Code Top Level Domains to address
many of the concerns expressed about them.
If the creation of the ccNSO does not result in increased participation by the ccTLDs in
ICANN policy making, then ICANN may find itself subject to increasing pressures to constrain its
role to that of gTLD management and root zone file record keeping and to turn ccTLD oversight
over to some other organization. The success of the ccNSO will depend on its ability to attract an
increasing number of members, both from the large ccTLDs that are needed for financial and other
support of ICANN and the smaller ccTLDs that can benefit from the support that ICANN could offer
them. Even more critical is the refinement of the principles and processes for delegation and redelegation
of ccTLD registries and their acceptance by most of the ccTLDs.
ES-7
Prepublication Copy--Subject to Further Editorial Correction
Commercial Challenges
Perhaps the most subtle, but still significant, challenge that the DNS faces is that arising from the
imperative faced by commercial operators of DNS elements they must strive to increase their revenues
and profits in the face of competition. On the Internet, increasing revenues generally means increasing
traffic to one's service, sometimes by diverting it from another operator's service. This imperative raises
the temptation to seek traffic and revenue by breaking or bending the fabric of tacit agreements that
underlies the success of the Internet and the DNS.
ICANN should strengthen its contracts with TLD operators (especially the largest ones) to
ensure that it has the authority to review proposed changes in their services that could have a
detrimental effect on the DNS or on other services that depend on the DNS. It should establish an
open, transparent, and speedy process of review for such changes that solicits contributions from
the technical community, other DNS operators, other affected Internet operations, and end users. A
recent case in point is the unanticipated and unannounced introduction by VeriSign, a commercial
registry, of a service, called Site Finder, that altered the conventional response to erroneous queries to the
.com and .net TLDs, by returning pointers to its own search page, rather than sending back an error
message. After being called on by ICANN to suspend the service, VeriSign did so under protest and is
currently seeking relief in the courts.
TLDs and other DNS operators that do not have agreements with ICANN should
voluntarily agree to adhere to published technical standards and to consult the technical
community and conduct public review processes before introducing new services that could have a
detrimental effect on the DNS or on other services that depend on the DNS.
Dispute Resolution Challenges
Arbitral domain name dispute resolution processes, rather than national courts, should
continue to be encouraged as the initial and primary vehicle for resolving most disputes associated
with the rights to domain names. The Uniform Domain Name Dispute Resolution Policy was
implemented by ICANN in December 1999 and has been adopted by all registrars in nine of the generic
top-level domains, as well as voluntarily by managers of several ccTLDs. In addition, managers of other
ccTLDs have adopted their own policies based on modified versions of the UDRP.
The UDRP has generally satisfied the need for an effective and cost-efficient means of
resolving disputes concerning domain names; however, it has weaknesses that should be addressed.
The UDRP has both positive and negative aspects, which differ, however, depending on whether they are
being considered from the perspective of the complainants or of the respondents. Although many
observers believe that the UDRP has enabled speedy and fair resolution of domain disputes, others
believe that the current system is biased toward the interests of trademark holders. Notwithstanding its
perceived disadvantages, more than 9000 decisions concerning over 15,000 domain names have been
rendered under the UDRP.
The feasibility and desirability of five specific UDRP improvements should be further
considered by ICANN:
Improving consistent use of arbitral precedents to enable similar issues to be addressed in
a more consistent manner that also supports case-by-case knowledge building;
Establishing an internal appeals process that would review the small number of decisions
that are clearly faulty or that cover a situation or issue for which competing bodies of precedent exist;
ES-8
Prepublication Copy--Subject to Further Editorial Correction
Using three-member panels. Some analyses of UDRP proceedings indicated a significant
difference in outcomes depending on whether they were heard by one-member or three-member panels:
three-member panels found for the complainant in a smaller percentage of the cases;
Improving panelist knowledge about the technology underlying the DNS, the uses of
domain names (beyond Web sites), and the application of the policies and rules applicable to domain
name disputes; and
Improving the nature and structure of incentives in the process. Under the current
funding structure, the revenue for panelists depends on the volume of cases, creating incentives either for
haste or for marketing strategies and tactics to attract cases by defining lucrative niches.
Internationalization Challenges
Continuing and increased attention to internationalized domain names (IDNs) is necessary.
Efforts to coordinate work across different countries, regions, and language groups should be
undertaken to prevent the balkanization of the Internet. Of particular interest in many countries is
access to the Internet and the DNS using home-country languages and scripts. Unfortunately, the design
of the DNS, as well as the general nature of multiscript environments, presents formidable technical and
linguistic challenges for the accommodation of languages that use non-Roman characters, which require
compromises for their solution.
Some experts have argued for a major overhaul of the Internet's infrastructure to incorporate
IDNs. However, pressure to act quickly reduced support for solutions that would require extensive
changes in architectures or standards; the result was an effort led by the IETF that culminated in the
Internationalizing Domain Names in Applications (IDNA) mechanism.1 The central goal of the IDNA
scheme is to enable end-user viewing of IDNs without altering the DNS protocols themselves, using a
client-side set of procedures, implemented at the edge of the DNS.
However, the IDNA mechanism solved only part of the internationalization problem. Remaining
to be addressed are the questions of potential consumer confusion; conflict avoidance or resolution for
similar-appearing names; differences in interpretations for different languages; restrictions on
registrations on a per-domain basis; implications for the UDRP and the Whois database (of information
about domain name registrants); security issues raised by IDN; and the implications of (and alternatives
to) multilingual top-level domains.
INTERNET NAVIGATION
In contrast to the unique role played by the DNS, navigation through the Internet is not supported
by a unique integrated technical system. Among the many ways to navigate the Internet, only two involve
dedicated technical systems--search engines and directories. Moreover, the institutional framework of
those technical systems is an open market, with many, generally commercial, competitors offering
navigation services, and specialized non-commercial services focused on non-profit resource providers
and seekers.
Finding and accessing a desired resource via the Internet poses challenges that are
substantially different from the challenges in navigating to resources in non-digital, non-networked
environments.
A wide range of navigation aids and services now permit large segments of the Internet,
particularly the World Wide Web, to be traversed rapidly and efficiently in ways previously
unimaginable. They offer users across the globe convenient access to much human knowledge and
1 IDNA is described in: Patrik Fältström, Paul Hoffman, and Adam M. Costello. 2003. "Internationalizing Domain
Names in Applications (IDNA)." RFC 3490. March. Available at <http://www.rfc-editor.org/>.
ES-9
Prepublication Copy--Subject to Further Editorial Correction
experience and open an international audience to purveyors of content and services, no matter
where they may be located.
Use of Navigation Aids and Services
Surveys indicate a high level of satisfaction with navigation aids and services at present.
An analysis of navigation behavior, based on survey data from March 2003,2 indicates that
Internet users tend to use preferred sites and services consistently, visiting them repeatedly, using their
bookmarks or remembered Uniform Resource Locators (URLs). Search engines produced only 13 percent
of site referrals, navigation through entry of a known or guessed URL or use of a bookmark produced 66
percent of referrals, and flow along hyperlinks produced 21 percent.
According to a recent survey,3 residents of the United States conducted 3.9 billion searches in
June 2004, an average of 33 searches per user. Search engines have been used by 84 percent of U.S.
residents who use the Internet--more than 107 million people; on an average day, about 38 million of the
64 million U.S. residents who are online use a search engine. Using search engines is second only to
using e-mail as the most popular Internet activity, except when major news stories are breaking. A vast
majority of searchers say that they find the information they want most of the time, and more than two-
thirds consider search engines a fair and unbiased source of information. But only a third of searchers say
they could not live without search engines; about half say that, although they like using search engines,
they could go back to other ways of finding information.
As the material accessible through the Internet continues its rapid increase in volume and
variety and as its societal importance grows, Internet navigation aids and services are likely to be
challenged to deliver more precise responses, in more convenient forms, to more diverse questions,
from more users with widely varying skills. Efforts to improve the basic algorithms and operations of
Internet navigation services will continue because of competitive pressures, evolving user requirements,
and technological advances. Among the specific areas where improvements are needed are query
interfaces and results displays for desktop, portable, and collaborative devices; navigation of audio and
visual materials; management of the navigation process; use of contextual information (while protecting
privacy); and understanding the wide range of navigation behaviors of the highly diverse users who now
seek resources on the Internet.
As the Internet has become the sole or most accessible location of many valuable resources, the
importance has grown of ensuring that they will persist indefinitely at the same URL (or in an archive on
the same site) or, alternatively, that they will be preserved at another site where they can be readily found.
Ensuring persistence is primarily the responsibility of resource providers, while third parties national
libraries or private organizations such as the Internet Archive--are undertaking some preservation efforts.
Although commercial services can be expected to support substantial research and development
on these topics, academic research and development activities have provided the innovative basic
technologies for many successful navigation aids and services. Public support of such academic
research and development efforts should be continued.
2 The data were collected on March 6, 2003, by WebSideStory's StatMarket from about 12 million visitors to
125,000 sites using its proprietary analytical platform and compared with figures from the previous year. Reported
in: Brian Morrissey. 2003. "Search Guiding More Web Activity." CyberAtlas. March 13. Available at
<http://cyberatlas.internet.com/big_picture/traffic_patterns/article/0,1323,5931_2109221,00.html>.
3 See Deborah Fallows, Lee Rainie, and Graham Mudd. 2004. "The Popularity and Importance of Search Engines."
Data Memo. Pew Internet & American Life Project. August. Available at
<http://www.pewinternet.org/pdfs/PIP_Data_Memo_Searchengines.pdf>. The results came both from a telephone
survey of 1399 Internet users and from tracking of Internet use by comScore Media Metrix.
ES-10
Prepublication Copy--Subject to Further Editorial Correction
Commercial Navigation Services
The Internet navigation services industry has financed the development and evolution of
services that meet many of the needs of a wide range of searchers at little or no cost to them,
especially when they are seeking commercial material. At the same time, it has provided advertisers
with an efficient, cost-effective means to gain access to potential customers at the time that they are
most interested in the advertiser's product or service. The primary source of income for commercial
Internet navigation services is selling advertising linked to search queries. Consequently, as for many
broadcast media, it is the content and service providers that are subsidizing users' access to navigation
services so that they can present advertisements to them at the time of their expressed interest in a topic.
The major search services currently identify the results whose presentation in response to
specified search terms is paid for by advertisers (so-called sponsored links or sponsored search listings)
and set them off from the direct results of more neutral search algorithms. As long as the distinction is
clear and users are aware of it, sponsored search listings should present few problems while providing the
great benefit of free search services to the user.
The potential for abuse exists, however. It would be possible, for example, for a search
service to accept payment for assured placement in the "top 10" of what would appear to be a
neutral listing. Should abuses grow, search services could find themselves under increased public
pressure for government scrutiny or facing more disputes and criticism concerning such activities
from other commercial entities. None of the navigation services have been accused of accepting
payment for highly ranked inclusion of particular responses to queries, but some have accepted payment
to ensure inclusion, but not ranking, in the otherwise neutral listing. Furthermore, the distinct placement
and typography of the sponsored listing could be weakened to the point that a casual user would not be
aware of its difference from the neutral algorithmic search results. Thus far, competition among services,
third-party evaluations, and the perceived value to the user of search transparency have served as
important forces constraining misbehavior of these kinds.
Although competition and the desire to be seen as useful by searchers are incentives for fair
and open behavior, appropriate regulatory agencies of the U.S. federal government and of other
governments should pay careful and continuing attention to the result ranking and display
practices of Internet navigation services and their advertisers to ensure that information can flow
freely and that those critical practices are fully disclosed. The behavior of commercial navigation
services can have a substantial influence on the kind, quality, and appropriateness of the information that
Internet users receive. Although there is no evidence that abuse has yet occurred, the potential for abuse is
inherent in the navigation services' ability to affect users' access to information for commercial or other
reasons.
In the future, competition among general navigation services is more likely to take the form
of rivalry among a small number of established large players rather than competition with a large
number of small newcomers. Over the past 4 years, there has been considerable consolidation in the
general search services market, which reflects the increasing importance of economies of scale--the
considerable hardware and software costs of developing and operating a search engine are independent of
the number of users, whereas revenues from advertising are directly dependent on them. The result is that
the barriers to entry are high, and only a company with substantial financial resources and technical skills,
such as Microsoft or IBM, is in a position to introduce its own competitive general navigation service, as
Microsoft began to do in 2004.
Innovation, Competition, and Regulation
The importance of the Internet as the infrastructure linking a growing worldwide audience
with an expanding array of resources means that improving Internet navigation will remain a
profitable goal for commercial developers and a challenging and socially valuable objective for
ES-11
Prepublication Copy--Subject to Further Editorial Correction
academic researchers. Consolidation of navigation services makes it difficult for innovative services to
start small and build volume over time unless they have a very large amount of patient investment capital.
But, so long as no single service becomes dominant, each of the major competitors will face continuing
pressure to improve its offerings either through internal innovation or through the acquisition of
innovative small companies, paths they are currently actively pursuing.
Since competition in the market for Internet navigation services promotes innovation,
supports consumer choice, and prevents undue control over the location of and access to the diverse
resources available via the Internet, public policies should support the competitive marketplace
that has emerged and avoid actions that damage it.
Potential rulings in some jurisdictions could substantially reduce the ability of search
engines to sell keywords using the current automated methods. As with the Domain Name System,
the most contentious intellectual property issues affecting navigation services concern trademarks,
specifically the sale of trademarked terms to advertisers as keywords whose use will bring up their
advertisements. Since there is no arbitral process, such as the UDRP, by which such disputes could be
resolved outside the courts and with worldwide effect, it seems likely that conflicting court decisions in
different jurisdictions, worldwide, will establish the potentially conflicting rules by which navigation
services will have to abide.
THE DNS AND INTERNET NAVIGATION
The preservation of a stable, reliable, and effective Domain Name System will remain
crucial both to effective Internet navigation and to the operation of the Internet and most of the
applications that it supports.
Despite the differences in the way in which they developed, the relationship between the DNS
technical system and Internet navigation aids and services is strong and fundamental the DNS has
served as the stable core on which the incremental evolution of the different navigation aids and services
has depended. The development of navigation services is likely to continue to relieve some of the
commercial pressures on the DNS as users become increasingly comfortable with using them as their
primary means to navigate the Internet, but both the Domain Name System and Internet navigation aids
and services will be significant elements of the Internet for the foreseeable future.
The demonstrated success of the DNS and navigation aids and services in meeting the basic
needs of all Internet users should not be jeopardized by efforts to constrain or direct their evolution
outside the open architecture of the Internet, or to use them to enable control of the free flow of
information across the Internet.
The governance and administration of the DNS should not become a vehicle for addressing
political, legal, or economic issues beyond those of the DNS itself.
ES-12
Prepublication Copy--Subject to Further Editorial Correction
1
Introduction
The Internet is rapidly becoming everybody's neighborhood. Just a few keystrokes take us to an
online bookstore; several mouse clicks deliver us to an online newsstand; only a bit more effort connects
us with distant friends or family. For many of us, seeking out a Web site or an e-mail address is almost as
important as finding the way to the library, a theater, the nearest mall, the bookstore, or the neighborhood
playground. And for those who use the Internet to deliver products or services, their clientele's ability to
find them is essential to their success. Navigating the virtual neighborhood has become a life skill for
those needing something on the Internet and a life-or-death matter for businesses with something to offer
on the Internet.
To navigate--to follow a course to a goal--across any space, a method is needed for designating
locations in that space. On a topographic map, each location is designated by a combination of a latitude
and a longitude. In the telephone system, a telephone number designates each location. On a street map,
locations are designated by street addresses. Just like a physical neighborhood, the virtual neighborhood
has addresses--32 or 128 bit numbers, called Internet Protocol (IP) addresses--that define the specific
location of every device on the Internet. And also like the physical world, the virtual world has names--
called domain names, which are generally more easily remembered and informative than the addresses
that are attached to most devices--that serve as unchanging identifiers of those devices even when their
specific addresses are changed. The use of domain names on the Internet relies on a system of servers--
called name servers--that translate the user-friendly domain names into the corresponding IP addresses.
This system of addresses and names linked by name servers establishes the signposts in cyberspace and
serves as the basic infrastructure supporting navigation across the Internet. It is called the Domain Name
System (DNS).
This report is concerned with the Domain Name System and its interactions with Internet
navigation, including its uses as a means of navigation itself and as an infrastructure for navigation by
other means. Since the World Wide Web is the application running on the Internet that contains the
greatest number of locations to which most users want to navigate, this report often draws examples from
the Web. However, there are other applications that use the Internet, not least e-mail, and others that are
being developed for it. The DNS supports most of them. Unless otherwise specified, the information in
this report, its conclusions, and its recommendations apply to the DNS in its role as a basic infrastructure
element of the entire Internet, not just of the World Wide Web.
The report's specific objectives and how it is organized to address them are spelled out in this
chapter, which begins with an introduction to the Internet, the Domain Name System, and Internet
navigation, and with an examination of the forces affecting them. Four basic concepts that are used
throughout this report--names, navigation, technical system, and institutional framework--are defined
and briefly described in Box 1.1.
1.1.
THE INTERNET
The Internet, according to the National Research Council, is "a diverse set of independent networks,
interlinked to provide its users with the appearance of a single, uniform network . . . . The networks that
compose the Internet share a common architecture (how the components of the networks interrelate) and
software protocols (standards governing the interchange of data) that enable communication within and
among the constituent networks." 1
1Computer Science and Telecommunications Board, National Research Council. 2001. The Internet's Coming of
Age. Washington, D.C.: National Academy Press, p. 29.
1-1
Prepublication Copy--Subject to Further Editorial Correction
Internally, the Internet comprises two types of elements: communication links, channels over
which data travel from point to point; and routers, computers at the network's nodes that direct data
arriving along incoming links to outgoing links that will take them toward their destinations. Altogether,
the Internet is a complex network of routers and links, the latter varying in transmission medium
(telephone lines, cable lines, optical fiber cable, satellite, wireless); servers and other hosts; and access
equipment. Links in the network may be characterized by their transmission capacity (low-capacity local
lines to very high capacity "backbone" cables) and by their latency (short-latency local fiber links to long-
travel-time satellite links). Data travel along the Internet in packets adhering to the standard Transmission
Control Protocol/Internet Protocol (TCP/IP) that defines the packets' format and header information.
BOX 1.1
Four Basic Concepts
Names and Naming Systems
Names and naming systems are everywhere in society. A license plate on a car, a serial number
on a product, and a stock market symbol for a company are a few examples of names that are used within
formal naming systems. Each of these examples is a unique identifier, created according to the
specifications of a naming system, which is associated through strict naming rules with a single
automobile, product, or company. Equally important are a host of informal or less strict naming systems,
such as the naming of people by families, the naming of streets or locations, or the naming of files and
directories on a personal computer. In these processes, there is no guarantee of unique names for objects.
More generally, naming is used to distinguish individual objects within a broad class, the object
space. The set of allowable names for objects in that class is called the name space. A name is then a
member of that set used to differentiate one member of the object class from another. A naming system is
the combination of an object space, the name space that is applied to it, the rules governing the
assignment of names to objects, the files recording the assignments, and the administrative processes (if
any) applying the rules and maintaining the files.
Navigation, Navigation Aids, and Navigation Services
Navigation is the process of following a course from one place to another. In the narrow sense,
the term is used to refer to a person or entity (e.g., a vehicle) being directed along a course from an origin
to a specified destination. In the broader sense, navigation refers to following a course on, across, or
through (e.g., navigate a stream) or making one's way somewhere (e.g., Lewis and Clark navigating to the
"western passage" or Dr. Livingstone navigating to the source of the Nile). Navigation involves a set of
skills (e.g., reading a compass, using a search engine). The place to which one wishes to navigate may be
known explicitly (e.g., latitude and longitude, a street address, a Web site address) or only in general
terms (e.g., source of the Nile, sites with information about veteran's benefits). In the former case,
navigation requires only the two steps of laying out a route to the known location and following it. In the
latter case, however, there is a prior step of identifying the desired location (or locations) through a search
process of some form.
A navigation aid is anything that assists navigation, such as a map or a compass. In the physical
world, navigation aids include a sextant and precision clock, and a compass and topographical map. In
document-oriented environments, navigation aids include printed directories for the telephone system and
online or card catalogs for library collections. Human intermediaries also can serve as navigation aids in
these environments, such as directory assistance operators in the telephone system and reference
librarians for library services. In the Internet, navigation aids include bookmarks and lists of favorites,
hyperlinks, and restricted keyword systems, such as AOL keywords.
A navigation service is a navigation aid that is based on a complex technical system (see below).
In the physical world, the Global Positioning System is a navigation service, as is an inertial navigation
system. Automated directory assistance and online white pages are navigation services for the telephone
1-2
Prepublication Copy--Subject to Further Editorial Correction
network, and online card catalogs are navigation services for libraries. In the Internet, directories and
search engines are navigation services.
Internet navigation, navigation aids, and navigation services are discussed in greater detail in
Chapters 6, 7, and 8.
Technical Systems
A technical system is an integrated set of engineered elements (components and practices) that
delivers a specific service to users. Some familiar examples of technical systems are the telephone
system, the air transport system, the electric power system, and the Domain Name System. In the case of
the telephone system, the engineered elements are organized in a complex network that includes the
switching facilities (both hardware and software) that set up the circuits linking telephones for a call, the
transmission lines that carry the calls, and the telephone instruments that originate and receive calls; the
service it delivers is telephone connectivity; and the users are people who want to communicate with
others by voice, data, or facsimile.
The single technical system that is the Domain Name System is described and discussed in
Chapters 2, 3, and 4; the technical systems that support Internet navigation services are characterized in
Chapters 6, 7, and 8.
Institutional Framework
An institutional framework is a collection of organizations and policies whose decisions and
actions enable a technical system to be constructed, operated, controlled, regulated, and improved. An
institutional framework and its technical system are complementary to each other. Each of the examples
of technical systems described above has a complementary institutional framework. The telephone
system, for example, depends for its effective and efficient development and operation upon a
complementary framework comprising equipment suppliers, operating companies, local, state, national,
and international regulatory bodies, international standards organizations, and the technical community.
The institutional framework of the DNS is discussed in Chapters 2, 3, and 5; that of Internet
navigation services, in Chapters 6, 7, and 8,
Each router uses the origin and destination IP addresses in each arriving packet to determine which link to
direct it along. A message from a sender to a receiver may be broken into multiple packets, each of which
may follow a different path through the Internet. Information in the packets' headers enables the message
to be restored to its proper order at its destination.
The origins and destinations of data transiting the Internet are computers (or other digital devices)
located at its "edges." They are, typically, connected to the Internet through an Internet service provider
(ISP) that handles the necessary technical and financial arrangements. A distinctive feature of the Internet
is that all the user services (such as e-mail or the World Wide Web) accessible through it are provided by
applications running on computers located at its edges. The "center" of the Internet--its links and
routers--provides the critical connectivity among them. As a consequence of this architecture, most of
the service innovation takes place at the edges, completely independently of the network itself. It is an
embodiment of the end-to-end argument in systems design2 that says that "the network should provide a
very basic level of service--data transport--and that the intelligence--the information processing needed
to provide applications--should be located close in or close to the devices attached to the edge of the
network."3
2 See J.H. Saltzer, D.P. Reed, and D.D. Clark. 1984. "End-to-End Arguments in System Design," ACM Transactions
on Computer Systems 2(4):277-288.
3 CSTB, NRC, The Internet's Coming of Age, 2001, p. 36.
1-3
Prepublication Copy--Subject to Further Editorial Correction
A consequence of this architecture is that innovation at the edges is eased and facilitated,
requiring no coordination with network architects or operators, as long as the basic protocols are adhered
to. Conversely, innovation at the center of the network is difficult and often slow, since it requires the
cooperation of many providers and users. Because of the higher potential for inadvertent disruption as a
side effect of a change at the center of the system, difficult and time-consuming effort must be devoted to
testing and validating each proposed change. All such changes have been subject to cooperative
collaboration and agreement by the Internet engineering community since the earliest days of research
and implementation. (See "Maintenance of DNS Standards" in Section 3.2.5.) That principle has been a
major factor in the successful design, development, and implementation of the technology.
The Internet's architecture has enabled it to respond very successfully to the challenges of growth
in the number of its users and in the capacity of its links and the complexity of their connectivity, as well
as to provide a robust base for the growth of services such as e-mail and the World Wide Web.
1.2 THE DOMAIN NAME SYSTEM
The DNS was put into place by technologists in the early 1980s when the Internet provided basic
non-commercial services to a small community of specialists.4 The World Wide Web had not yet been
invented. The DNS's designers intended it to be a simple and stable way for users and applications to
identify computers on the Internet. They gave it a hierarchical structure so that the responsibility for
maintaining the necessary information tying domain names to IP addresses (and other data) could be
distributed to the organizations actually managing the relevant networks and groups of hosts across the
edges of the network.5 They designed it as an inverted tree with the expectation that most domain names
would lie several branches down, requiring relatively few names in the upper part of the tree. Figure 1.1
illustrates the Domain Name System's role in support of navigation across the Internet.6 Complete
domain names7 incorporate the names of the nodes in the tree above them. So in Figure 1.1, the domain
name www.cstb.nas.edu designates the www leaf lying on the .cstb branch, which lies on the .nas
branch, which lies on the .edu branch.
A number of factors, including the introduction of the World Wide Web in the early 1990s, have
transformed the Internet community from a small town into a great and rapidly expanding metropolis with
an extremely large, highly diverse body of users, relatively few of whom are computer specialists. These
users employ the Internet as the communications backbone for a vast range of commercial and non-
commercial purposes. As a result, the Internet has expanded both in scale and in the scope of its
applications. Because of the elegance of its technical design, the DNS has, thus far, been able to adjust to
the expanded scale of the Internet, evolving to meet the increased operational demand adequately.
However, as a consequence of the growth in the scope of the Internet, the DNS is now used in ways that
were not anticipated when it was designed. These unanticipated uses have led, in turn, to a substantial
increase in the number and complexity of the institutions responsible for its operation and management
and to less use than was originally expected of deep naming hierarchies and distributed, but localized,
management of names. This growth in institutional complexity has been driven primarily by the fact that
domain names acquired increased value, which required mechanisms to deal with their allocation and
ownership. Their acquisition of increased value followed from four developments:
4 Chapter 2 describes the development of the Domain Name System from the early 1980s to the present.
5 Chapter 3 describes the design and operation of the Domain Name System.
6 This depiction of the DNS is highly simplified. More detailed descriptions of the DNS are provided in Chapters 2
and 3.
7 Formally, these are called "fully qualified domain names" to distinguish them from partial domain names that
describe the path only from some node below the root.
1-4
Prepublication Copy--Subject to Further Editorial Correction
Preference for short and memorable names. The first development was a preference among users
for short and memorable domain names, which led to an unexpectedly unbalanced distribution of domain
names. More devices were named at the second or third level of the inverted tree, thereby widening it,
rather than deepening it to the fourth and lower levels as had been anticipated. And although the
implementation of the DNS offered a range of generic top-level domains--such as .com, .net,
.org, .gov, and .edu--for a variety of reasons, .com became the preferred choice, further
unbalancing the tree. Even with the addition of new generic top-level domains after the year 2000,
memorable domain names within the .com domain remain the preferred choice for most businesses,
many non-profit organizations, and numerous individuals.8
Navigation role of .com. What led most directly to the growth in importance of the .com
domain was the second development--its self-fulfilling role in navigation. For example, as commercial
uses grew, users seeking IBM's site on the World Wide Web could guess www.ibm.com with an
expectation of success. That common behavior naturally led organizations and individuals to seek
registration of domain names that users might be able to guess to find their site, which in turn improved
the users' chances of navigating by guessing. That users were inclined to use domain names to search for
content of interest increased the desirability of domain names corresponding to generic words, such as
"business," "jobs," or "sex." And the importance of having those names in the .com domain was
increased even more by the design of Web browsers. Recognizing user inclinations, designers made the
default behavior of many Web browsers when confronted by an incomplete domain name the automatic
addition of .com to the end of it and www as the default prefix.9 Thus, domain names became not only
the way of designating locations on the Internet, but also a principal means of navigating to them.10
Valuable second level domain names. The third development was the recognition that certain
domain names within the top-level domains--second-level domain names --are more valuable than most
others. The result was an aftermarket for domain names, generally in the .com top-level domain, in
which some have been resold for prices far greater than the nominal registration fee paid by the original
registrant. Furthermore, in an effort to protect their rights and prevent others from abusing them,
trademark holders have sought to acquire many of the domain names incorporating their trademarks and,
given the likelihood of entry errors, words that are typographically close to them in all of the relevant top-
level domains. This effort has, in turn, led to competition among trademark holders with the same mark
(though in different industries or regions) for the small number of memorable domain names
incorporating their marks. (Individuals or groups with other legitimate claims to a name--such as those
with the surname McDonald11--have also asserted their rights to domain names incorporating
trademarks.) It has also attracted speculators who rush to acquire potentially desirable domain names
(both trademarks and generic words) in order to resell them to those for whom the value would be
substantially greater than the registration fee.12
Marketing function. The value of domain names has been further enhanced by their widespread
use in marketing materials as a secondary, or even primary (e.g., amazon.com), identifier of an
8 In mid-2004 there were almost 27 million .com registrations compared with 4.4 million for .net and 2.8 million
for .org. See Table 3.3.
9 Browsers in 2005 no longer make this assumption. Instead, they commonly assume that the entry is a search term.
10 The unique role of.com is elaborated on in Chapter 2.
11 The new top-level domain, .name, for registration by individuals was intended to meet that need, although by
mid-2004 the companies involved with registrations in that domain had not found business models capable of
supporting those operations.
12 A case in point is the name "business.com," which changed hands for $150,000 in 1997 and was resold for
$7.5 million in 1999. See "Business.com: The $7.5 Million Domain," ZDNet News, Jennifer Mack, December 1,
1999, available at <http://zdnet.com.com/2100-11-516999.html?legacy=zdnn>. However, in the aftermath of the
dot.com bust, the prices realized in the aftermarket for domain names have also subsided substantially, although at
the end of 2003 the name "men.com" was sold for $1.3 million by a person who paid $15,000 for it in 1997. See
"Domain Names Once Again Fetch Top Dollar," Associated Press, Anick Jesdanun, December 25, 2003.
1-5
Prepublication Copy--Subject to Further Editorial Correction
organization. In that role they appear on stationery, in newspaper ads, on billboards, and on the sides of
buses. This marketing function of domain names is the fourth unanticipated development.
Because of these developments, the Domain Name System--originally a modest technical system
introduced to provide easy-to-remember and portable names for locations on the Internet--has become a
critical tool facilitating global communication by designating sources of information, products, and
services as well as the e-mail boxes of people and organizations throughout cyberspace. As a
consequence, its simple original institutional framework, managed essentially by one person,13 has been
replaced with a complex network of institutions comprising numerous public and private, commercial and
non-commercial organizations that register domain names and operate name servers; and one non-
governmental organization with international scope that, with the authority and oversight of the U.S.
government, provides technical coordination and establishes some elements of global policy--the Internet
Corporation for Assigned Names and Numbers (ICANN).
1. What is the IP address of the
domain name www.cstb.nas.edu?
USER
2. The IP address of
www.cstb.nas.edu is 128.128.128.128
DOMAIN
NAME
SYSTEM
3. Retrieve the home page at
4. Here is the
128.128.128.128.
home page at
www.cstb.nas.
edu.
INTERNET
128.128.128.128
FIGURE 1.1 The Domain Name System and Internet navigation for the Web--navigating to
www.cstb.nas.edu. The Web site and IP address used are fictional.
1.3 INTERNET NAVIGATION
With the growth of the size, complexity, and variety of applications using the Internet, and
especially the rapid growth of the World Wide Web, a range of aids to the navigation process (especially
on the Web) have appeared.14 The DNS is a single technical system providing a single service, which is
operated and controlled in a complex institutional framework. In contrast, among aids to navigation on
13 Jon Postel held this responsibility for many years. For further information, see <http://www.isoc.org/postel>.
14 If the location of a desired Web site is known, then navigation can be direct--the DNS determines the IP address
of the site. If the location is unknown, then some navigation aid must first be used to determine the location. See
Section 71 for a detailed discussion of "direct" and "indirect" navigation.
1-6
Prepublication Copy--Subject to Further Editorial Correction
the Web there are numerous specialized navigation services, each operated by different providers that
compete openly without any comprehensive institutional framework for their operation and control.
Principal among these navigation services are search engines, which at the possible cost of a few more
keystrokes open up a far wider range of possibilities on the Web than simple domain name guessing; and
directories, which provide a "yellow pages" or "white pages" guide to locations, principally on the Web.
As search engines have improved in user-perceived quality and ease of use, they have become a principal
means of navigation to new destinations for many users.15 In place of guessing, intrepid Web travelers
enter a descriptive word or phrase in the search engine and use the resultant list to direct their journeys.
In June 2004, nearly 4 billion searches were conducted each month by almost 110 million people in the
United States, an average of 33 searches per person per month.16 It appears that a consequence of the
growing use of search engines for navigation across the Web may be a reduction, though by no means
elimination, of the direct use of the DNS to support navigation by guessing domain names.
Because locations that offer search or directory capabilities are accessed so often, a number have
evolved into portals, which are Web sites offering directed links to popular categories of services, such as
My Yahoo!. Portals such as MSN and AOL have also evolved from provision of Internet service. Some
users find the portals more desirable than search engines alone and begin their navigation from them. In
doing so, they are relying on the editorial judgment and commercial or other arrangements of the portal to
get started. However, once a World Wide Web site is reached--no matter how--subsequent navigation
often flows along the network of links from one site to others. And it is likely that most experienced
users deploy a combination of navigation aids and services: employing search engines, portals, and direct
entry of destinations into browsers at various times.17 Other navigation aids are also in use. In some Web
portals run by ISPs (such as AOL) or through extensions to browsers, a specified vocabulary of key
words can be used to reach specific destinations.
The cumulative effect of these aids to navigation has, thus far, been positive. They enable users
to find sources of products, services, information, and contacts that they would not have been able to
identify previously. Complementarily, they enable providers to reach audiences that might not otherwise
have known of their existence. Unlike the development of the top levels of the DNS, which has been
under the technical control of the Internet engineering community and the governance of ICANN,
national governments, and the operational organizations, these navigation services have for the most part
been provided by private organizations. Despite their benefits, however, navigation aids are also
beginning to raise policy concerns. Most search engines and directories now accept payment from
advertisers for placement of an ad on the pages of responses to queries with specific search terms. If not
clearly identified such ads might give searchers a false sense of an advertiser's importance or relevance
and reduce the chances that a non-advertiser will be located. Concerns about the practices of the providers
of navigation services are likely to grow as Internet users rely increasingly on these services as a principal
means of navigation.
15 According to data from WebSideStory, both direct navigation using a known domain name and the use of Web
search engines increased substantially from 2002 to 2003. In March 2003, 13.6 percent of Web site accesses were
generated by search engine listings, while 66 percent were the result of bookmarks or direct entry of a known
address. See <http://www.websidestory.com>, press release, March 12, 2003.
16 Deborah Fallows, Lee Rainie, and Graham Mudd. 2004. "The Popularity and Importance of Search Engines."
Data Memo. Pew Internet & American Life Project. August. Available at
<http://www.pewinternet.org/pdfs/PIP_Data_Memo_Searchengines.pdf>. The results came both from a telephone
survey of 1399 Internet users and from tracking of Internet use by comScore Media Metrix.
17 These destinations might be derived from guesses about domain names as discussed above or references provided
by others (e.g., in an e-mail) that are copied and pasted into browsers, as well as by the use of bookmarks for
destinations that are accessed frequently.
1-7
Prepublication Copy--Subject to Further Editorial Correction
1.4 THE DYNAMICS OF CHANGE
Since the early 1980s, when the DNS was adopted, five forces have inexorably driven the
transformation of the Internet from its origins as a small, primarily North American research network,
which was run by a tight-knit group of specialists for use within their research and industrial
communities, into its current state as a diffusely managed and increasingly critical part of the global
information and communication infrastructure. These driving forces are increasing scale, technological
progress, increasing economic value, increasing social value, and internationalization. In addition to
having a profound impact on the Internet (and the World Wide Web) as a whole, these forces have
simultaneously transformed the DNS and Internet navigation to subjects of substantial commercial, legal,
political, and social importance. The likelihood of the continued influence of these forces raises
important questions about the future viability, operability, and governability of the DNS and Internet
navigation--the subjects of this study.
1.4.1 Increasing Scale
When the DNS was developed, the Internet comprised on the order of a 1000 sites and perhaps
10,000 users. In two decades it has grown to more than 30 million sites and over 600 million users.18
Though its designers did not fully anticipate the rapid growth in users and uses stimulated by the World
Wide Web, the DNS has technically scaled quite well to the current size. In addition, new navigation
tools have been deployed to assist users in searching the vastly larger Internet. The Internet continues to
grow in number of users, number of addresses, and number and diversity of attached devices. By 2010, at
current growth rates, the Internet could have more than 60 million sites and well over a billion users
worldwide.19
1.4.2 Technological Progress
When the DNS was developed, most of the hosts were workstations, minicomputers, or
mainframe computers. Personal computers had just begun their penetration of the business and home
markets in North America, Europe, and Japan. Internetworking communication took place over
backbones that had 56 kbps (kilobits per second) speeds--about 1/180,000th the speeds of backbones in
2004, which run at 10 Gbps (gigabits per second). As the capacities of computers and communications
networks have soared, the DNS and navigation systems have taken advantage of the increased
computational capability and bandwidth to meet the challenges of scaling. Continuing technological
advances in computing and communications offer the possibility of strengthening the DNS and increasing
the capacities of navigation services, while at the same time further empowering those who would attack
the services or attempt to misdirect them for their own benefit.
1.4.3 Increasing Economic Value
When the DNS was developed, there was probably little or no economic value associated with
possession of a particular domain name, which could be obtained at no cost, although having a
18 These numbers reflect estimates made in May 2003 by CyberAtlas; see <http://cyberatlas.internet.com>.
19 To serve them, the basic IP address--currently 32 bits--is being enlarged to 128 bits, enabling addressing of a
wide range of devices from computers and cell phones to home digital media centers and home appliances. The
current IP address space is called the IPv4 address space; the new version is called the IPv6 address space. IPv6 is
slowly being adopted, working in parallel with IPv4.
1-8
Prepublication Copy--Subject to Further Editorial Correction
hierarchical naming system was judged to be valuable. A distinctive Internet culture had developed well
before this time, led by the relatively small and homogeneous community of engineers and scientists who
were its primary users. It placed high value on voluntary service, free access within the community, and
consensus decision making. However, the growth of applications on the Internet for commerce,
information, art, and entertainment attracted commercial, legal, governmental, and other communities
whose values and processes differ from those of the early Internet culture. Their arrival led to the
development of a vigorous market for domain names and of a variety of mechanisms to deal with fair
allocation of the now economically valuable domain names. Not surprisingly, throughout these
developments there has been a continuing tension between the technical community and the public
interest community about the proper goals and mechanisms for the allocation of domain names and the
management of the DNS.
As domain names have gained economic value, so, too, has their owners' desire grown for
opportunities to publicize those names (as part of Web site and e-mail addresses) to potential users of the
corresponding Internet locations. Consequently, many search engines and other navigational services,
which originally provided a single listing of search results in the order of estimated relevance to the user's
query, now also give prominent placement to those willing to pay for it. As noted above, the search
engine industry faces a continuing challenge in finding the proper balance between the interests of the
users of search engines and the advertisers on them, against the backdrop of the ever present possibility of
government intervention.
1.4.4 Increasing Social Value
When the DNS was developed, there was a modest level of social, political, or cultural value
associated with specific domain names. As the Internet grew in size and evolved in use, it became a
primary medium for communication, commerce, information, art, and entertainment; accordingly, domain
names assumed greater social, political, and cultural significance as the memorable designators of the
Internet locations of political groups, cultural resources, and social activities. But as a result, the DNS
became entangled in issues of privacy versus accountability, freedom of expression versus national legal
restrictions, and the rights of producers of intellectual property versus those of its users.
In the future, the Internet can be expected to be even more widely used for interpersonal
communication, for the public expression of ideas, for access to information, for the development of
virtual communities around common interests, and for the production and distribution of art and
entertainment. It will be a major portion of the global social fabric, facilitating and/or controlling the flow
of information, expression, art, and entertainment. Until or unless the DNS is replaced, the signs
designating the location of information, art, entertainment, viewpoints, and services will continue to
depend on domain names.
For that reason, it will be essential to sustain the DNS as the reliable signposting infrastructure of
the Internet, facilitating the Internet's use as a medium of free and open communication reaching all
corners of the globe, while balancing privacy, freedom of expression, property rights, cultural mores, and
national laws. As a result of the Internet's increased social value, the desire to navigate freely across it can
also be expected to encounter legal, commercial, cultural and political challenges that will pose issues
about the appropriate balance among rights, freedoms, mores, and laws.
1.4.5 Internationalization
When the DNS was developed, the Internet's geographic scope was limited primarily to North
America, parts of Western Europe, and a few countries on the Pacific Rim. And it was operated by a
loose confederation of bodies and individuals, primarily in the United States, most of whom had received
substantial support from the U.S. government. As use of the Internet has spread beyond its initial sites to
1-9
Prepublication Copy--Subject to Further Editorial Correction
encompass every continent and region and almost all nations, the network has responded successfully.
But internationalization has posed two specific challenges for the DNS.
First, until recently domain names have been limited to strings of Roman letters, Arabic numbers,
and the hyphen, a subset of the ASCII20 character set. However, the native languages of an increasing
number of Internet users employ different character sets. Recently, following years of work, a means of
enabling presentation of internationalized domain names (domain names encoding other character sets
into ASCII characters) has been adopted. It should become an important facilitator of Internet access and
use for those communities.21
And, second, although ICANN has international participation, its authority rests on a contract
from the U.S. Department of Commerce, which is perceived by some as undercutting its legitimacy as a
representative of the international community. That concern may increase as the economic and social
value of the DNS as the critical signposting infrastructure of the Internet continues to grow.22
Although the DNS is only now moving toward presentation of non-ASCII scripts in domain
names, Internet content in most important applications, including e-mail and the Web, has been
internationalized for well over a decade. Most Internet navigation services have incorporated the
capability to search in multiple languages. For example, in November 2004 the Google search engine
supported searches in over 100 languages and dialects and provided a customized version of the search
interface for 103 different nations.23 At the same time, the Yahoo! directory and search service offered
portals customized for 32 national and/or language groups.24 Since the navigation services are provided
by a variety of organizations in an open forum, they are less subject to concerns about the
internationalization of their governance. However, as their importance as the principal means of access to
the Internet grows, they may well come under pressure from those who believe that in one aspect of their
service or another, they do not adequately take into account the concerns or interests of certain nations,
ethnic groups, or linguistic communities.
1.5 INTERNET NAMING AND NAVIGATION
Owing to the five forces outlined above, Internet naming and navigation have become matters of
broad concern throughout the world. Those concerns are given voice by the large number of competing
interest groups that now take a vigorous interest in the DNS and, to a somewhat lesser degree, Internet
navigation.
Product and service providers compete for named locations on the Internet and have a strong
interest in the means for setting up new regions and allocating named locations in them. Internet users
have a complementary interest in being able to find the information or service they want wherever it may
be located, even as the Internet continues to grow in size and in diversity. All cultures have an interest in
being able to name locations and access and navigate the Internet in their native languages. Trademark
holders have an interest in protecting their rights in names from being infringed. Nations and their
citizens want assurance that their interests will be treated fairly and their needs supported by the
institutional frameworks that affect the Internet's naming and navigation infrastructures. The Internet
20 The American Standard Code for Information Interchange (ASCII) was originally developed for use with
teletype. It was extended by IBM to represent 256 characters and has become a de facto standard.
21 Internationalized domain names (IDNs) have recently been approved by ICANN for use by registries with which
it has agreements. See "Standards for ICANN Authorization of Internationalized Domain Name Registrations in
Registries with Agreements," posted March 13, 2003, on the ICANN Web site, <http://www.icann.org>. See
Section 4.4 for a more complete discussion of this subject and more extensive references.
22 Changes in ICANN's organizational structure and decision processes responded to this concern, although debate
continued into 2004 about the effectiveness of those changes. See Sections 5.1 and 5.2 for an extended discussion
of this issue.
23 For a listing see <http://www.google.com/language_tools?hl=en>.
24 For a listing see <http://world.yahoo.com/>.
1-10
Prepublication Copy--Subject to Further Editorial Correction
technical community wants to ensure that everything is done to improve and nothing is done to
compromise the reliability, security, and stability of the Internet itself. Individuals also want to be certain
that neither their access nor their rights will be unduly affected by the actions of the other groups. The
interaction among these various interests in naming and navigating the Internet--a global infrastructure
that is undergoing rapid growth in scale while absorbing continual technological change--raises
important issues that lie at the intersection of technology, economics, public policy, law, and user
behavior.25
This report addresses those issues from a specific perspective, that of the Domain Name System.
Navigation across the vast and multifaceted complex of human activity connected through the Internet is
a subject that warrants a major report in its own right. It is too large, in its full richness, to fit within a
report that was initiated to address significant questions about the future of the DNS. Yet, at the same
time, navigation is so intertwined with the present and future of the DNS that it cannot be completely
absent. Consequently, this report concentrates on navigation over the Internet primarily in its
relationships with the DNS. Even under that constraint, however, it is necessary to introduce fundamental
issues of Internet navigation to provide a background for the more circumscribed examination of its
interrelationships with the DNS.
The DNS interrelates with navigation across the Internet in five ways.
First, the DNS plays a direct navigational role by providing the IP address of a World Wide
Web site, an e-mail server, or another network host or resource whose domain name is known, or can be
guessed.
Second, the DNS serves as an enhancer of navigation because many navigation services
return locators incorporating the domain names of relevant Web sites. These names usually provide more
(although not necessarily reliable) information to the user about the provider whose location has been
returned than just the IP address or a blank link would.
Third, navigation services complement the DNS by, for example, enabling navigation to Web
sites whose domain names are not known by the user or by enabling searches within sites that have been
reached by use of their domain names.
Fourth, navigation services relieve some of the pressure on the Domain Name System by
reducing the need for a site to have a short memorable name in order to be found. It appears that efforts
and funds spent in previous years to obtain desirable domain names are now being diverted to some
degree to efforts and expenditures to ensure a presence and high ranking in the results of search engines
or directories.
Fifth, navigation services could, in the extreme, substitute entirely for the Domain Name
System on the Web because they could directly return IP addresses. However, as noted above, this
approach would deprive the user of any information about the provider contained in the domain name. It
would also deprive the provider of the marketing value of the domain name. And it would eliminate the
use of domain names as stable identifiers of Internet resources whose IP addresses change, which was one
of the original motivations for the creation of the DNS.
Of these five roles, it is the third and fourth--navigation as a complement to and a relief for the
DNS--that are the focus of this report's examination of Internet navigation.
1.6 OBJECTIVES OF THIS REPORT
This report is addressed to those who are or will be concerned with policies and practices that
affect the operation and evolution of the DNS and Internet navigation. That is a large audience. It
includes the technologists who research, design, implement, and operate the DNS and navigation systems;
25 See CSTB, NRC, The Internet's Coming of Age, 2001.
1-11
Prepublication Copy--Subject to Further Editorial Correction
the governmental policy makers and their staffs who establish, oversee, and operate the framework of
institutions and laws that govern or regulate those systems; the commercial and non-commercial
organizations that operate, manage, and use those systems; and the users and providers who depend on
those systems for access to and the accessibility of Internet locations.
During the time that this report has been in preparation, the DNS and Internet navigation have
seen many technical and institutional changes, some substantial, others modest; some controversial,
others agreeable; some likely to last, others temporary expedients that will eventually be replaced. Some
of the changes made have addressed the issues that gave rise to the initial request for this report. Clearly,
this study was not the proper vehicle to address those specific issues. However, it is equally clear that
many issues of similar character are or soon will arrive on the agendas of the policy, technical, provider,
and user communities. Yet those called upon to deal with policy and practices affecting the DNS and
Internet navigation often have little or no knowledge of the full complexity of those arenas. Those who
are engaged with the technology of these worlds do not always appreciate the nuances of the policy,
economic, and legal issues, while those experienced with the legal, economic, and policy aspects often are
largely unaware of the intricacies of the technology. The result is often a clash of cultures that inhibits
both effective policy making and desirable technological change. Both groups would benefit from having
a reliable source of information about the technologies and the institutions that control them, upon which
they can base reasonable and effective policies. And, where appropriate, they might also benefit from the
conclusions and recommendations of a broadly knowledgeable committee that has spent several years
reviewing the two worlds.
Therefore, this report, which is the result of extensive and collaborative work by a committee
whose members are drawn from both the technology and the policy communities, is intended to serve five
objectives:
1. To provide a thorough and objective description and assessment of the Domain Name
System--both its technology and the institutional framework within which that technology operates;
2. To describe and analyze alternative approaches to the principal technology prospects and
institutional issues that are likely to affect the future of the DNS;
3. To provide a thorough and objective description and assessment of Internet navigation, with
sufficient background information to provide context;
4. To describe and analyze alternative approaches to some of the technology prospects and
institutional issues that are likely to affect the future of Internet navigation; and
5. To present conclusions and make recommendations where it was possible for the committee
to reach agreement--in any case, to characterize the range of alternative views.
This report has been structured to respond to those objectives.
1.7 ROADMAP FOR THIS REPORT
This report is divided into three parts. The DNS is the subject of the first, consisting of Chapters
2, 3, 4, and 5. Internet navigation in its relationship to the DNS is the subject of the second, consisting of
Chapters 6, 7, and 8. Chapter 9 summarizes the interaction between the DNS and Internet navigation.
Because the options for moving forward are partially constrained by the decisions taken along the
path to the present, the first part begins with a careful review of the development of the Domain Name
System. Chapter 2 examines the evolution of the technical design of the DNS and its associated
operational, administrative, and governance mechanisms. It describes the sequence of important technical
decisions and innovations, as well as the new governance and administrative mechanisms that have been
introduced in response to the Internet's rapid growth. Several of the early technical decisions, taken at the
time of restricted use of internetworks by specialized groups, still constrain the DNS.
1-12
Prepublication Copy--Subject to Further Editorial Correction
Chapter 3 describes the current state of the DNS, considering both the technical system, which
performs the linkage of domain names with IP addresses and associated data, and the higher-level
institutional framework, which carries out operational, administrative, and policy-setting functions
essential for the DNS to function. It explains and evaluates the operation of the DNS technical system
and identifies and assesses each of the functions carried out by the highest levels of the institutional
framework.
Chapter 4 describes the prospective technologies that can respond to the challenges the DNS
faces from malicious attacks, the growing intersection of the telephone system and the Internet, the need
to internationalize the name system, and the need to regulate the introduction of potentially disruptive
new services. Chapter 5 deals with the key institutional issues facing the DNS: governance of the DNS
itself, oversight of root operations, governance of the top-level domains, improvement of the dispute
resolution process, and improvement of the DNS's information service (called the Whois service).
The distinctive characteristics and historical development of Internet navigation, as it relates to
the DNS, are described in Chapter 6. The current state of navigation aids and services and the framework
of commercial institutions within which they operate are presented in Chapter 7. Chapter 8 addresses
some prospective technologies whose introduction, and a number of the institutional issues whose
resolution, can have a major influence on the future development of Internet navigation and its
relationship to the DNS.
Finally, Chapter 9 sums up the interaction between the DNS and Internet navigation.
Throughout the chapters on the DNS and Internet navigation, the committee's conclusions and
recommendations are incorporated into the text where appropriate.
The goal of this report is to clarify the sometimes controversial, often arcane, and frequently
uncertain issues concerning the signposting and navigational infrastructure of the Internet. The committee
hopes that by providing such clarification, this report will itself serve as a navigational aid to the policy
and technology communities as they find their way to decisions that will enable the Internet to remain an
efficient and reliable channel of global communication and commerce.
1-13
Prepublication Copy--Subject to Further Editorial Correction
2
The Emergence and Evolution of the Domain Name System
The Domain Name System (DNS) was designed and deployed in the 1980s to overcome
technical and operational constraints of its predecessor, the HOSTS.TXT system. Some of the
initial design decisions have proven to be extraordinarily flexible in accommodating major
changes in the scale and scope of the DNS. Other initial design decisions constrain technical and
policy choices to the present day. Thus, an understanding of the system architecture and the
rationale for the design characteristics of the DNS provides the base for understanding how the
DNS has evolved to the present and for evaluating possibilities for its future. This chapter
outlines the origin and development of the DNS and describes its key design characteristics,
which include both technological and organizational aspects.1
2.1.
ORIGIN OF THE DOMAIN NAME SYSTEM
For the first decade or so of the ARPANET,2 the host3 table file (HOSTS.TXT) served as
its directory. HOSTS.TXT provided the network address for each host on the ARPANET,4 which
could be looked up by using the host's one-word English language name, acronym, or
abbreviation. The Network Information Center (NIC) at the Stanford Research Institute5
managed the registration of hosts and the distribution of the information needed to keep the
HOSTS.TXT file current. The list of host names and their mapping to and from network
addresses was maintained in the frequently updated HOSTS.TXT file, which was copied to and
stored in each computer connected to the ARPANET. Thus, HOSTS.TXT6 was introduced to:
Simplify the identification of computers on the ARPANET. Simple and familiar
names are much easier for humans to remember than lengthy (12-digit) numeric strings; and
1 A general presentation of the history of the Internet is beyond the scope of this report. One source of
documentation on the Internet's history is available at <http://www.isoc.org/internet/history/>.
2 The Internet grew out of the ARPANET project (funded by the Defense Advanced Research Projects
Agency (DARPA), which was known as ARPA for a period of its history); for many years the ARPANET
served as the core of the Internet.
3 A host is the primary or controlling computer in a network.
4 These network addresses could be represented using the Internet Protocol (IP) format or in the equivalent
(now unused) ARPANET Network Control Protocol (NCP) format. The current version (v4) of IP
represents addresses using 32 bits, usually expressed as four integers in the range from 0 to 255, separated
by dots. An example of an IP address is "144.171.1.26."
5 Stanford Research Institute became known as SRI International in 1977.
6 For further discussion, see "Host Names On-line," Request for Comments (RFC) 606, L. Peter Deutsch,
December 1973; "Hostnames Server," RFC 811, Ken Harrenstien, Vic White, and Elizabeth Feinler,
March 1982; and "DOD Internet Host Table Specification," RFC 952, Ken Harrenstien, M. Stahl, and
Elizabeth Feinler, October 1985, all available at <http://www.rfc-editor.org/rfc.html>. RFCs are created to
document technical and organizational aspects of the Internet. The Internet Engineering Task Force (IETF)
manages the process for discussing, evaluating, and approving RFCs. For a discussion of the role of the
DNS more generally, see "Role of the Domain Name System," RFC 3467, John C. Klensin, February 2003.
2-1
Prepublication Copy--Subject to Further Editorial Correction
Provide stability when addresses changed. Since addresses in the ARPANET are a
function of network topology and routing,7 they often had to be changed when topology or
routing changed. Names in the host table could remain unchanged even as addresses changed.
The HOSTS.TXT file had a very simple format. Each line in HOSTS.TXT included
information about a single host, such as the network address, and when provided, system
manufacturer and model number, operating system, and a listing of the protocols that were
supported.
Because a copy of the host table was stored in every computer on the ARPANET, each
time a new computer was added to the network, or a change was made, the entire table had to be
updated at every computer on the network for the new machine or location to be recognized.8 As
increasing numbers of computers joined the ARPANET, the updating task became more and
more burdensome and subject to error and failure, and, as a consequence, several major problems
developed from the use of the HOSTS.TXT file:
Failure to scale. As the ARPANET started to grow rapidly, it became clear that the
centralized HOSTS.TXT file failed to scale in two ways. First, the volume of updates threatened
to overwhelm the NIC staff maintaining HOSTS.TXT. Second, because every system needed to
have an up-to-date copy of HOSTS.TXT, announcement of a new copy of HOSTS.TXT meant
that the NIC server where the current version of HOSTS.TXT was stored was inundated with
attempts to download the file. Moreover, the download problem was aggravated because
HOSTS.TXT kept getting bigger. In short, more hosts on the network meant more updates, more
hosts trying to download, and more data to download.
Inadequate timeliness. It often took several days to get a new host listed in
HOSTS.TXT while the NIC staff processed the request to add the host entry. Until it was listed
and communicated, the host was effectively invisible to the rest of the ARPANET. In a
community already becoming accustomed to getting data instantly over the network, this delay
was a source of frustration. Similarly, correcting an error often took a few days, because fixes to
any errors were not generally available until the next HOSTS.TXT file was released--which
caused further frustration. The maintainers of some hosts also did not update their copies of the
table at very frequent intervals, resulting in those hosts having obsolete or incomplete information
even when the master copy of the table was up-to-date.
Susceptibility to failure. The system had multiple ways to fail. Probably the most
famous outage occurred when the NIC released a version of HOSTS.TXT that omitted the entry
for the system where the HOSTS.TXT file was stored. When the subsequent HOSTS.TXT file
was released, most systems could not download it, because they could not look up the relevant
host name! There were also cases where partial tables were inadvertently released. Furthermore,
seemingly innocuous additions to HOSTS.TXT could cause the programs that converted
HOSTS.TXT into local formats to fail.
Name conflicts. The HOSTS.TXT name space was flat, which meant that host names
had to be unique. Popular host names such as FRODO were selected first, and so some people
had to invent alternate names for their systems.
The emergence of these problems caused technologists to develop a new, distributed,
method for managing the mapping of names to addresses.
7 Routing refers to the way data flow on the ARPANET. Data transmitted from point A to point B may
traverse many different paths, or routes, on the ARPANET. Note that the ARPANET, as the original
network to employ the Internet Protocol (IP), is often referred to as "the Internet," although the term later
formally encompassed the aggregate of interconnected IP-based networks.
8 It was the obligation of individual network and host operators to download the latest HOSTS.TXT file to
their machines.
2-2
Prepublication Copy--Subject to Further Editorial Correction
2.2.
DESIGNING THE DOMAIN NAME SYSTEM
In the early 1980s, research on naming systems--systems for associating names with
addresses--was underway and a few prototype naming systems had just been developed, most
notably the Grapevine and Clearinghouse systems at the Xerox Palo Alto Research Center
(PARC).9 Also in progress at this time was preliminary work on other computer network
addressing standards such as X.400.10 Because of the uncertainty as to whether these research
and development efforts would yield in the near term an operational system with the required
functionality and needed scale, Internet researchers elected to develop their own protocols.
In August 1982, Zaw-Sing Su and Jon Postel authored "The Domain Naming Convention
for Internet User Applications," Request for Comments (RFC) 819, which described how Internet
naming should be changed to facilitate a distributed name system. This document envisioned that
Internet names would be organized into logical hierarchies, represented by text components
separated by a period (".") (thus the existing host "ISIF"--host computer "F" at the Information
Sciences Institute (ISI)--would become F.ISI), and that the various parts of the name as assigned
(i.e., the parts delimited with periods) would be managed by different network servers. RFC 819
specified only how names would be represented--the details of how the management of various
parts of assigned names would take place operationally by the different network servers remained
to be determined.
In November 1983, Paul Mockapetris authored "Domain Names--Concepts and
Facilities" (RFC 882) and "Domain Names--Implementation and Specification" (RFC 883),
which specified a set of protocols, called the Domain Name System, that implemented the
hierarchical name space proposed by Su and Postel. Reflecting the discussions of the previous
several months on the electronic mail list Namedroppers, the proposed DNS supported more
sophisticated services and features than simply converting host names to addresses (e.g., the
proposed system would provide a way to map a name to different addresses, depending on the
purpose for which an inquiry was being made). With some modest changes, the proposed
protocols are exactly those in use two decades later.
Conceptually, the DNS is implemented through a distributed and hierarchical series of
tables, linked like the branches of an inverted tree springing from a single, common root. When
an address is sought, the search proceeds successively from the table at the root (or "top") of the
tree to successive branches and leaves, or "lower tables," until the table that holds the desired
address is found. For a particular query, only the last table in the search serves as a "white pages
directory." All of the other tables serve as "directories of directories," each one pointing to lower
level "directories" on a path to the one holding the desired address. Thus, the entries in a table at
any given level of the tree can include pointers to lower-level tables as well as final network
addresses. See Figure 2.1.
When a change is made in the network, only the table directly affected by that change
must be updated and only the local organization (e.g., the system administration function in a
university or corporation) responsible for that table needs to make the update. As a result, the
work of registering changes is distributed among many organizations, thus reducing the burden
each must carry.
9 See Andrew D. Birrell, Roy Levin, Roger M. Needham, and Michael D. Schroeder, 1982, "Grapevine: An
Exercise in Distributed Computing," Communications of the ACM 25(4):260-274.
10 The International Organization for Standardization and the International Telecommunication Union
endorsed X.400 as a standard that describes a messaging service (e.g., electronic mail). The first version of
X.400 was published in 1984 by the Comité Consultatif International Téléphonique et Télégraphique
(CCITT), which is now the International Telecommunication UnionTelecommunication Standardization
Sector (ITU-T)).
2-3
Prepublication Copy--Subject to Further Editorial Correction
The DNS naming syntax corresponds to the levels in the hierarchical tree. Each node in
the tree has a name that identifies it relative to the node above it. The highest level, the "root
node," has the null name. In text it is written as a single dot (".") or simply implied (and thus not
shown at all). Each node below the root is the root of another subtree, a domain, that can in turn
be further divided into additional subtrees, called subdomains. Each subdomain is written in text
to include its name and the subdomains above it in the applicable hierarchy. In
Figure 2.1, .com, .org, and .edu are top-level domains (TLDs) and cstb.org, mit.edu,
and ibm.com are subdomains of the TLDs, often called second-level domains. The third-level
domain, lcs.mit.edu, is a subdomain within the mit.edu second-level domain.
The DNS name of a computer is the name of its node or end point in the Domain Name
System. Thus, frodo.lcs.mit.edu would be the computer (or device) named "frodo" that
is located within the lcs.mit.edu subdomain of the mit.edu second-level domain within
the .edu TLD. On the other hand, myownpersonalcomputer.com (without any further
subdomains) could point directly to a particular computer.
Applications, such as Web browsers and e-mail software, use domain names as part of
the Uniform Resource Identifiers (URIs) or other references that incorporate information about
the protocols required for communication with the desired information source. Examples of URIs
are http://www.national-academies.org and mailto:someperson@example.com. In the first
example, "http" refers to the Hypertext Transfer Protocol (HTTP) used for communication with
sites on the World Wide Web. In the second example, a particular user at the host identified by
"example.com" is identified as the addressee for electronic mail.
In terms of information technology, the Domain Name System is implemented through a
series of name servers that are located at each of the nodes in the hierarchy. Each name server
contains a table that indicates the locations of the name servers immediately below it in the
hierarchy and the portion of the hierarchy for which it contains the final (authoritative) network
addresses. Thus, the root name servers (at the top of the hierarchy) contain the locations of each
of the name servers for the top-level domains.11 At any given node, such as .com or ibm.com,
there are expected to be multiple (physical) name servers at different Internet Protocol (IP)
addresses, each with identical information; the purpose of this redundancy is to share the
workload to ensure adequate system performance.
When a user wants to reach www.national-academies.org, his or her computer
usually sends a message to a nearby name server (usually local or operated by the user's Internet
service provider), where software (called a resolver), in conjunction with other name servers and
resolvers, performs a series of queries to find the name server that is authoritative for
www.national-academies.org. That server is then queried for the corresponding IP
address(es) and returns the resulting address(es) to the user's computer.12
11 Each of these root name servers contains identical information; the purpose of having multiple root name
servers is to distribute the query workload and ensure reliable operation. Specifics concerning the root
name servers are discussed in Chapter 3.
12 The summary provided in this paragraph is quite simplified; there are many discrete technical processes
that are not articulated here. See Chapter 3 for a more detailed explanation.
2-4
Prepublication Copy--Subject to Further Editorial Correction
"." root
.org
.com
.edu
mit.edu
icann.org
cstb.org
ibm.com
lcs.mit.edu
frodo.lcs.mit.edu
FIGURE 2.1 The hierarchical Domain Name System inverted tree structure.
2.2.1. Simple, Mnemonic, and Deeply Hierarchical Names
As indicated above, domain names were intended to enable a more convenient and
efficient way of referring to IP addresses and other information, using a simple taxonomy. The
early DNS included eight generic top-level domains (gTLDs): .edu (higher education
institutions--most of which were based in the United States), .gov (U.S. government), .mil
(U.S. military), .com (commerce), .net (network resources), .org (other organizations and
persons13), .int (international treaty organizations) , and .arpa (network infrastructure). In
addition, country-code top-level domains (ccTLDs) were created based on the two-letter code set
(e.g., .gh for Ghana or .au for Australia) in the ISO 3166-1 standard.14
Despite the ability of the protocols and data structures themselves to accommodate any
binary representation, DNS names were historically restricted to a subset of the ASCII character
set.15 Selection of that subset was driven in part by human factors considerations, including a
desire to eliminate possible ambiguities in an international context. Hence, character codes that
had international variations in interpretation were excluded; the underscore character (too much
like a hyphen) and case distinctions (upper versus lower) were eliminated as being confusing
when written or read by people; and so on. These considerations appear to be very similar to
13 Initially, the .org TLD was intended as the category for organizations and individuals that did not fall
into any of the other categories. Through time, many individuals increasingly viewed .org as
representing the domain name space for non-profit organizations.
14 Thus, the determination of what constitutes a country did not need to be addressed by those who
administer the DNS. See <http://www.iso.org/iso/en/prodsservices/iso3166ma/index.html>.
15 This subset, which derives primarily from the original HOSTS.TXT naming rules, includes the 10 Arabic
digits, the 26 letters of the English alphabet, and the hyphen.
2-5
Prepublication Copy--Subject to Further Editorial Correction
those that resulted in similarly restricted character sets being used as protocol elements in many
International Telecommunication Union (ITU) and International Organization for Standardization
(ISO) protocols.
Another initial assumption behind the design of the DNS was that there would be
relatively many physical hosts for each second-level domain name and, more generally, that the
system would be deeply hierarchical, with most systems (and names) at the third level or below.
Some domains--those of most universities and some large corporations and the country code for
the United States (.us)--follow this model, at least in its original design, but most do not16 (see
Chapter 3 for discussion). However, experience through the year 2004 has shown that the DNS is
robust enough--given contemporary machines as servers and current bandwidth norms--to
operate reasonably well even though the design assumption of a deep hierarchy is not satisfied.
Nonetheless, it is still useful to remember that the system could have been designed to work with
a flat structure (e.g., the huge, flat structure under .com comprising tens of millions of names)
rather than a deeply hierarchical one. For example, based on an assumption of a flat structure at
the TLD level, one would probably not wish to assign specific operational responsibility by TLD
(as is the case currently). Instead, it might have made more sense to design the system as one
database that is replicated on a limited number of servers (to share the workload and coordinate
updates in a manageable way).
2.2.2. Experimental Features
The DNS specification included a number of experimental features, intended to enhance
the services that the DNS could provide beyond simple name-to-address lookup. Several of these
features were intended to facilitate improved support of electronic mail. Several resource
records17 were intended to improve e-mail routing, helping to ensure that e-mail sent to a
particular host took a reliable route to that host. The DNS also included features intended to
support e-mail lists and aliases. The idea was to make it easier to maintain mailing lists and to
forward mail when someone's e-mail address changed. In addition, the DNS contained a feature
to track "well-known services." The purpose of this feature was to provide a list of services (e-
mail, File Transfer Protocol, Web) that are available from a host. Most of the experimental
features have not been adopted for general use. Indeed, the original set of e-mail-related record
types were deprecated in favor of a newer model (see Section 2.3.3) and the "well-known
services" record was determined to be unworkable.
2.3.
DEPLOYING THE DOMAIN NAME SYSTEM
Whereas the design of the DNS looked reasonable on paper, several limitations of the
new system, as with any new system, did not become apparent until initial deployment began.
Addressing these limitations caused a delay in the full implementation of the DNS. The plan
called for a switchover to the DNS in September 1984, but full conversion did not take place until
16 The .us country code TLD was designed originally to use geographical and political jurisdictions as
subdomains. As one moves to the left, each subdomain represents a subset of the area represented by the
immediately preceding name. For example, in the name www.cnri.reston.va.us, "va" represents
the state of Virginia within the United States, "reston" represents a city within Virginia, and "cnri"
represents an organization in the city of Reston.
17 Each table within the domain name tree hierarchy contains resource records, which are composed of
fields such as the type (i.e., does this record correspond to a host address, an authoritative name server, or
something else) and time to live (i.e., for what period of time may this record be cached before the source
of the information should be consulted again?). See Box 3.2 for detailed discussion of resource records.
2-6
Prepublication Copy--Subject to Further Editorial Correction
1987. Some of the delay was attributable to reconciling naming conflicts.18 A large part of the
delay derived from a far longer than expected period to implement and debug the DNS, of which
a significant portion derived from simple procrastination--just not getting around to installing
and implementing the DNS. Another delay included the difficulty of retrofitting the DNS into old
operating systems that were no longer actively maintained.
2.3.1. Caching
The design of the DNS allows for the existence of caches. These are local data storage
and/or memory that can significantly reduce the amount of network traffic associated with
repeated successful queries for the same data by providing access to the data in servers closer to
the end user than the authoritative name server.19 The data in these caches need to be refreshed at
regular intervals20 to ensure that the cached data are valid. In the initial version of the DNS
specification, several timing parameters had time-to-live limits of approximately 18 hours. It
quickly became apparent, however, that in many cases data changed slowly, and so updating
caches every 18 hours or so was unnecessary. As a consequence, the protocol specification was
changed to increase the allowed range of these timing parameters; several other protocol
parameters were also given expanded ranges, based on the theory that one incompatible protocol
change early on would be better than a series of such changes. This happened early enough that
there was no serious difficulty in deploying upgraded software.
In its original design, the DNS did not have a corresponding mechanism for reducing the
network traffic associated with repeated unsuccessful queries (i.e., queries for which no entry in
the relevant authoritative table is found). Within a few years of the initial implementation of the
DNS, it became apparent that such a mechanism would be beneficial, given the number of
identical queries that are unsuccessful. A proposed mechanism for negative response caching
was developed, and the data necessary to support it were added to the protocol in a way that did
not affect software based on earlier versions of the protocol, but the full deployment of the new
mechanism was slow. The name server side of the new mechanism was very simple and was
deployed fairly quickly, but initial support for the client (user) side of the negative caching
mechanism was limited to a few implementations and was not adopted more generally until much
later. The lack of widespread and correct client-side support for negative caching is a problem
that still persists.21
2.3.2. Lookup Timeouts
The biggest single difficulty in the transition from HOSTS.TXT to the DNS, however,
was not due to any specific shortcoming of the DNS. Rather, it was attributable to the
fundamental change in the nature of the lookup mechanism. In the HOSTS.TXT world, any
particular host lookup operation would either succeed or fail immediately--the HOSTS.TXT file
18 Most or all of these conflicts were internal ones--for example, subunits of a university trying to obtain
the same domain name as the university.
19 An additional potential benefit from the use of caches is an improvement in user response time.
20 As defined in the time-to-live field in the resource records. See Chapter 3.
21 Users derive benefits from the implementation of negative caching, namely faster response times. The
larger system also derives benefits through the reduced load of invalid queries. However, there are costs
associated with the implementation and maintenance of negative caching. For a given user, if the estimated
benefit deriving from faster response times is deemed to be worth less than the costs associated with
negative caching, then the user is not likely to implement negative caching, even though the total benefits
(which include the reduced load of invalid queries on the larger system) may exceed these costs. This
phenomenon is explained under the rubric of what economists refer to as externalities.
2-7
Prepublication Copy--Subject to Further Editorial Correction
is located on the user's system; it is not dependent on Internet connectivity at the moment of
lookup. The DNS added a third possible outcome to any lookup operation: a timeout attributable
to any of a number of possible temporary failure conditions (e.g., the required name server is
down, so one does not know whether the particular name is indeed in the table or not). The
occurrence of a timeout indicates neither success nor failure; it is the equivalent of asking a yes or
no question and being told "ask again later." Many of the network programs that predated the
DNS simply could not handle this third possibility and had to be rewritten. While this was
something of a problem for programs intended to be run directly by a user (e.g., one then-popular
e-mail client checked the host name of every recipient during composition), it was a far more
serious problem for programs that ran unattended, such as mail transfer agents. These programs
had to be rewritten to handle DNS timeout errors in the same way as they would handle any other
form of connection failure. Conceptually, this was simple enough, but it took several years to
actually track down and fix all the places in all the programs that made implicit assumptions
about the host lookup mechanism. Toward the end of this period, the Internet had entered an era
of periodic "congestion collapses" that eventually led to a fundamental improvement in certain
algorithms used in the Internet infrastructure. During each of these congestion collapses, DNS
lookups (along with all other forms of Internet traffic) frequently timed out, which made it much
more obvious which applications still needed to be converted to handle timeouts properly. To
this day, however, correct handling of the possibility of timeouts during a DNS lookup represents
an issue in application design.
2.3.3. Convergence in Electronic Mail Systems
In the mid-1980s, the Internet was one of the major data networks.22 Although data could
not move from one network to the next, e-mail was able to flow--through carefully designed e-
mail gateways--between the networks. Some of the busiest computers on each network were the
machines whose job it was to relay e-mail from one network to the next.23 Unfortunately, the
system of gateways required users to route their e-mail by explicitly using the e-mail address.
For instance, to send e-mail over the Internet to a colleague at Hewlett Packard Laboratories on
the Computer Science Network (CSNET), one had to address the e-mail to
colleague%hplabs.csnet@relay.cs.net. This complex syntax says that the Internet should deliver
the e-mail to relay.cs.net and then send the message on to the appropriate address on cs.net.24
Thus, some people had one e-mail box yet had business cards listing three or four different ways
to send e-mail to them. There were ample opportunities for confusion and mis-routed e-mail.25
The original DNS specification tried to address this problem by making it possible to
send e-mail to names that were not connected to the Internet. For instance, if the Example
Company was on the UUCP network, but wanted to exchange e-mail over the Internet, it could
22 These major data networks included BITNET, Internet, CSNET, UUCP, and Fidonet. See The Matrix:
Computer Networks and Conferencing Systems Worldwide (1990), John S. Quarterman, Bedford, Mass.:
Digital Press; and !%@: A Directory of Electronic Mail Addressing and Networks, 1991, Donnalyn Frey,
Buck Adams, and Rick Adams, Sebastopol, Calif.: O'Reilly and Associates.
23 For instance, relay.cs.net and seismo.css.gov, the e-mail gateways between the Internet and the Computer
Science Network, and an important one of those between the Internet and the Unix-to-Unix network,
respectively, were typically the top two hosts (in terms of traffic sent or received) on the ARPANET in the
mid-1980s.
24 In some instances, the messages were even messier; someone on the Unix-to-Unix network (UUCP),
might have to write an address such as <ihnp4!seismo!colleague%hplabs.csnet@relay.cs.net> to send an e-
mail.
25 For instance, at Princeton University there was a weekly tape swap between the operators of
princeton.bitnet and princeton.csnet--two machines on different networks that routinely got mail
accidentally intended for the other.
2-8
Prepublication Copy--Subject to Further Editorial Correction
register Example.com and place an entry in the DNS directing that all e-mail to names ending
Example.com should be forwarded to the UUCP e-mail gateway, which would know to forward
the e-mail to the Example Company's e-mail hub.
Unfortunately, the original DNS scheme for e-mail routing was not up to the task. It did
not handle certain types of e-mail routing well, and, worse, it could cause e-mail errors that
resulted in lost e-mail.
The result was a new scheme using Mail eXchangers (MXs) so that, for any domain
name, the DNS would store a preferentially ordered list of hosts that would handle e-mail for that
name. The rule is to start with the most preferred host in the list and work down the list until a
host is found that will accept the e-mail.26 This simple rule could be combined with the DNS
facility for wildcarding (following rules that state that all names ending in a particular domain, or
that a particular subset of names ending in a name, should all get the same response)27 to create e-
mail routing for almost any desirable situation. In particular, it was possible to address e-mail to
domains that were off the Internet, or domains that were partly on and partly off the Internet.
The development of a dependable and highly flexible mechanism for routing Internet e-
mail had two almost immediate consequences. First, all the other major e-mail networks
converted to using domain names or names that looked like domain names.28 These other
networks all had non-hierarchical (i.e., flat) name spaces, with many of the same scaling
problems that were experienced with HOSTS.TXT, and were looking for a workable hierarchical
name space. Once it was shown that the DNS would work for e-mail, it was simpler for
companies to adopt domain names and, in some cases, adapt the DNS to run on their networks
rather than to devise their own naming scheme. Thus, within a matter of 18 months to 2 years,
the Babel of e-mail addresses was simplified to user@domain-name, almost everywhere in the
world. A second effect was that companies could now change networks without changing their
host names and e-mail addresses, providing incentives for some companies to make the switch to
the Internet. Indeed, by 1990, almost all the networks that had offered services comparable to the
Internet were either gone or going out of business.29 Around the same time, companies began to
26 See "Mail Routing and the Domain Name System," RFC 974, Craig Partridge, January 1986.
27 For example, in the early days of e-mail connectivity to much of Africa, e-mail hubs were set up inside
the countries, serving all users there. These hubs did not have direct Internet connectivity to the rest of the
world but were typically served through occasional dial-up connections that, in turn, usually used non-
TCP/IP connections. To facilitate this arrangement, the DNS was set up so that all traffic for, say, South
Africa (the .ZA ccTLD), regardless of the full domain name, would be routed to a mail-receiving system in
the United States. That system would then open an international dial-up connection at regular intervals and
transfer all mail over it. The mail hub in South Africa would then distribute the mail to other hubs within
the country, often using the originally specified domain as an indication of the appropriate domestic server.
This model had the added advantage that, when permanent connectivity became available, user and
institutional e-mail addresses and domain names did not need to change--users just saw a dramatic
improvement in service and turnaround time. More information on the history of this strategy may be
found at <http://www.nsrc.org/> and in John C. Klensin and Randy Bush, "Expanding International E-mail
Connectivity: Another Look," Connexions--The Interoperability Report 7(8), August 1993, pp. 25-29;
available at <http://www.nsrc.org/articles/930600.connexions>.
28 For convenience and as a transition strategy, many sites chose to treat, for example, "BITNET" and
"UUCP" as if they were top-level domain names, mapping those names through the DNS or other facilities
into gateway paths. So a generation of users believed that, for example, smith@mitvmb.bitnet was an
Internet domain name when, in fact, it was mapped to smith%mitvmb.bitnet@mitvma.mit.edu, where the
latter was a gateway between the Internet and BITNET. The full use of MX records, so that the same user
could be addressed as smith@mitvmb.mit.edu, came along only somewhat later.
29 In economics, network effects (or, alternatively, positive network externalities) explain the rationale for
the convergence to Internet-based e-mail: The value of a network to a user increases as more users join the
same network, or other networks that are compatible with it. See, for example: Jean Tirole. 1988. The
Theory of Industrial Organization. Cambridge, Mass., and London: MIT Press, pp. 404-409.
2-9
Prepublication Copy--Subject to Further Editorial Correction
encourage their employees to put e-mail addresses on business cards (it had often been
discouraged because, as previously noted, e-mail addresses were so complicated). Domain names
thereafter became a (small) part of everyday business.
There were also some longer-term effects. First, it was very clear that the DNS could
provide names for things that were not hosts. For instance, almost every organization soon made
it possible to mail to someperson@example.com, even though there was no actual machine
named example.com, but rather a collection of servers (e.g., mailserver1.example.com,
mailserver2.example.com, and so on) that handled e-mail for the example.com domain. The
DNS began to be viewed as a general naming system. Second, because almost all naming
systems had been designed primarily to support e-mail, and domain names had won the battle for
how e-mail was done, the other naming systems diminished in importance and use, leaving the
DNS as the only widely available naming system. The result was that the DNS was viewed as a
general service, albeit an imperfect one: but even if imperfect, it was the only naming system that
was widely available, and thus it became the one of choice.
2.3.4. The Whois Database
The Whois database was developed in the 1970s to track authorized ARPANET users
and, in particular, those users that could request addresses on the network. For each host or
domain name, the information in the Whois database was supposed to include the contact
information (such as the contact person's name, organization, street address, electronic mail
address, and phone number) of those with responsibility for the host or domain name; additional
information could also be stored and accessed. From a technical design and operational
viewpoint, the Whois database is independent of either the HOSTS.TXT file or the DNS.30 For a
while, the Whois database, maintained by the Network Information Center (NIC), served as a de
facto white pages directory of ARPANET users. Beyond the online database, the NIC printed a
phone book of everyone listed in the Whois database about once a year until 1982.
Around the time of the last NIC phone book, the Whois database was rapidly losing its
value as a white pages directory because many new Internet users were not being included in the
database. However, at the same time, the Whois database was becoming increasingly important
for network operations because the NIC (which at the time also managed the allocation of IP
addresses) would not give out an IP address, a host name, or a domain name to anyone who did
not have a Whois entry. Furthermore, the NIC put all address and name registrations into the
Whois database. So, given a host name or address, any user on the network could query the
database to learn who had control of that host name or address. Thus, if a network operator
noticed (or had a user complain) that a domain name suddenly could not be looked up, or that a
particular network appeared to be unreachable, the operator could query the Whois database and
find out whom to call about the issue.
By the late 1980s, problems began to develop with the Whois database. The first
problem, which proved easy to solve, was that in many cases the formal institutional contact for
the name or address was a corporate or university officer or administrator and was not the
network operations person who actually operated the network or domain name server. The NIC
resolved this problem by updating the database to keep track of both the administrative and
operational contact for each address and domain. The second problem, which was not so easy to
30 "Whois" represents both the name of the implemented system/database as well as the name of the
underlying protocol. This caused, and continues to cause, some confusion since several universities and
enterprises maintained local "white pages" and similar services, which had nothing to do with the central
databases, that were accessed using the Whois protocol.
2-10
Prepublication Copy--Subject to Further Editorial Correction
solve, was trying to keep the Whois data current--a problem that existed even before the
explosive growth of the Internet and demands on the DNS in the 1990s.31
2.3.5. The DNS as a Production System
By 1990, the DNS was a production system and deeply ingrained in the Internet and its
culture.32 The use of HOSTS.TXT was declining rapidly. But the move to a production system
was not easy: Deploying the DNS in the 1980s required several years of debugging and resolving
various issues. Timeouts and negative caching remain, to some extent, open issues in 2005.
Several lessons are apparent from the process of developing and deploying the DNS. A
good new design that solves important problems can catch on, but it will take time for solid
implementations to be developed. And even if a new design offers significant advantages,
adoption will take time. Even when the Internet was comparatively small, switches from
HOSTS.TXT to DNS or from e-mail Babel to uniform naming took a significant amount of time.
Given the decentralized nature of the Internet, network service providers, hardware and software
vendors, end users, or others can inhibit worthwhile technical advances from being implemented
through mere procrastination or a deliberate decision that the implementation of a particular
software upgrade is simply not sufficiently beneficial to them. Given the much larger scale and
scope of the DNS and the embedded base of software two decades later, successful
implementation of any proposed new system or major changes to the existing DNS may prove
difficult.33
2.4.
CONTINUING GROWTH AND EVOLUTION OF THE INTERNET AS A
TECHNICAL INFRASTRUCTURE
The increasing popularity of personal computers changed the basic model of computing
in most organizations from a model based on central computing using mainframes or
minicomputers with terminals to one based on personal computers connected in local area
networks, which in turn were connected to central resources (i.e., the client/server model of
computing). The adoption of the personal computer by consumers (which is correlated with the
improving price/performance of computers and, in particular, increasing modem speeds at
affordable prices) provided the household infrastructure for supporting widespread dial-in access
to the Internet by the mid-1990s in the United States.34
31 The history of the Whois database through the 1990s can be found in Section 2.5.3.
32 By the late 1980s, the Internet was in fact an operational network and not only a subject of research, and,
as such, increasingly fell outside DARPA's research mission. At this time, DARPA was working with
other federal agencies, notably the National Science Foundation, to hand off the infrastructure it had
created.
33 See Tirole, The Theory of Industrial Organization, 1988, pp. 406-409, for a brief discussion of the kinds
of coordination and strategic issues that can arise in a network like the DNS.
34 According to the Current Population Survey (conducted by the U.S. Census Bureau), personal computer
adoption in the United States continued to increase throughout the 1990s and demonstrated a five-fold
increase from 1984, the first year data was collected on computer ownership to the year 2000. By the year
2000, 51 percent, or 54 million households, had access to at least one computer at home, up from 36.6
percent in 1997. Households with Internet access more than doubled between these years, from 18 percent
in 1997 to 41.5 percent, or 42 million households by the year 2000. Computer access and Internet access
were becoming synonomous: more than four in five households with computer access also had Internet
access. For the full report, see Eric C. Newburger, September 2001, "Home Computers and Internet Use in
the United States: August 2000," Current Population Reports, Washington, D.C.: U.S. Department of
Commerce, U.S. Census Bureau. Available at <http://www.census.gov/prod/2001pubs/p23-207.pdf >.
2-11
Prepublication Copy--Subject to Further Editorial Correction
To function on the Internet, a computer needs to have some basic information, such as its
IP address, the IP address of at least one router,35 and the IP addresses of a few critical services.36
In the world of a relatively small number of large mainframes or minicomputers, such
information was entered manually on each new computer when installed and, once configured,
rarely changed. In such a world, IP addresses functioned as de facto stable identifiers, with the
DNS (or its HOSTS.TXT predecessor) representing a convenience, not a necessity.37
However, as the number of computers increased sharply, such a custom approach became
increasingly impractical. Thus, a mechanism to automate this startup process was developed.
One approach is contained within the Bootstrap Protocol (BOOTP), a very simple protocol that
enabled a computer to ask a local central server for and receive a number of critical parameters.
BOOTP and other protocols of a similar type shared one important characteristic: Each protocol
had a mechanism to allocate IP addresses to computers, but did not have any mechanism to
reclaim IP addresses when they were no longer needed. In the 1980s, this was not a problem
because IP addresses were plentiful. However, by the early 1990s IP addresses, which had once
seemed to be a nearly inexhaustible resource, were starting to look like a scarce resource that
required conservation, a consequence of the tremendous growth of the Internet. Protocols to
support the "leasing" or temporary assignment of IP addresses were developed,38 such as the
Dynamic Host Configuration Protocol (DHCP)--a direct successor of BOOTP--or the Point-to-
Point Protocol (PPP).39 An important reason for the development of these protocols was to
support system and local area network (LAN) management and auto-configuration, but the timing
was fortuitous inasmuch as these protocols could also help with the conservation of IP addresses.
The spread of network address translators (NATs)--in part, a response to the increased
difficulty of obtaining large blocks of IP addresses in the latter half of the 1990s--further
degraded the usability of IP addresses as stable identifiers. The basic function of a NAT is to
rewrite IP addresses in the data that it forwards. NATs map the set of IP addresses for external
traffic (i.e., the IP addresses that are visible to the world) to a set of IP addresses for internal
traffic (e.g., an organization's LAN); thus, an organization can have many more internal IP
addresses than external ones. The use of NATs distorts the one-to-one mapping between Internet
hosts and IP addresses that many applications assumed in their design--thus, any application that
depends on IP addresses is at risk when its traffic goes through a NAT.40
As a result of these changes, IP addresses have become much less useful as stable
identifiers than they once were. In the case of most application protocols, the "obvious" answer
has been to replace the use of IP addresses with DNS names wherever possible. Thus, over the
35 A router is a device that determines the next Internet Protocol (IP) network point to which a data packet
should be forwarded toward its destination. The router is connected to at least two networks and
determines which way to send each packet based on its current understanding of the state of the networks to
which it is connected. Routers create or maintain a table of the available routes and use this information to
determine the best route for a given data packet.
36 Examples include the address of an e-mail server (because most computers do not operate their own mail
server) and the address of a DNS resolver (explained in Chapter 3).
37 Indeed, the IP addresses of certain important servers were well known to system administrators.
38 After the lease expires, ownership of the address reverts back to the server that issued the address. The
protocol includes mechanisms for lease renewal, and lease times can be quite long at the discretion of the
DHCP server administrator. These "leases" did not include a financial component--"temporary
assignment" is perhaps a more accurate characterization.
39 PPP supports address assignment for dial-up networking by assigning IP addresses to ports on access
servers. Users connect to the access server and are allocated to a port, which has an IP address assigned to
it. Thus, users "lease" the assigned IP address for the duration of their session.
40 In particular, peer-to-peer applications and security protocols that require different public addresses for
each host become much more difficult to deploy.
2-12
Prepublication Copy--Subject to Further Editorial Correction
last decade, applications have come to rely on DNS names very heavily as stable identifiers in
place of IP addresses.
Another departure from transparent architecture41 came with the introduction of packet-
filtering routers, one of the simplest kinds of firewalls.42 A number of organizations introduced
such firewalls beginning in the late 1980s with the intent to defend their sites against various real
and perceived threats. The much-publicized Morris worm43 further raised the profile of network
security and provided network administrators with an additional motivation to install firewalls
(thereby further inhibiting transparency in the network architecture).44
As network security attracted increasing attention, some focus was directed to the DNS
itself. DNS security emerged as an issue in the form of a proposed addition of a cryptographic
signature mechanism to the DNS data.45 Such a mechanism would help ensure the integrity of the
DNS data communicated to the end user. The original DNS design did not include a mechanism
to ensure that a name lookup was an accurate representation of the information provided by the
entity responsible for the information. DNS information was assumed to be accurate as the result
of general notions of network cooperation and interoperation (i.e., based on the presumption that
nobody would deliberately attempt to tamper with DNS information). Development work on
DNS security extensions (DNSSEC) started in the early 1990s and continues a decade later.46
See Chapter 4 for further discussion of DNSSEC and DNS security in general.
2.5.
ECONOMIC AND SOCIAL VALUE OF DOMAIN NAMES
The nature of the growth in the Internet during the 1990s was qualitatively different from
the growth in the 1980s. Most of the new Internet users in the 1990s were non-technical people
who were not associated with academic institutions or the computer and communications
industry. Instead, these new users represented a cross section of society that typically accessed
the Internet from their places of employment, through dial-up connections from their homes, and
by gaining access through libraries, schools, and community organizations.
41 In this context, a transparent network is one that does not interfere with arbitrary communication between
end points.
42 Packet-filtering routers attempt to block certain types of data from entering or leaving a network.
43 In 1988, a student at Cornell University, Robert T. Morris, wrote a program that would connect to
another computer, find and use one of several vulnerabilities to copy itself to that second computer, and
begin to run the copy of itself at the new location. Both the original code and the copy would then repeat
these actions in a theoretically infinite loop to other computers on the ARPANET. The worm used so many
system resources that the attacked computers could no longer function, and, as a result, 10 percent of the
U.S. computers connected to the ARPANET effectively stopped at about the same time. From "Security of
the Internet," available at <http://www.cert.org/encyc_article/tocencyc.html>. Also published in The
Froehlich/Kent Encyclopedia of Telecommunications vol. 15. Marcel Dekker, New York, 1997, pp. 231-
255.
44 The relative value of firewalls in advancing network security can be debated and such discussions can be
found elsewhere; for example, see Fred B. Schneider, editor, Trust in Cyberspace, 1999, Computer Science
and Telecommunications Board, National Research Council. Washington, D.C.: National Academy Press.
45 Digital signatures do not provide foolproof security, but they can demonstrate that the holder of the
corresponding private cryptographic key (i.e., a secret password) produced the data of interest. This is
more or less like trusting a document that bears a particular seal--one must independently make a
determination that an authorized person had possession of the seal when it was used and that the seal is
legitimate but, if both of those conditions are met, it provides some assurance of the authenticity of the
document.
46 For further information on the historical progression of DNSSEC, see Miek Gieben, "A Short History of
DNSSEC," April 19, 2004, available at <http://www.nlnetlabs.nl/dnssec/history.html>.
2-13
Prepublication Copy--Subject to Further Editorial Correction
These new users and the organizations that supported them (such as Internet service
providers, electronic commerce companies, non-profit information services, and so on.) were
primarily interested in how the Internet in general, and Internet navigation and the Domain Name
System in particular (especially using the World Wide Web and e-mail), could advance and
support personal and business goals--that is, they were not very interested in the technology per
se. Consequently, increasing effort was directed to support these non-technical goals, and thus, it
is not surprising that economic value, social value, and globalization emerged as major forces
influencing the DNS and Internet navigation in the 1990s.
2.5.1. Demand for Domain Names and Emergence of a Market47
The rapid growth of the World Wide Web stimulated interest in and the demand for
domain names because Web addresses (Uniform Resource Locators; URLs [see Box 6.2])48
incorporate domain names at the top of their naming hierarchy. One of the early major uses of
the Web that appealed to a wide range of the new users--and helped to continue attracting
additional new users to the Web--was electronic commerce. The .com generic top-level domain
(gTLD) became a kind of directory service for companies and their products and services. If a
consumer wanted to find the Web site for a company, the consumer would often be able to guess
the URL by entering part or all of the company's name followed by .com in the browser
command line; often, the desired site would be located. This practice was further encouraged by
the use of second-level domain names in advertisements and by the naming of companies by their
second-level domain name (e.g., priceline.com). Even if the user's initial guess(es) did not work,
users would often then try the company's name followed by .net or .org, or variations of the
company's name in combination with one of these gTLDs, such as ibmcomputers.net.49
It did not take users long to discover that shorter, shallower, URLs were easier to guess,
use, remember, and advertise than longer ones. The shortest URL of all was based solely on a
domain name. Thus, if one wanted to post a distinct set of resources on the Web, or create an
identity for an organization, product, or idea, it often made sense to register a separate domain
name for it rather than create a new directory under a single domain name. Hypothesizing that
customers would look for products and services by guessing at a similar domain name, companies
like the Procter & Gamble Company, for example, registered pampers.com and used that as a
URL (namely, <http://www.pampers.com>), which also had the advantage of being much easier
to communicate to users, and for users to remember, than, say,
<http://www.pampers.procterandgamble.com>. These different domain names would be used
even if all the information resided on a single computer. In short, domain names began to refer to
products or services rather than just network resources (e.g., host names).50
Before the rise of the Web, the largest concentration of domain name registrations was
under the .edu TLD (as of March 1993). The Internet's rapid growth after 1993, however,
47 A significant portion of this subsection was derived from Mueller, Milton L. 2002. Ruling the Root:
Internet Governance and the Taming of Cyberspace. Cambridge, Mass. and London: MIT Press.
48 Examples of URLs include <http://www.whitehouse.gov> or <http://www.un.org>.
49 Sometime in 1996 or 1997, browser manufacturers made .com the default value for any names typed
directly into the browser command line. That is, whenever a user typed <name> without a top-level
domain into the command line, the browser automatically directed the user to www.<name>.com. Making
.com the default value for all browser entries reinforced the value of .com registrations relative to other
TLDs. In effect, a .com domain name functioned as a global keyword, and the possession of a common,
simple word in the .com space was sure to generate significant traffic from Web browsers. This explains,
to some degree, why some domain names sold for hundreds of thousands or even millions of dollars. As
noted in Section 1.2, footnote 9, browsers no longer operate in this way.
50 Generic words were also registered (e.g., cough.com was registered by Vicks).
2-14
Prepublication Copy--Subject to Further Editorial Correction
radically altered the distribution of domain names across TLDs. Until at least 1997, .com
attracted the large majority of new domain name registrations (see Table 2.1).51 Most of the users
rushing to take advantage of the Web were businesses, and .com was the only explicitly
commercial top-level domain. Furthermore, the U.S.-based InterNIC operated the only
unrestricted, large-scale registry (supporting .com and other gTLDs). Most country-code
registries at this time were slow, or expensive, or followed restrictive policies and considered a
domain name a privilege rather than a commercial service.52 Indeed, in some of the countries
with restrictive country-code registries, such as Japan and France, more businesses registered in
.com than under their own ccTLD. The available statistics provide the basis for estimating that
roughly 75 percent of the world's domain name registrations resided in .com at the end of
1996.53 Thus, the .com TLD became the dominant place for domain name registration
worldwide in the mid-1990s, which by the late 1990s became reflected in popular culture through
phrases such as a "dot com company" (or simply a "dot com") or "dot com economy."
TABLE 2.1 Number of Second-Level Domain Names Registered in the .com, .edu, .org,
and .net Top-Level Domains, 1993-1997
Top-Level
March January January February January
Domain
1993
1994
1995
1996
1997
.com
600
11,000 30,000 232,000 796,000
.edu
1,100
1,400 2,000 2,000
3,000
.org
500
1,100 3,000 17,000
53,000
.net
200
400 2,000 11,000
44,000
Total
2,400
13,900 37,000 262,000 896,000
NOTE: It is worth noting that the number of second-level domain names does not correlate with the
number of host computers. For example, the .edu TLD has maintained a relatively vertical structure, and
so even though a university may be adding many hosts to its network, there will be minimal or no impact
on the number of second-level domain names.
SOURCE: A.M. Rutkowski, "Internet DNS Historical Timeline: Official Actions and Statistics," presents
a timeline-style chronology, official actions, and statistics, plus other meetings and events occurring
between the DNS's inception in 1985 and today. Copyright A.M. Rutkowski. July 30, 1997. Available at
<http://www.wia.org/dns-law/pub/timeline.html>.
51 There were a number of initiatives to use the Internet for commercial purposes (including research and
development activities within companies) prior to the rise of the Web. Such initiatives caused the number
of .com registrations to increase. However, the wide use of the Web caused the registrations of multiple
domain names to single companies, a practice that had been discouraged in the past.
52 In February 1996, when the Internic had about a quarter of a million second-level registrations, Germany
(.de) had only 9000 total registrations, and Great Britain (.uk) had only 4000. Japan, Canada, Australia,
and other major leading participants in the Internet had numbers comparable to the United Kingdom's.
However, some countries (e.g., the United Kingdom) have restrictive policies with respect to registering in
the second-level domain so that most entities actually have to register in the third-level domain (e.g.,
sothebys.co.uk) that would instead be a second-level domain registration in other TLDs (e.g.,
sothebys.com).
53 InterNIC gTLD registrations accounted for an estimated 85 percent of all domain name registrations
worldwide, and .com accounted for 88.6 percent of all Internic gTLD registrations. (About 62 percent of
all registered domains worldwide resided in .com in 2002.)
2-15
Prepublication Copy--Subject to Further Editorial Correction
Interest in domain names extended beyond the for-profit sector. The visibility of
governmental entities and non-profit organizations also became increasingly tied to domain
names as the Web became a key mechanism for providing information and services to the public
and their constituencies. Moreover, individuals also wanted their own domain name as the
identifier for their personal information posted on the Web or for a myriad of other purposes (e.g.,
establishing fan sites54). Opportunistic companies capitalized on (and perhaps helped to create)
this demand by developing services so that users could register a domain name and obtain support
for establishing and maintaining a Web page as an integrated service for a monthly or annual fee.
Domain names also became involved in electoral politics and social commentary.
Political campaigns established Web sites with descriptive domain names in the URLs such as
<http://www.algore2000.com>, <http://www.georgewbush.com>, or
<http://www.johnkerry.com>55 to provide access to information about their respective candidates,
to organize volunteers, and to solicit contributions. Web sites were also created to critique or
parody virtually anything, from the practices of certain companies or their products or services to
various social and political causes. A common practice was to register a domain name that
included the name of interest followed by "sucks," or something similar, and to associate that
domain name with a Web site that criticized the entity in question. In addition to motivating legal
actions to try to prevent the use of domain names in this fashion, this practice caused many
companies to pre-emptively register these types of domain names for themselves.56
Therefore, for various reasons, the demand for domain names increased tremendously
during the 1990s.57 Further fueling the demand was aggressive marketing by companies that
register domain names and provide related services, efforts by IT companies more generally that
played up domain names (especially .com names) in their larger marketing campaigns, and the
popular and technical press, which devoted a lot of attention to anything related to domain names.
The increasing demand for domain names was attributed to interest in facilitating Internet
navigation as well as to the value of domain names irrespective of their functional utility on the
Internet (e.g., placing a domain name on posters in a subway station as a part of a marketing
campaign). Thus, the real value of certain domain names in the rapidly growing and
commercializing Web and Internet was far greater than the price of setting up a domain name
(which was on the order of $50 at the retail level).58 The predictable consequence was the
development of an aftermarket for certain domain names. In 1996, tv.com sold for $15,000 and
in 1997, business.com changed hands for $150,000.59 Not surprisingly, speculation in the
registration of domain names took place: An individual or firm would register domain names
(often very many) with the intent of reselling them to others for a premium. Such speculators
would not only register generic or descriptive names (e.g., "business," "fever," and so on) with
the hope of appealing to multiple prospective purchasers, but would also register domain names
incorporating the trademarks of third parties with the hope that the corresponding trademark
54 See, for example, <http://www.juliaroberts.de> as a fan site and tribute to the actress Julia Roberts that is
based in Germany. Accessed on March 27, 2004.
55 Note that campaign information was not available at the Al Gore site as of March 25, 2004.
56 However, this was a difficult proposition, considering the nearly limitless variations of less-flattering
names that can be devised. See further discussion in the next section.
57 The growth in the registration of domain names was phenomenal. For example, in September 1995,
there were approximately 120,000 registered domain names. By May 1998, 2 million domain names were
registered. "Fact Sheet: NSF and Domain Names," National Science Foundation, Arlington, Virginia,
accessed on March 27, 2004, available at <http://www.nsf.gov/od/lpa/news/media/fs80226a.htm>.
58 Domain names are registered through and maintained by registrars; see Chapter 3 for an extended
discussion.
59 Business.com was resold for $7.5 million in 1999. With some irony, the committee observes that
www.business.com links to "The Business Search Engine" (as of March 27, 2004), a "comprehensive
business directory."
2-16
Prepublication Copy--Subject to Further Editorial Correction
BOX 2.1
The Value of Domain Names
Semantic Value
Economic value often arises when names have some semantic distinction--a meaning--and are
visible in a public arena. The value of meaningful names will differ from nil to very high
depending on the meaning and the potential application. Examples include sex.com and
gardentips.com.
Mnemonic Value
In many commercial contexts, it can be important for a name or identifier to be easily
remembered. If users cannot remember the name, or it is too long or complicated to reproduce,
the object will not be found. Memorability, and in some cases guessability, facilitates more
incoming traffic and more business and, therefore, gives rise to economic value. One example is
gm.com (i.e., a second-level domain name for the General Motors Corporation).
Personal Value
Even when there is no apparent commercial consequence, the human desire to make a statement
and assert an identity can give economic value to identifiers in a public name. Someone with a
high regard for himself might want the domain name i-am-the-best.com.60
Stability Value
Users can accumulate equity in a particular identifier, which becomes closely associated with
them and expensive to change. Changing a telephone number or e-mail address that has been
used for many years can be difficult because of the large number of personal contacts and records
that contain the number. Thus, equity in an identifier raises switching costs for consumers,
making them more likely to stay with the provider of that identifier.
Pure Scarcity Value
Meaningless identifiers, such as bank account numbers, function economically as an
undifferentiated resource pool. They may possess economic value by virtue of their scarcity, but
no one cares which particular identifier he or she gets. In the DNS, there are plenty of possible
names (accepting that random strings of letters and digits can produce domain names (e.g.,
akwoeics8320dsdfa0867sdfad02c.org); there is scarcity of some desired names, with
desirability defined by one of the reasons above (e.g., only a small subset of all possible domain
names have semantic value).
owner would purchase the domain name from the speculator as well. See Box 2.1 for further
discussion on the value of domain names.
An industry emerged to provide services related to the transfer and assignment of domain
names and related services.61 The pressure for new TLDs led to the conversion of some country
codes to quasi-generic TLDs. For example, the marketing of .cc (a country-code TLD created
to represent the Cocos Islands but later marketed as a de facto gTLD) further increased the variety
60 As of March 27, 2004, this domain name was not registered.
61 Registrars, and the industry surrounding registrars and allied services, are discussed in detail in Chapters
3 and 4.
2-17
Prepublication Copy--Subject to Further Editorial Correction
and value of certain domain names. However, true additional gTLDs did not materialize in the
1990s (despite the intense arguments and efforts made by some individuals and organizations),
which helped to solidify the dominance of the then-extant TLDs, especially of .com.62
2.5.2. The Rise of Conflicts Over Domain Names
As the number of domain name registrations exploded, conflicts developed over the right
to register particular names at the second level of many of the TLDs.63 The basis for most of
these conflicts derived from the unique naming associated with the DNS. The DNS does not
have the capability to incorporate context into domain names, so each domain name must be
unique worldwide and then in turn, a Web site at that domain name can then be accessed
throughout the world.64 The consequence is that it is significantly harder to pick a domain name
that is both unused and memorable.
Claims to rights to domain names can be based on a number of different legal, political,
economic, ethical, or cultural criteria. A common problem raised by all such claims is that any
reasonable attempt at resolution must balance the value of avoiding confusion or preventing
illegal or otherwise undesired appropriation of identity against the value of free expression, open
communication, and fair use. Whenever semantics and economics enter the picture, however,
society and all of its conflicts come along with them. The resultant conflicts over who has rights
to use particular domain names has enmeshed and continues to enmesh apparently technical
naming processes in economic, public policy, and legal issues.65
Trademark Conflicts
In the commercial world, trademark law provides one of the oldest, most widely
recognized and well-developed regimes for recognizing and protecting exclusivities in the use of
source identifiers of goods or services within specific fields and territories. Trademark laws
developed, in part, to protect consumers against various forms of fraud, deception, or confusion
that might result from the ways in which products and services are identified. By giving
producers an exclusive right in an identifier, trademarks reduce consumer search costs and
channel the benefits of developing a good reputation to the producer responsible for the
reputation. Trademark protection is not, however, intended to give firms ownership of common
62 Discussion of the gTLDs added in the early 2000s (e.g., .info) and general discussion of the issues
involved with adding new gTLDs can be found in Chapters 3 and 4.
63 "Rights to names" refers to claims to exclusive or privileged use of an identifier based on the meaning or
economic value of the name.
64 The mythical (or perhaps real) Joe's Pizza illustrates the point. The DNS can support only one
www.joespizza.com worldwide, but in the physical world, people can usually distinguish among the
(presumably) multiple Joe's Pizza restaurants around the world. If a person is located in the center of a city
and asks a taxi driver to take her to Joe's Pizza, it is presumed that she wishes to travel to a restaurant
within a few miles, not a Joe's Pizza located in a city 2000 miles away. Although the requestor does not
state this context explicitly, it is assumed in the conversation. As of February 4, 2005, joespizza.com
is registered by BuyDomains.com and offered for resale at a minimum price of $1488.
65 In his paper "External Issues in DNS Scalability," Paul Vixie argues for eliminating the disputes
associated with domain names by eliminating all meaningful top-level domains and replacing them with
meaningless alphanumeric identifiers. Conference paper, November 11, 1995, available at
<http://www.ksg.harvard.edu/iip/GIIconf/vixie.html>. Whereas the number of conflicts would surely
decline, so too would the benefits to those who prefer specific domain names that have meaning or some
other characteristic. As with phone numbers, however, competition for certain numbers will ensue unless
they are assigned randomly and a secondary market (in either names or entities that control names) is
prohibited.
2-18
Prepublication Copy--Subject to Further Editorial Correction
words alone, to prevent non-commercial or fair use, or to inhibit public discussion of companies,
products, and services involving direct references to the mark.
The great emphasis placed on second-level domain names created a problem for some
trademark holders, especially for those that held trademarks that were well known in the United
States or worldwide. Trademark rights (which are traditionally accorded on a country by country
basis) generally arise through use of a trademarkable name, logo, color, sound, or other feature, in
association with the marketing and sale of particular types or classes of goods and services in
commerce. Some countries will allow someone to reserve or even register a trademark without
using it, but most countries (including the United States) require use to claim protection under
trademark law.66 Similar to trademarks, domain names can act as source-identifiers suggesting
the identity, quality, or source of a good or service. Accordingly, domain names may conflict
with trademarks because of their similarity in function.
If a trademark holder allows someone else to use the trademark or mark either in the
same class of goods/services or in some other way that could create confusion in the marketplace,
the other party may begin to acquire rights as a result of that use, and those rights reduce the
value of the mark to its original owner. Within the United States, the problem is further
complicated by the existence of federal and state antidilution laws that permit owners of famous
marks to enjoin others from commercial uses of such marks, even where such commercial uses
are in classes of goods or services different from that of the famous mark.67 Designed to prevent
the whittling away of the identification value of the plaintiff's mark, antidilution laws differ from
more traditional trademark laws, which are designed to prevent consumer confusion within the
same class of goods or services.68 In order to determine whether a mark is subject to federal
antidilution protection (i.e., whether it is considered to be a famous mark), the law provides
several non-exclusive factors that may be considered.69 Some states within the United States
have more generous definitions of "famous marks," while other countries have similar or
different definitions or do not recognize the concept at all. Another one of the factors to be used
in this determination under U.S. law is "the nature and extent of use of the same or similar marks
by third parties." This factor demonstrates that a potentially famous mark owner's antidilution
rights, like rights against infringement, can be lessened or lost by its failure to police its mark.
Thus, trademark holders became quite concerned about the activities of parties that had
registered domain names that either were confusingly similar to their trademarks or diluted their
famous marks. Generally, to cause a likelihood of confusion under trademark law,70 a domain
name must be used in connection with an offering of goods and services or it must be used
commercially for antidilution laws to apply, but cybersquatters raised a slightly different problem.
Cybersquatters are generally defined as domain name speculators who register a domain name
that incorporates a trademark owned by another party, not in order to use the domain name, but
with the intent of reselling the registered domain name to that party for an amount that far
exceeded the cybersquatter's registration cost. The most contentious examples of cybersquatting
were those in which domain names incorporating trademarks (or phonetic or typographical
variants of them) were associated with Web sites that included pornographic content or other
66 This also means that the failure to use a registered mark can result in the loss of rights.
67 See J. Thomas McCarthy, McCarthy on Trademarks and Unfair Competition § 24:88 (2003).
68 See id. An example would be if Mack Trucks, Inc. began using the mark "BIG MAC" in association
with a new model of truck. It is unlikely that the McDonald's Corporation would argue that there was a
likelihood of consumer confusion between Mack's truck and McDonald's large sandwich of the same
name. However, it is possible that the McDonald's Corporation would argue that the truck model was
diluting the value of its famous mark, BIG MAC.
69 These factors include "the degree of inherent or acquired distinctiveness of the mark," "the duration and
extent of use of the mark in connection with the goods or services with which the mark is used," and "the
duration and extent of advertising and publicity of the mark." See 15 U.S.C. § 1125(c)(1).
70 See McCarthy on Trademarks, § 25:76, at 25-237.
2-19
Prepublication Copy--Subject to Further Editorial Correction
information that would confuse or offend users who reached that Web site by mistake or assumed
that the trademark holder had registered the domain name and that the Web site associated with it
belonged to the trademark holder. The cybersquatter would then offer to sell the domain name to
the trademark owner for a substantial sum, which some companies agreed to pay, if for no other
reason than to make the offending use stop. Such actions, of course, only fueled more
cybersquatting activities. Cybersquatters also figured out that users were trying alternative
domain names (e.g., ibm-computers.com instead of ibm.com) and began to register many
different combinations, such as ibmcomputers.com and ibmcomputer.com. Partially in
response to these actions, many companies began to register various combinations themselves--
so-called pre-emptive registrations71--and to seek remedies through the courts, various dispute
resolution processes, and legislative action.72
At least one court has held that a cybersquatter's registration of a domain name that
incorporated a plaintiff's famous mark, without the sale of any goods or services via the Web site
associated with that domain name, was a violation of the federal antidilution statute because the
defendant made "commercial use" of the trademark when he attempted to sell the domain name
back to the owner of the famous mark.73 Another court has found the attempted sale or licensing
of domain names containing trademarks to be trademark infringement, similarly concluding that
the sale of these domain names was a commercial use of the marks.74 Additionally, the
Anticybersquatting Consumer Protection Act (ACPA), enacted in 1999,75 provides additional
rights to trademark owners against those who register, traffic in, or use, with the bad-faith intent
to profit, a domain name that is identical or confusingly similar to a registered or unregistered
mark that was distinctive or dilutive of a famous mark when the domain name was registered.
Despite the creation of ACPA and other domain name dispute resolution mechanisms,76 the costs
involved with pre-emptive registrations and the enforcement of trademarks ultimately led many
representatives of trademark holder interests to resist efforts to create new TLDs, fearing that
these costs would continue to increase substantially if new additional TLDs were created.
In contrast, the protective efforts by trademark holders in some instances have also raised
conflicts with other legally equivalent rights held by the individuals using the domain names. For
example, suppose a group critical of a corporation wants to create a public space for discussion
and register a domain name associated with that corporation (e.g., companyname.org). Does
such a registration constitute an infringement of the corporation's trademark because it creates
consumer confusion or is it dilutive because it tarnishes the reputation of the corporation, or
rather is it an exercise of a protected right, such as freedom of speech under the First Amendment
of the U.S. Constitution? Discussions related to domain names, trademark concerns, and public
policy issues will continue into the 21st century.77
Other conflicts involving trademarks arose for reasons that had nothing to do with the
above-described conflicts between trademark holders and their cybersquatting antagonists. For
example, Chris Van Allen, then 12 years old, registered the second-level domain name
pokey.org because that was his nickname, and was subsequently ensnarled in a trademark
dispute with Prema Toy Company, owner of the trademarks on the claymation character Gumby
71 Such pre-emptive registrations were encouraged by the marketing strategy of many registrars.
72 In fact, the congressional mandate (P.L. 105-305) for this study came largely as a result of actions by
representatives of the trademark community. This community was very active and visible in the domain
names arena in the late 1990s.
73 See Intermatic, Inc. v. Toeppen, 947 F. Supp. 1227 (N.D. Ill. 1996).
74 See Toys "R" Us, Inc. v. Abir, 45 U.S.P.Q.2d 1944 (S.D.N.Y. 1997).
75 See 15 U.S.C. § 1125(d).
76 See Section 3.5 for an extended treatment.
77 The state of understanding continues to evolve. See, for example, The Taubman Company v. Webfeats,
et al., Nos. 01-2648/2725 (6th Circuit, February 7, 2003).
2-20
Prepublication Copy--Subject to Further Editorial Correction
and his horse Pokey, which wanted control over the domain name.78 Ultimately, Prema Toy
Company withdrew its complaint.79 In other cases, disputes arose between different entities with
equally valid rights to the same second-level domain name, such as "bob.com," which might
have been coveted by many men named Robert, and "avon.com," which might have been
coveted by a variety of different companies around the world that have legitimate rights to the
trademark Avon for different products or services in different countries.
This latter example presents a particularly difficult point that cannot be easily resolved by
simply granting the second-level domain name to the entity with the legal right to use it as a
trademark, since multiple entities can have such legitimate rights. Under most countries'
trademark laws, multiple entities can use the same trademark in the same country, provided each
entity uses the trademark for different categories (called classes) of goods or services, as long as
there is no possibility of confusing consumers as a result, and each trademark has to be registered
within each country in which it is used in order to be fully protected. Hence it is entirely possible
to have one company legitimately use the trademark "avon" for automotive tires in the United
States, and a second company to use the same trademark for cosmetics. Unfortunately, however,
there can be only one avon.com, and so the first entity to register that domain name has often
been able to use it to the exclusion of all other legitimate users worldwide.80
Beyond Trademark Conflicts
Trademark issues dominated domain name conflicts in the late 1990s and into the
beginning of the 21st century, but other conflicts also demanded attention. For example, some
governments asserted rights to control the assignment of country code TLDs and country names
and the registration of those names, even beyond the second level.81 Some governments assert
that this is an extension of national sovereignty. Similar claims may be asserted by ethnic groups
and indigenous tribes that have not achieved the political status of sovereigns, but that
nevertheless wish to protect or control the use of their collective name. In some jurisdictions, the
subunits of national governments, such as city administrations or port authorities, have claimed
exclusive rights to the use of their name in the DNS.82 In a similar vein, some international
organizations have asserted a right to prevent others from registering domain names identical to
their acronyms or names.83 These claims have more to do with the imputed legitimacy of the
association than with commercial confusion. Here, too, issues arise regarding the balance struck
between the use of the name as an identifier and its legitimate use as a reference to the identified
78 See "Short Take: Pokey Causes Net Trademark Uproar," Courtney Macavinta, News.com, March 23,
1998, available at <http://news.com.com/2110-1023-209417.html?legacy=cnet>. The dispute also
involved Pokey's Network Consulting, which registered pokey.com.
79 See "Pokey Wins His Domain Name," Heather McCabe, Wired News, April 22, 1998,
<http://www.wired.com/news/business/0,1367,11846,00.html>.
80 See Chapters 3 and 4 for a discussion of how trademark conflicts over domain names can be (and should
be) managed.
81 See Principles for Delegation and Administration of ccTLDs presented by the ICANN Government
Advisory Committee, February 23, 2000, at <http://www.icann.org/committees/gac/gac-cctldprinciples-
23feb00.htm>.
82 See, for example, Excelentisimo Ayuntamiento de Barcelona v. Barcelona.com Inc. WIPO Case No.
D2000-0505, available at <http://arbiter.wipo.int/domains/decisions/html/2000/d2000-0505.html>; Salinas,
California, National Arbitration Forum, City of Salinas v. Brian Baughn, WIPO Case No.
FA0104000097076, available at <http://www.arbitration-forum.com/domains/decisions/97076.htm>.
83 For example, international organizations such as the International Monetary Fund (IMF) or the World
Health Organization (WHO). See The Recognition of Rights and the Use of Names in the Internet Domain
Name System, Report of the Second WIPO Internet Domain Name Process. September 3, 2001. Available
at <http://wipo2.wipo.int/process2/report/pdf/report.pdf>.
2-21
Prepublication Copy--Subject to Further Editorial Correction
entity. These claims also raise questions about who in the affected society has the right to control
the name. Also, some legal regimes, which are analogous to trademark law because they are
related to reputation in commerce, attempt to vest regions or localities, rather than specific firms
or products, with exclusive rights to a name for a certain use. These regimes of "controlled
appellations of origin" might be applied, for example, to wines or other agricultural products.84
In addition to nations, regions, and international organizations, many people feel that they
have some ownership right over their personal name and other aspects of their persona. National
systems of law often recognize "rights of personality" when defined as the ability of a person "to
control the commercial use of his or her identity."85 In the United States, there currently is no
federal right of publicity or privacy; rather, the promulgation of such laws has been left to the
states. About half of the states have recognized the right of publicity, either through common law
or statute.86 Other states provide similar protections as a part of the right of privacy.87 Under the
Restatement (Second) of Torts §§ 652A - 652C (1979), invading an individual's right of publicity
is similar to invading her privacy through unauthorized appropriation of her name or likeness.88
One of the primary motives behind passage of the Anticybersquatting Consumer
Protection Act in the United States, for example, was the widespread registration of the names of
U.S. politicians as domain names and their linkage to Web sites that were satirical or critical.89
Communications technology can create new arenas for disputes over rights to names. In
particular, the process of entering an identifier into a network creates numerous opportunities for
conflicts over the boundary of a name right. Of course, many of the underlying issues--
confusion, fraud, competition, fair use, freedom of expression--are familiar from other contexts.
84 For further discussion see, "Geographic Identifiers," in The Recognition of Rights and the Use of Names
in the Internet Domain Name System, Report of the Second WIPO Internet Domain Name Process.
September 3, 2001. Available at <http://wipo2.wipo.int/process2/report/pdf/report.pdf>.
85 See J. Thomas McCarthy. 1996. McCarthy on Trademarks and Unfair Competition, 4th ed., Clark
Boardman Callaghan, Deerfield, Illinois.
86 See, for example, Carson v. Nat'l Bank of Commerce, 501 F.2d 1082, 1084 (8th Cir. 1974) (recognizing
a common law right of publicity in Nebraska); FLA. STAT. ANN. §540.08 (West 2002) (providing for a
statutory right of publicity in Florida).
87 See, for example, Allison v. Vintage Sports Plaques, 136 F.3d 1443 (11th Cir. 1998) (describing the
appropriation of plaintiff's personality for a commercial use as an invasion of privacy tort in Alabama).
88 In 1953 in the case of Haelan Labs. v. Topps Chewing Gum, the right of publicity was first explicitly
recognized as a right independent of the right of privacy and as an individual's right to the publicity value
of his photograph. The court distinguished the right of publicity from the right of privacy because "many
prominent persons . . . far from having their feelings bruised through public exposure of their likeness,
would feel sorely deprived if they no longer received money for authorizing advertisements [or]
popularizing their countenances." See Haelan Labs. v. Topps Chewing Gum, 202 F.2d 866, 868 (2d Cir.
1953). Thus, the right of publicity has developed into a body of law distinct from, but related to, copyright
law, privacy rights, and the law of unfair competition. While certain states encode publicity rights within
their right of privacy statutes, prominent case law and jurisprudence acknowledge the development of the
right of publicity as an independent body of law. See, for example, Carson v. Here's Johnny Portable
Toilets, 698 F.2d 831, 834 (6th Cir. 1983) (stating, "[T]he right of privacy and the right of publicity protect
fundamentally different interests and must be analyzed separately."). When commercial exploitation of
names is involved, personality rights often overlap with, or are informed by a logic that parallels, trademark
rights. Indeed, a person's name is often registered as a trademark or used to brand products or services
(e.g., Michael Jordan). But rights of personality are often asserted even when commerce is not directly
involved.
89 U.S. Patent and Trademark Office, "Report to Congress: the Anticybersquatting Consumer Protection
Act of 1999." January 2000. A law passed by the state of California makes it illegal to register someone
else's name as a domain name "without regard to the goods and services of the parties." [Section 17525 of
the California Business and Professions Code]
2-22
Prepublication Copy--Subject to Further Editorial Correction
A good part of the advertising economy of the Internet is based on paying for "hits" (i.e., the
exposure of the content of a Web site to a distinct user).90 Thus, the practice of "typosquatting"
developed, wherein entrepreneurs registered domain names that were only a keystroke or two
apart from popular domains. These "typo" domains would then be linked to advertisements in
order to collect pay-per-hit revenue from people who mistyped the locator into the browser. The
cybersquatter John Zuccarini refined the practice of "typosquatting" to an art, registering
hundreds of close misspellings of popular domain names and trapping users into a parade of
cascading Web pages, some of them pornographic.91
There are even fuzzier boundaries to consider. There are businesses that register large
collections of expired domain names in order to collect advertising hits from people who are
looking for the old Web site. 92 Is this an abusive practice or one as innocent as putting up a
billboard on a choice spot on a busy highway?
Beyond Second-Level Domain Names
Thus far, the discussion has focused on second-level domain names. Although less
common, there are disputes involving third-, fourth- and higher-level domain names, as well as
involving directory and file descriptors. For example, in Bally Total Fitness Holding Corp. v.
Faber, 29 F. Supp. 2d 1161 (C.D. Cal. 1998), an infringement suit was brought against a
defendant who used the URL <http://www.compupix.com/ballysucks> to post critical comments
regarding the plaintiff. The court held that "no reasonable consumer" was likely to confuse the
defendant's domain name with the plaintiff's marks BALLY, BALLY TOTAL FITNESS, and
BALLY'S TOTAL FITNESS, because, among other things, the defendant did not use the
plaintiff's mark in his domain name.93 Based on the facts of the case, the court stated that the
result would have been the same even if the defendant's domain name was
ballysucks.com.94 The court also contrasted the defendant's domain name and the
hypothetical second-level ballysucks.com domain name with other cases where likelihood
of confusion was found when the plaintiff's mark was the only mark (e.g., panaflex.com)
used in the defendant's second-level domain.95
In another example, the Usenet newsgroup name space contains numerous descriptors
that use a variety of names to describe the space, including, for instance, the name Disney (e.g.,
alt.disney.disneyland or rec.arts.disney.parks). These newsgroups (which are visible to most
Internet users) are not run by the Disney Corporation, and the content and administration of the
90 See Section 7.2.2 for an extended discussion.
91 See, for example, "Typo-Loving Squatter Squashed," Joanna Glasner, Wired, October 31, 2000, available
at <http://www.wired.com/news/business/0,1367,39888,00.html>. In 2004, Zuccarini was sentenced to 30
months in prison for using misleading domain names to trick children into visiting pornographic Web sites
in violation of the federal Truth in Domain Names Act. See "U.S. Man Jailed for Luring Children to Porn
Sites," Reuters, February 26, 2004.
92 Other cases include attempts to protect the "nonproprietary" status of a name by excluding it from a
name space. The World Health Organization and World Intellectual Property Organization (WIPO)
proposed to do this with respect to International Nonproprietary Names (INNs), a list of over 3000 names
of pharmaceutical substances. See "International Nonproprietary Names (INNs) for Pharmaceutical
Substances," in The Recognition of Rights and the Use of Names in the Internet Domain Name System,
Report of the Second WIPO Internet Domain Name Process. September 3, 2001. This proposal is
particularly problematic because the list of INNs is not only long, but expands over time. Available at
<http://wipo2.wipo.int/process2/report/pdf/report.pdf>. Religion is another potential source of rights
claims. Certain religions recognize words as sacred and attempt to protect or restrict their use.
93 See id. at 1163-65.
94 See id. at 1165.
95 See id. at 1165.
2-23
Prepublication Copy--Subject to Further Editorial Correction
group may or may not have the corporation's approval. In the even more freewheeling world of
AOL screen names, any user can appropriate the name of his or her favorite Disney character
(even in less than flattering variations) and use it as his or her screen name and e-mail address.
While it is clear that no exemption exists for Usenet groups and AOL screen-name aliases, it does
appear that trademark holders have chosen not to pursue many of these uses in these naming
spaces.96
Yet current law and policy regarding domain names erect major distinctions between the
various parts of the domain name used in a URL. Within the generic and most country-code top-
level domains, all (or at least most) of the political and legal conflict over rights to names takes
place over the second-level domain name. The third-level domain and all identifiers to the right
of the domain name are generally outside the scope of challenge through dispute resolution
processes.97 Current law and policy therefore regard the top-level domain as a fixed set of
generic categories or country codes, the second-level domain as the identifier of an organization,
product, or Web site, and the third-level domain as part of a "private" naming system, wherein
assignments can generally be left to the discretion of whoever holds the second-level name.
To further illustrate this point, Yahoo! Inc. has been an active defender of its brand name
in cyberspace. It has challenged the registration of hundreds of second-level domains, including
some rather remote misspellings, such as "jahu" or "yhuu," whenever they appear in the second
level of a domain name. But under current legal precedent, it would likely take no action against
a name such as yahoo.blatant.cybersquatter.com. In all likelihood, however,
Yahoo's decision not to pursue claims for trademark infringement or dilution for alternative uses
of its brand name and mark is less influenced by current precedent than it is by Yahoo's
likelihood of success on the merits, especially in view of decisions such as that in the above noted
Bally Total Fitness Holding Corp. v. Faber case.
By contrast, second-level domain names are ripe for generating conflicts over rights to
names. They are meaningful, they are perceived as being economically valuable, and they are
part of a global, public naming system administered via collective action. And perhaps most
importantly, they are susceptible to centralized control because of the existence of a single,
central point of coordination, the relevant registry. See Box 2.2.
96 Many trademark holders have not done anything regarding many newsgroup names, in part, because such
activities are difficult to police as well as prove that trademark infringement and/or dilution has occurred.
Indeed, as soon as a name was removed or changed in this space, another of the millions of users could
create a new one.
97 There are some important exceptions, such as the case of .uk, for which most entities register at the
third level (e.g., Disney.co.uk) rather than at the second level. For these exceptions, it is the fourth
level and beyond that are outside the purview of dispute resolution processes. Dispute resolution processes
are further described in Chapters 3 and 5.
2-24
Prepublication Copy--Subject to Further Editorial Correction
BOX 2.2
The Institutionalization of .com
For the most part, the initial dominance of .com among the TLDs was a historical
accident, a product of the chance conjunction of the commercialization of the Internet, the rise of
the Web, the openness of the InterNIC registry relative to the ccTLD registries, and the lack of
any other commercially oriented TLD in the original set of gTLDs. Once .com became
established as the most desired TLD for many registrants, other forces contributed to the
solidification of .com's increasing dominance. As discussed elsewhere in this section, "Beyond
Second-Level Domain Names," the rise in value of .com names (whether for navigation or
marketing functions) led to the registration of some domain names for speculative, abusive, or
preemptive purposes. Based on a desire to avoid further registration of domain names for these
same purposes in new TLDs, some resistance developed to the creation of new TLDs, thereby
reinforcing the focus on extant TLDs (with disproportionate advantage to .com , given its
dominant market position). Whether the historical dominance of .com from the mid-1990s will
continue in the future of the DNS is discussed in Section 5.4.
2.5.3. Whois
In concert with the rise in the interest in and demand for domain names was a
corresponding increase in the value of contact information associated with domain names.
Hence, interest in the Whois database continued to rise in the 1990s.
Some of the targeted uses of the Whois data were for old-fashioned marketing
purposes--for example, to send marketing brochures and to make telephone solicitations to
network operators and domain name registrants. As domain names became economically
valuable after 1995, accessing Whois data also became a popular way to find out which domain
names were taken, who had registered them, and the creation and expiration date of the
registration. The Whois database also became an investigation and monitoring tool for
intellectual property rights holders. When a trademark holder discovered a potentially infringing
domain name, the trademark holder could use the Whois database to identify, investigate, and
contact the registrant of the domain name. At that time, the Whois database could also be used to
determine if the same registrant had registered any similar domain names that the trademark
holder did not know about or to search for further evidence of cybersquatting by the registrant.
Trademark holders also discovered that they could use the database proactively to perform
searches for character strings that matched trademarks, and pull up many of the domain name
registrations in the generic top-level domains that matched or contained a trademark. This
automated searching function proved to be so valuable that trademark interests began to demand
that the Whois functions be institutionalized, expanded, and subsidized, including the right to
purchase the complete list and contact data for all of a registrar's customers. The first World
Intellectual Property Organization (WIPO) domain name process, initiated in 1998 in response to
a U.S. government request, as detailed by a U.S. Commerce Department white paper,98
98 For the text of the white paper see <http://www.ntia.doc.gov/ntiahome/domainname/6_5_98dns.htm>.
2-25
Prepublication Copy--Subject to Further Editorial Correction
recommended that the contact details in a Whois record be contractually required to be complete,
accurate, and up-to-date, on penalty of forfeiture of the domain name.99
2.6.
GLOBALIZATION
Worldwide interest in the DNS developed during the 1990s along with increasing
concern about U.S. dominance of a critical element of global communication and a commercial
resource on which other nations foresaw their economies and societies becoming ever more
dependent. With increasing recognition of this value came a growing desire to participate in the
management and policy decision making with respect to domain names.
One of the issues of particular interest in many countries is access to the Internet and the
DNS using home-country languages and scripts. The DNS was designed and developed based on
the use of Roman characters, generally in the English language. As the number of users in
countries with first languages that are not based on Roman characters increased dramatically
through the 1990s, interest developed in domain names based on non-Roman scripts (e.g.,
Chinese, Hebrew, Arabic, and so on). Several major efforts were undertaken to accommodate
internationalized domain names (IDNs) within the Internet infrastructure.100
Unfortunately, the design of the DNS presents formidable technical challenges for the
accommodation of languages that use non-Roman characters. As a lookup system, the DNS must
be able to determine unambiguously whether there is a match with a query or not. Comparing
strings is much more difficult than most people realize, because the definition of what is "equal"
is often not deterministic. For example, consider the case of the French language in Canada and
in France, for which there are different rules as to whether an accent stays over a character when
it is converted from lower to upper case.101 And some languages (e.g., Chinese) cannot even be
reduced to a relatively small number of standardized characters (e.g., the character set for
English). See Section 4.4 for further discussion of the IDN issue and the increasing interest and
involvement by parties outside the United States in matters related to the DNS.
2.7.
ADMINISTRATION OF DOMAIN NAMES
In the 1980s, the Network Information Center (NIC) managed the registration of domain
names, operating under the auspices of SRI International and funded by the Department of
Defense (DOD), by DARPA and the Defense Information Systems Agency (DISA).102 Jon Postel
and other researchers at the Information Sciences Institute at the University of Southern
California had been given the authority to establish procedures for assigning and keeping track of
99 See paragraph 73 of The Management of Internet Names and Addresses: Intellectual Property Issues.
Final Report of the WIPO Internet Domain Process. April 30, 1999, available at
<http://wipo2.wipo.int/process1/report/finalreport.html#49>.
100 See discussion in Section 4.4.
101 Another example is the "a" with diaeresis "¨" ("ä"), which in German should be sorted and looked at
exactly as an "a" with diacritical character, but in Swedish has nothing to do with the character "a" except
the look. In the same way Å as the abbreviation for the unit of length "angstrom" is one character, but the
initial character of the word "Ångström" is another (which in turn is different from an "A"). The other
problem with the German "a" with diaresis ("umlaut") is that it may be considered to match the string "ae",
whereas not all names containing "ae" match "ä".
102 Formally, the NIC was the Defense Data Network-Network Information Center (DDN-NIC).
2-26
Prepublication Copy--Subject to Further Editorial Correction
protocol and network numbers and controlled the definition of TLDs.103 Overall, the
administration and policy oversight for domain names was relatively straightforward.
In the mid-1980s, the National Science Foundation (NSF) created NSFNet to provide
data communication services to researchers and educators. It selected the Transmission Control
Protocol/Internet Protocol (TCP/IP) as its transport protocol and worked closely with the
Department of Energy, the National Aeronautics and Space Administration, and DARPA to share
facilities to extend this infrastructure in the United States and worldwide. NSF encouraged
campus network investment by focusing its efforts on high-speed and high-capacity long-haul
"backbone"104 and regional networks to connect the campuses. Thus, the responsibility for the
civilian network gradually shifted from the DOD to NSF. (See Box 2.3 for a timeline of the
shifting administration of domain names.) In the early 1990s, NSF made another important
decision--to withdraw as the primary financial benefactor for the backbone of the Internet and to
encourage a commercial market for support of transport facilities.
Continuing on this path, in 1993 NSF replaced DOD as the funding agency for domain
name management. As the workload increased, NSF contracted with Network Solutions, Inc.
(NSI) to manage the registration for most of the gTLDs (.com, .net, .org, .edu, and .gov),
through InterNIC. At this time, NSF, preserving the practice that the registration of domain
names would be free to registrants, subsidized the costs associated with domain name
registration. See Box 2.3.
Increasing scale was not the only impetus for administrative evolution. The increasing
economic and social value of domain names caused new players to become interested in the
realm of domain names. As discussed earlier, holders of highly visible and valuable trademarks
developed an active interest in domain names. Many other entities, from national governments
and public interest groups to the firms in the emerging domain name industry, also developed a
keen interest in all things related to domain names. Thus, the 1990s saw the domain name
community expand radically, both in scale and, especially important to understand, in the scope
of the interests and backgrounds of participants.105
103 Jon Postel had a central role in the DNS from the beginning as co-author of "The Domain Naming
Convention for Internet User Applications," RFC 819. Postel "held leadership positions in several Internet
infrastructure activities. He was founder and head of the Internet Assigned Numbers Authority, RFC
editor, and chief administrator of the .US domain. He was expected to play a crucial role in the future of
Internet administration, which [was] in the process of being transferred to the private sector [the Internet
Corporation for Assigned Names and Numbers (ICANN)]." Source: The Domain Name Handbook, In
Memoriam, Dr. Jonathan B. Postel, August 3, 1943 October 16, 1998. See
<http://www.domainhandbook.com/postel.html>, accessed March 31, 2004.
104 A backbone is a network that interconnects other networks. Backbone networks often operate over
relatively longer distances than do typical networks.
105 This diversity in the range of participants creates challenges in achieving consensus in the decisions
needed to make progress on various problems. Among other things, conflicting goals and varying
communication styles and vocabulary contribute to these challenges. Even agreeing on something as basic
as defining "DNS" can lead to disputes.
2-27
Prepublication Copy--Subject to Further Editorial Correction
BOX 2.3
Administration of the Domain Name System in the 1990s: The Road to ICANN
1991
Responsibility for much of the Network Information Center (NIC) was transferred from SRI
(operating on the behalf of the Department of Defense; DOD) to Government Systems, Inc.,
which then subcontracted the entire operation to Network Solutions, Inc. (NSI). NSI started
operating the NIC in 1992.
1993
The National Science Foundation (NSF) replaced DOD as the funding source for the NIC. NSF
completed a service contract with InterNIC, the umbrella organization for the participating
contractors AT&T (directory and database services), NSI (registration services), and General
Atomics/CERFnet (information services). Thus, NSF engaged NSI to take over domain name
registration services for most of the generic top-level domains (gTLDs) through a 5-year
cooperative agreement.
1994
"Domain Name System Structure and Delegation" (RFC 1591), written by Jon Postel, was
published and gained general acceptance.106
1995
NSF and NSI amended their cooperative agreement, imposing a $100 fee for 2 years of domain
name registration.
1997
The International Ad Hoc Committee (IAHC), a coalition of individuals representing various
constituencies established in 1996, released a proposal for the administration and management of
gTLDs that included a framework for a governance structure, captured in a document known as
the Generic Top Level Domain Memorandum of Understanding (gTLD-MoU).107
The U.S. government created an interagency group to address the domain name issue and
assigned lead responsibility to the National Telecommunications and Information Administration
(NTIA), Department of Commerce. This interagency group reviewed the IAHC proposal and
solicited public comment.
As a part of the Clinton Administration's "Framework for Global Electronic Commerce,"108 the
Department of Commerce was directed to privatize the Domain Name System in a manner that
would increase competition and facilitate international participation in its management. The
department issued a call for public input relating to the overall framework of the DNS.
1998
The NTIA released "A Proposal to Improve Technical Management of Internet Names and
Addresses," also known as the Green Paper. This proposal called for a private, non-profit
106 Available at <http://www.rfc-editor.org/rfc.html>.
107 For further information, see <http://www.gtld-mou.org/draft-iahc-recommend-00.html>.
108 See <http://www.ta.doc.gov/digeconomy/framewrk.htm>.
2-28
Prepublication Copy--Subject to Further Editorial Correction
corporation, headquartered in the United States, to manage domain names and IP addresses, and
for "the addition of up to five new registries."109
A final statement of policy, the "Management of Internet Names and Addresses," also known as
the White Paper, was issued by NTIA. The White Paper reaffirmed the goals of the Green Paper,
while having the U.S. government take a more hands-off approach, and urged the creation of a
new not-for-profit corporation to oversee the management and assignment of domain names and
IP addresses. Goals for the new corporation included ensuring stability, competition, private and
bottom-up coordination, and fair representation of the Internet community.110
NSF transferred authority to the U.S. Department of Commerce to administer the cooperative
agreement under which domain name registration services are provided.111
Internet constituencies (e.g., those that attended the workshops held under the auspices of the
International Forum on the White Paper) discussed how the new entity (the New Corporation, or
"NewCo") might be constituted and structured. A group led by Jon Postel (and under his name)
proposed a set of bylaws and articles for the incorporation of NewCo. The final version of
NewCo's (then named as the Internet Corporation for Assigned Names and Numbers; ICANN)
bylaws and articles of incorporation were submitted to NTIA in October. On November 25,
NTIA and ICANN signed an official memorandum of understanding (MOU), with an initial
termination date of September 30, 2000.
In October, NTIA and NSI extended their cooperative agreement through September 2000. NSI
committed to a timetable for the development of a shared registration system (SRS) that permitted
multiple registrars to provide registration services within the .com, .net, and .org gTLDs.
Also, NSI agreed to separate its registrar and registry operations into separate divisions, to
recognize NewCo, and to make no changes to the root without written approval from the U.S.
government.
By 1996, the belief by some (e.g., Jon Postel) that additional TLDs were needed led to
the establishment of the International Ad Hoc Committee (IAHC) to develop a framework for the
administration of domain names, which became known as the Generic Top Level Domain
Memorandum of Understanding (gTLD-MoU). The IAHC's proposal for an institutional
framework prompted a strong reaction from a few key constituencies and "sent ripples through
the international system," as characterized by Milton Mueller.112 Although the gTLD-MoU was
not implemented, its creation did motivate the discussions leading to the development of the
Green and White Papers (see Box 2.3) and the eventual creation of the Internet Corporation for
Assigned Names and Numbers (ICANN) in late 1998.
NSI exclusively operated the .com, .net, and .org TLDs through 1998. The registry
operations (associated with the management of the TLD databases themselves) and registrar
operations (associated with the retail functions of dealing with customers) were integrated.
NTIA's agreement with NSI in late 1998 required NSI to separate its registry and registrar
functions so that other registrars could enter the market. To facilitate the entry of other firms,
NSI also agreed to establish a shared registration system to enable all registrars (including NSI's
109 See <http://www.ntia.doc.gov/ntiahome/domainname/dnsdrft.htm>.
110 For the text of the White Paper see <http://www.ntia.doc.gov/ntiahome/domainname/6_5_98dns.htm>.
111 See <http://www.nsf.gov/od/lpa/news/media/ma9822.htm>.
112 From Milton Mueller, 2000, "Internet Domain Names: Property Rights and Institutional Innovation,"
Entrepreneurship and Economic Growth in the American Economy, Vol. 12, 93-131, p. 111.
2-29
Prepublication Copy--Subject to Further Editorial Correction
registrar unit) to interact with the registry database. The vibrant market for domain name
registration services in the .com TLD that developed in the late 1990s also spurred interest in the
creation of new TLDs.
Thus, the DNS has experienced an extraordinary evolution since its birth in the early
1980s. Initially intended to address specific technical and operational problems of concern to a
small, relatively homogeneous group of computer scientists and engineers, the DNS came to
involve many other groups such as lawyers, businesspeople, national governments, public interest
groups, non-profit organizations, and others. The issues surrounding the DNS became
increasingly non-technical in nature and increasingly complex and controversial, and so the
founding of ICANN did not end the conflict among constituents, but rather provided the forum
through which the conflicts became further intensified. Chapters 3 and 5 further explore these
conflicts and the alternatives for their possible resolution.
2-30
Prepublication Copy--Subject to Further Editorial Correction
3
The Domain Name System: Current State
The Domain Name System (DNS) in 2005 serves a global 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.
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
1 This section elaborates on the high-level explanation in Chapter 2. It draws extensively on: Paul Albitz and
Cricket Liu. 2001. DNS and BIND. Sebastopol, Calif.: O'Reilly & Associates.
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.
3-1
Prepublication Copy--Subject to Further Editorial Correction
root
indns.cstb.nas.edu?
root
Name Server
.edu
Name Server
edu
com net
ISP
Caching
Name
Server
nas.edu
Name Server nas.edu mit.edu
indns.cstb.nas.edu
IP Address of
cstb.nas.edu
Name Server
IP address
cstb.nas.edu
DNS System
indns.cstb.nas.edu?
Stub
Resolver
Application
FIGURE 3.1 Operation of the Domain Name System without a local name server.
3-2
Prepublication Copy--Subject to Further Editorial Correction
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 host 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.
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 computer4 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.5 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.
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.
4 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.
5 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 (DARPA). Name servers
are discussed further in Section 3.2.3.
3-3
Prepublication Copy--Subject to Further Editorial Correction
In Figure 3.1, the query is shown as going first to a name server offering recursive services
located at the user's ISP.6 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 DNS 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)7 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 and/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 and/or addresses of the name servers that are authoritative for nas.edu."
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 answer 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 previously 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.
6 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.
7 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.
3-4
Prepublication Copy--Subject to Further Editorial Correction
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).8 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 each of the satellites and the
root name server if the attacker wished to disable all access to the service.9 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.10 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.
8 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. See Box 3.2 for an explanation of RFCs. All RFCs are available at <http://www.rfc-
editor.org/rfc.html>.
9 And even then other root name servers and their satellites would be accessible.
10 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, which is 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.
3-5
Prepublication Copy--Subject to Further Editorial Correction
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.11 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.
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.12 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 structure13 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 ASCII14 comprising the 26 letters of the Roman alphabet, the
11 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. 2003. "Wow, That's a Lot of Packets."
Proceedings of Passive and Active Measurement Workshop. Available at
<http://www.caida.org/outreach/papers/2003/dnspackets/>.
12 The evolution of the DNS is described in Chapter 2.
13 They will be stored in whatever data structures the local database software requires.
14 American National Standards Institute. "USA Code for Information Interchange." X3.4. 1968.
3-6
Prepublication Copy--Subject to Further Editorial Correction
10 numerals from 0 to 9, and the hyphen. Labels may not begin or end with a hyphen. 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."15 and
"www.nas.edu" 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 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
15 Note the trailing dot after "edu."
3-7
Prepublication Copy--Subject to Further Editorial Correction
source of the query. Generally, resolvers are just a set of library routines within a name server, a browser,
or an operating system.
Second, there must be name server software that performs the functions described in Section 3.1.
As noted above, the most common name server software is BIND,16 which is used on the majority of
name servers on the Internet.17 There have been many versions of BIND produced since it was originally
written in the early 1980s. The most recent releases (as of February 2005) are BIND 8.4.6, which extends
and enhances prior versions, and BIND 9.3.0 and 9.2.4, which is the latest release of a major rewrite of
the underlying architecture undertaken in response to anticipated demands resulting from the rapid growth
of the Internet. Although originally written for Unix operating systems, BIND has been programmed for
other operating systems, including Windows NT and Windows 2000.18 It has also been used as the basis
for many vendor name servers.19
The rest of this section uses BIND as an example because it is widely deployed. However, other
name server software may behave differently in some respects and still conform to the domain name
server standards.
A name server running BIND, or a comparable program, has complete information and authority
over the zones for which it is authoritative. It contains all domain names from the top of its zone down to
its leaves, except for those that are delegated to zones within it. See Figure 3.2.
Each zone must have a primary master (or primary) server that receives the contents of the zone
data file from some manually prepared local file. The primary server is the ultimate source of information
about the corresponding domain. There generally is at least 1 and possibly as many as 12 secondary
servers, which obtain copies of the zone data file from the primary or another secondary.
BIND has not traditionally made severe computational or storage demands on the computers that
run it. It has often been implemented on old machines that have been taken out of front-line service.
However, BIND 9 incorporates security and other features that impose much more severe computational
loads. In general, the computational requirements on a name server depend on the number of queries per
second and the relative distribution of the types of queries (because some types of queries impose greater
computational demands than others), as well as the extent of change of the zone files. The memory
requirements are determined by the size of its cache and zone files. In the latest versions of BIND, the
cache size can be controlled. In general, the cache size for a new name server is determined by
observation of the name server's operation over a few weeks to determine how much memory is required
to respond to the query demand at its installation.
16 BIND also contains a resolver library.
17 According to a survey by Internet Systems Consortium, Inc. in January 2004 it was used by almost 75,000
servers; the second most popular name server software was provided by Microsoft for almost 15,000 servers. For
more information about the survey and BIND, see "ISC Internet Domain Survey," March 10, 2004, available at
<http://www.isc.org>.
18 See "DNS Server Software" at <http://www.dns.net/dnsrd/servers/> for a survey of DNS servers available on
various operating systems.
19 A current list is posted at <http://www.isc.org/>.
3-8
Prepublication Copy--Subject to Further Editorial Correction
Root
= delegation
com
org
edu
edu zone
ucla
smu
smu.edu zone
ucla.edu zone
mit
mit.edu zone
sloancf
eecs
eecs.mit.edu zone
sloancf.mit.edu zone
web
Web.mit.edu
.edu domain
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, Fourth Edition, O'Reilly, 2001.
3-9
Prepublication Copy--Subject to Further Editorial Correction
3.2.4 Standards
The queries and responses that flow between name servers must be in a protocol that is readily
interpretable by any name server, no matter which software and hardware it uses. To that end, the data in
the queries and responses are, like the zone data, represented as resource records (Box 3.2).
BOX 3.2
Resource Records
Resource records are used in every DNS zone data file and every DNS message.20 Resource
records begin with a domain name (NAME), which is followed by the type (TYPE) and class
(CLASS) fields. Those fields are followed by the time to live (TTL) and a data field (RDATA),
appropriate to the type and class. Domain names and IP addresses make up a large portion of the data
in a typical zone data file.
NAME: The domain to which the record refers.
TYPE: Describes the type of data to be found in the resource record. The list of possible types is
open-ended; each is associated with a type code. There were more than 50 in January 2003, of which
no more than 20 are used to any extent.
Examples: A = host IP address; NS = an authoritative name server; MX = mail exchange.21
CLASS: Only one class, IN for Internet, is widely used. Four classes have been defined to date,
one of which is obsolete.
TTL: Specifies the time interval (in seconds) that the resource record may be cached before the
source of the information should again be consulted.
Example: 86400 (equivalent to one day).
RDATA: Describes the resource in question.
Example: If the class = IN and the type = A, this field is an IP address.22
If the class = IN and the type = NS, this field is a domain name.
DNS Zone Data File
Each DNS zone has a zone data file (also called the master file) that contains both resource
records describing the zone and actual data records for the zone. The former group specifies:
The authority for a zone, including the IP address of the primary name server and the e-mail
address of the responsible person, as well as times associated with updating the secondary name servers;
All the name servers that are authoritative for the zone; and
The IP addresses of the name servers (name-to-address mappings) that are in the zone.
There can also be data files that contain reverse mappings (i.e., tables for conversion from IP
addresses back to computer names). The domain names in these files look like IP addresses turned back to
front, and they all end in in-addr.arpa.23
20 For further detail, see RFC 1035.
21 For an explanation of "mail exchange," see Section 2.3.3.
22 Since each Type-A resource record in Class IN can include only one IP address, a domain name that maps to
multiple IP addresses will have multiple resource records--one for each IP address.
3-10
Prepublication Copy--Subject to Further Editorial Correction
The zone data file may contain some additional types of resource records. The specification of
resource records allows additional types of data to be added in the future, as required.
DNS Message Format
The DNS message format comprises five sections, some of which may be empty:
Header,
Question: the question for the name server (includes domain name),
Answer: resource records answering the question,
Authority: resource records pointing toward an authority, and
Additional: resource records holding additional information.
The lengths of the four sections that follow it are specified in the header section.
The practical limitation on the number of root name servers to 13 is a consequence of the DNS
message format and the design decision to use datagrams employing a minimal protocol--the User
Datagram Protocol (UDP)24--to send DNS queries and responses so as to achieve high performance.
Because in current practice there must be room within the datagram answer section for a list of all root
servers--in order to update the list of root servers25 in every iterative resolver--the number of root
servers is constrained by the maximum length of that section.26 To maximize the number of root servers,
their names were shortened and standardized for more efficient compression, increasing to 13 the
maximum number that could fit in the space available.
3.2.5 Functions and Institutions
There are two critical functions that the DNS institutional framework performs in support of the
standards and the programs that define the DNS. The first is maintenance of the DNS standards, and the
second is ensuring the availability of DNS name server software. DNS client software, primarily stub
resolvers, is widely available in standard software--operating systems, Web browsers--and the specifics
of their provision are not further considered here.
Maintenance of the DNS Standards--The Internet Engineering Task Force
The definition and maintenance of the basic standards for the DNS are the responsibility of one
informal organization--the Internet Engineering Task Force (IETF) (see Box 3.3). The IETF has
attracted experienced and knowledgeable technical talent, who volunteer considerable time to its
activities. The requests for comments (RFCs) process has provided a means for this diffuse technical
community to build a freely available, peer-reviewed store of knowledge and the successful standards and
protocols that enable the Internet and the DNS to function reliably and to adapt smoothly to the additional
23 Addresses are converted to names in the .arpa domain for DNS lookup. The in-addr.arpa zone contains the
hosts associated with all registered IP addresses.
24 For more information on the User Datagram Protocol, see John Postel, "User Datagram Protocol," RFC 768,
August 28, 1980.
25 As noted above, every iterative resolver needs to know where the name servers for the root zone are in order to
have a starting point for a non-local, non-repeat query.
26 In theory, the response could be a list of name servers that contain the names and locations of root name servers.
Also, the hints file, which is local, could contain information about more than 13 name servers. However, the
limitation to 13 has not yet been judged to be a large enough issue to change current practice in either respect.
3-11
Prepublication Copy--Subject to Further Editorial Correction
requirements imposed by increased scale, new applications, and new classes of users. Although the
IETF's standards and protocols underpin the worldwide Internet and the DNS, it does not have the
authority, the political or economic power, or the interest to force their adoption or validate their
implementation. Rather, their universal use has been the result of the practical benefit of having freely
available high-quality standards that all can share, and that give no organization proprietary advantage.
As a volunteer collaborating body, the IETF periodically restructures its processes. In 2003, the IETF
identified a number of problems, both routine and structural, in its operations and initiated a process of
problem resolution.27 As is typical, it did so publicly via the RFC process.
BOX 3.3
The Internet Engineering Task Force and Requests for Comments
The Internet Engineering Task Force (IETF)28 is a voluntary, non-commercial
organization comprising individuals concerned with the evolution of the architecture and operation of
the Internet. It is open to anyone who wishes to participate and draws from a large international
community. However, almost all its participants are technologists from universities, network
infrastructure operators, and firms in related industries. Although the IETF holds three meetings each
year at locations around the world, much of its work is conducted through the circulation of e-mail to
electronic mailing lists. The IETF divides its activities among working groups, organized into areas
that are managed by area directors (ADs). The ADs, in turn, are members of the Internet Engineering
Steering Group (IESG). The Internet Architecture Board (IAB) provides general oversight on Internet
architecture issues and adjudicates appeals that are unresolved by the IESG, but it is not actively
involved in standards development or implementation. The Internet Society (ISOC) charters the IAB
and IESG.29
Requests for comments (RFCs) were established in 1969 to document technical and
organizational aspects of the Internet (originally the ARPANET). RFC memos discuss protocols,
procedures, programs, concepts, and various other aspects of the Internet. The IETF defines the
official specification documents of the Internet Protocol suite that are published as "standards-track"
RFCs. RFCs must first be published as Internet-Drafts--a mechanism to provide authors with the
ability to distribute and solicit comments on documents that may ultimately become RFCs. An
Internet-Draft, which can be published by anyone, has a maximum life of 6 months, unless updated
and assigned a new version number. The Internet-Drafts that are intended for progression onto the
standards track, and some other documents at IESG discretion, are "last called," which involves an
announcement being sent out to the Internet community that the IESG wants input on the document.
The Last Call is usually of a few weeks duration. Using input from it, the IESG makes a decision on
further processing of the Internet-Draft. Such decisions might include rejection of the draft,
publishing it as a standards-track document, or handling it in some other way. Documents that are
considered valuable and permanent, including all standards-track documents, are then submitted to
the RFC editor for publication as RFCs.30
27 The problem statement and the history of the response are described in E. Davies, ed., 2004, "IETF Problem
Statement," RFC 3774, May, available at <http://www.ietf.org/rfc/rfc3774.txt?number=3774>; and E. Davies and J.
Hoffman, eds., 2004, "IETF Problem Resolution Process, " RFC 3844, August, available at
<http://www.ietf.org/rfc/rfc3844.text?number=3844>.
28 For a full description, see Susan Harris, "The Tao of IETF--A Novice's Guide to the Internet Engineering Task
Force," RFC 2160, August 2001. Available at <http://www.ietf.org/rfc/rfc2160.txt?number=2160>.
29 For more information on the evolving relationship between ISOC and IESG, see
<http://www.isoc.org/isoc/related/ietf/>.
30 For details on this process, see Scott O. Bradner, 1996, "The Internet Standards Process, Revision 3,"
RFC 2026, Internet Engineering Task Force, October, available at <ftp://ftp.rfc-editor.org/in-notes/rfc2026.txt>.
For background on RFCs and a searchable repository of RFCs, see <http://www.rfc-editor.org>.
3-12
Prepublication Copy--Subject to Further Editorial Correction
Providing Root Name Server Software--Internet Software Consortium, Inc. and Other Software
Providers
Internet Systems Consortium, Inc. (ISC), a not-for-profit organization formerly called the Internet
Software Consortium, has assumed responsibility for continuing maintenance and development of
BIND.31 Although ISC's scope is considerably more focused than the IETF's, it, too, has played a key
role in the smooth development and operation of the Internet and the DNS. By continuing to evolve
BIND and making it readily available worldwide, free of charge, ISC has provided a widely adopted
implementation of the DNS standards promulgated by the IETF.
Implementations of BIND and other DNS server software are also available from Microsoft and
other software companies as well as from various providers in the form of freeware and shareware.
3.2.6 Assessment
Conclusion: The architecture of the Domain Name System has demonstrated the ability to scale
to support the Internet's rapid growth, never holding up its development because of an inability to meet
the challenges of vast increases in the number of domain names, users, and queries. Furthermore, it has
demonstrated robustness, never failing so extensively as to prevent the Internet from functioning for even
a few minutes. What failures there have been have occurred in subzones of the system and have been
insulated from the rest of the DNS by its hierarchical, distributed structure.
The hierarchical architecture and caching have been critical to the ability of the DNS to scale
smoothly. First, they ensure that many queries are resolved locally, never reaching the higher levels of the
DNS. Second, even queries that do reach higher levels of the DNS do so only the first time they are made
by a specific name server in a given period (the TTL), with all subsequent queries from the same name
server during that period being answered locally.
These benefits are amplified by the ability of large ISPs, such as MCI and Verio, to maintain very
large caches and, thereby, to handle a substantial portion of the queries originating from their customers
without ever passing them along to the DNS.
Conclusion: Through its RFC process, the IETF has created a store of knowledge and a body of
standards and protocols that have, thus far, enabled the Internet and the DNS to function reliably and to
adapt smoothly to the additional requirements imposed by increased scale, new applications, and new
classes of users. Though ISC's scope is much more focused than the IETF's and its participation and
decision-making processes are far less open and public, by continuing the evolution of BIND and making
it readily available ISC has brought most of the IETF DNS standards32 into practical effect.
However, the continued growth of the Internet is posing new challenges and placing new
demands on the DNS architecture. The issues of future security and robustness, internationalized domain
names, and the intersection of the DNS with the telephone system are addressed in Chapter 4.
31 Information about ISC is available at <http://www.isc.org>.
32 This issue is complex since not all of IETF's standards are mandatory or even recommended, and some are
experimental or turn out to be bad ideas. The situation also differs between BIND 8, which is on end-of-life
maintenance, and BIND 9, which is an entirely new code base. BIND 9 is believed to adhere to all the mandatory
specifications, while ISC has eliminated non-compliant code from BIND 8 whenever it has been identified.
3-13
Prepublication Copy--Subject to Further Editorial Correction
3.3 IMPLEMENTATION--THE DOMAIN NAME SYSTEM ROOT ZONE
The top of the DNS inverted tree is its root, or more properly, the root zone (see Section 3.1.1).
The root zone name file (or, simply, root zone file) is stored in 13 root name servers, which use it to
respond to queries to the root. As shown in Section 3.1, while queries can enter lower on the tree if their
resolvers have current cached information, or if the query lies within the zone of the local name server,
the root serves as the assured point of entry to the DNS for any other query.
3.3.1 Characteristics of the Root Zone
Defining Characteristics
The root zone file defines the DNS. For all practical purposes, a top-level domain (and, therefore,
all of its lower-level domains) is in the DNS if and only if it is listed in the root zone file. Therefore,
presence in the root determines which DNS domains are available on the Internet.33 As Internet use has
grown, especially with the explosive growth of the Web and its reliance on domain names as key parts of
Web site addresses, entry of a top-level domain into the root zone file has become a subject of substantial
economic and social importance. Consequently, who controls entry into the root, and by what means,
have become controversial subjects. The current process for resolving these issues is described in Section
3.3.3.
Critical Characteristics
The root zone and the root name servers are critical to the operation of the DNS. The effective
and reliable operation of the DNS, and of the Internet, is entirely dependent on the accuracy and integrity
of the root zone file (and its copies) and the security, reliability, and efficiency of the root name servers.
Fortunately, the root zone has proven highly resilient and resistant to errors or disruptions.
One possible source of error is an incorrect entry--a mistyped domain name or an erroneous IP
address--in the root zone file. A consequence could be misdirection of queries seeking a particular top-
level domain (TLD) name server, say .net. That could prevent users searching for the address of any
domain name within that name server's TLD, say any address in .net, from reaching it through the
specific root name server containing the incorrect entry. If the error were updated in all copies of the root
zone file, access would effectively be denied to all domain names in that TLD, except from name servers
that had previously cached the correct address.34 However, relatively simple error detection and correction
procedures can quickly prevent such errors. (For example, most large top-level domains are programmed
to regularly query the root to ensure that it is properly routing queries seeking that TLD.)
A possibly disruptive event would involve one or more of the root name servers being non-
operational for hours or more. This might happen because of the unexpected failure of a computer or
communication link (accidental or purposeful) or because of regular maintenance. However, since the
capacity of each name server is many times greater than its average load, and iterative resolvers can use
any of the root name servers, other name servers can take up the load without degradation in the system's
performance that is perceptible to users. Moreover, in recent years such outages have been very rare.35
33 The IP addresses for the servers of well-known TLDs are widely available, and so to them presence in the root
may be less important. For less well known and new TLDs, however, presence in the root is the critical question.
34 This exception would hold true only until the TTLs of the cached addresses expired.
35 For example, in 2000, four of the 13 root servers failed for a brief period because of a technical mistake. In 1997,
a more serious problem involving the transfer of an incorrect directory list to seven root servers caused much of the
traffic on the Internet to come to a stop. As reported in "ISC Sets Up Crisis Centre to Protect Domain Name
3-14
Prepublication Copy--Subject to Further Editorial Correction
Although, as noted, there have been instances in the past of errors in the root zone file that have
had significant effects on the reliable operation of the DNS, there have been none in recent times. At
least for the current rates of queries and of changes in the root zone file, the systems of error checking and
correction and of capacity sharing appear to be working successfully.
Unique Characteristics
The design of the DNS is predicated on the existence of a single authoritative root that ensures
that there is one and only one set of top-level domains. However, some of those who object to the pace at
which new generic TLDs have been added to the root, or to the process by which they have been selected,
have sought a solution through the addition of one or more roots. They have been joined by some who
believe in the principle that having competition in the delivery of root services would benefit Internet
users.
On the other side are those who argue that additional roots would compromise the reliable
operation of the Internet by, among other things, opening the possibility of multiple addresses, associated
with different entities, being assigned the same domain name.36 Most experienced technologists view the
idea of introducing multiple roots for the DNS as threatening the stable operation of the DNS.
Moreover, since which domains are accessible to a user would depend on which of the multiple
roots were used, these technologists see a multiple-root DNS as balkanizing the Internet. Although there
may be some benefits from having competing roots, the presence of network externalities37 encourages
ISPs and name servers to converge on a single root that provides global compatibility. Consequently,
many technologists and economists believe it is unlikely that an alternative root would achieve
widespread success.38 In their view, while competition may serve a valuable purpose in the short term,
the task of maintaining the root zone file will equilibrate on a single, dominant root zone file, albeit an
equilibrium in which operational control is shared among a number of (non-competing) entities.39
There have been several attempts to create alternate roots that have data about the TLDs that are
recognized by the current root servers plus some additional TLDs that the operator of the alternate root is
trying to promote. However, these attempts have generally been unsuccessful, in large measure because
of the lack of global compatibility among the domain names recognized only by alternative roots, which
has made users unwilling to use them. However, one company--New.net--claims to have reached
financial profitability, to have registered over 100,000 domain names, and to be potentially accessible to
175 million Internet users through allied ISPs and browser plug-in software. It offers 12 additional TLDs
in English as well as in each of Spanish, French, Portuguese, Italian, and German.40 Although the
continued existence of New.net can be seen as a challenge to the DNS and ICANN's management of the
root zone file, it has not thus far appeared to have had any significant effect on either. Furthermore, in
System," Sydney Morning Herald, October 21, 2003, available at
<http://www.smh.com.au/articles/2003/10/21/1066631394527.html>.
36 See, for example: M. Stuart Lynn. 2001. "ICP-3, a Unique, Authoritative Root for the DNS." ICANN, July.
Available at <http://www.icann.org/icp/icp-3.htm>. Also, Internet Architecture Board. 2000. "IAB Technical
Comment on the Unique DNS Root." RFC 2826. May.
37 Network externalities are the increased benefits received by one user of a system as the number of users of the
system increases.
38 Milton L. Mueller. 2002. "Competing DNS Roots: Creative Destruction or Just Plain Destruction?" Journal of
Network Industries. Vol. 3. No. 3.
39 If an alternate root attracts a sufficient number of registrations, it raises the possibility that TLDs in the alternate
root and registrations within these TLDs could be created for speculative purposes. If ICANN creates a TLD that
already exists in an alternate root, the organization that controls the corresponding TLD in the alternate root could be
willing to transfer the registered names to the ICANN TLD--for a price.
40 Information obtained from <http://www.new.net/> in February 2004.
3-15
Prepublication Copy--Subject to Further Editorial Correction
September 2004, New.net was acquired by the Vendare Group, an online media and marketing company,
as the basis for a division offering search services, while continuing to offer domain name registration.41
3.3.2 Technical System of the Root Zone
The Root Zone File
The root zone file contains resource records for all the TLDs as well as for the root. In January
2004, there were 258 sets of entries. Of those, 243 were country code TLDs (ccTLDs) and 15 were
generic TLDs (gTLDs). (One of the gTLDs was the domain .arpa that is used for infrastructural
purposes, which is sometimes considered a separate category.) Because there are multiple records in the
root zone file for each of the subdomains, there were a total of 2143 records in the root zone, which
translates to about 78 kilobytes of storage. Moreover, although, as noted earlier, all the root name servers
together execute, in total, several billion searches a day on this file,42 this is well within their
computational capability because of the substantial overprovisioning of the system.
The Root Name Servers
Like other zone files, the root zone initially had a primary or master server accessible from the
DNS and several--in this case, 12--secondary or slave servers. That primary zone file was the most
current of the files, and all updates and changes were made to it; it served as the reference source for the
root zone. The secondary files were updated from it on a regular basis, at least twice daily. Starting in
1996 and achieving adoption by all secondaries by the end of 2001, the role of the primary was
transferred to a "hidden primary," which is a server that is used to update the secondaries but is not itself
accessible from the DNS. VeriSign operates this hidden primary. All 13 of the public root name servers
are now secondaries, including the former primary. Digital signatures, error checking, and correction
processes are in place to minimize the chance of introducing errors or being successfully attacked during
updates.
The December 2004 status of the group of 13 named root name servers is shown in Table 3.1.43
They are designated by the letters A through M. The A-root server, a.root-server.net, was until
recently the primary but, as noted above, has been replaced by a hidden primary. See Box 3.4.
Although the home locations of some of the root servers are the result of historical accident, they
were originally determined by analysis of network traffic flows and loads, seeking to have at least one
server "close" in terms of message communication time to every location on the network. It is important
to have root servers distributed so that they provide a uniform level of service across the network.44
Having a root server in a well-connected area is fairly unimportant to that area, since users there are likely
to be able to reach several servers. By contrast, if an area is fairly isolated from most of the network, it is
important that the ISPs that serve it acquire sufficient connectivity to enable the area's users to access one
or more root servers at all times.
41 The Vendare Group. 2004. "The Vendare Group, Online Media and Marketing Company, Acquires Search-
Services Provider New.net." Press release, September 17. Available at <http://www.new.net/id_9172004.tp>.
42 The F-root server (which includes its satellites), one of 13 root servers, answered more than 272 million queries
per day according to the Internet Systems Consortium in January 2004. See <http://www.isc.org>.
43 For the current version of this table, see <http://www.root-servers.org>. That Web site also contains links to the
root name server operators and to other relevant information.
44 See Lee et al. 2003. "On the Problem of Optimization of DNS Root Servers Placement." Passive Measurement
and Analysis Workshop. Available at <http://www.caida.org/outreach/papers/2003/dnsplacement/>.
3-16
Prepublication Copy--Subject to Further Editorial Correction
BOX 3.4
VeriSign
VeriSign, Inc., founded in 1995, describes itself as providing "intelligent infrastructure services
that support the digital economy." Its acquisition in 2000 of Network Solutions, Inc. made it the registry
for three gTLDs: .com, .net, and .org and the operator of the A-root and the J-root name servers.
It currently operates the A-root and J-root name servers, the hidden root primary, and the name
servers for the .com, and .net TLDs. At the end of 2004, its Naming and Directory Services unit
managed a database of over 38 million names in the .com and .net gTLDs; owned and maintained 13
gTLD name server sites around the globe that handled the more than 14 billion transactions per day for
those two gTLDs; and provided access to the .com and .net gTLD registries for more than 150 ICANN-
accredited registrars that submit over 100 million domain name transactions daily to its Shared
Registration System.
As a registrar--through a subsidiary renamed Network Solutions, Inc. in 2003--it registered
more than 500,000 new domain names during the second quarter of 2002, and an additional 700,000
names were renewed or extended. More than 8.7 million active domain names in .com and .net were
under management by VeriSign's registrar. However, in October 2003, it sold Network Solutions to a
private equity firm for $100 million.45
Considerations of this type are both complex and important but were not sufficient to determine a
unique set of locations for the home sites of the 13 root servers. However, as the Internet has evolved,
these original locations became less satisfactory, which has been one of the reasons for the proliferation
by some operators--notably C, F, I, J, K, and M in Table 3.1--of satellite sites at different locations.
These satellite sites use anycast addressing (see Box 3.1), which enables servers with the same IP address
to be located at different points on the Internet. Copies of the F-root server, for example, can be placed at
multiple locations around the world. The widespread distribution of anycast satellites of the 13 root
servers has improved the level of service provided to many previously less well served locations.
Some have believed that 13 root name servers are too few to meet requirements for reliability and
robustness, which requires sufficient capacity distributed widely enough to protect against system or
network failures and attacks. Others have believed that more root servers are needed to satisfy
institutional requirements. Their concern arose from the belief that to be a full participant in the Internet, a
nation or region must have its own root name server. While technical reasons46 make it difficult to
increase the number of root name server IP addresses beyond 13, the rapidly increasing use of anycast
addressing has enabled the root name server system to respond to both the technical and institutional
requirements through the addition of multiple geographically distributed anycast root server satellites.
Even so, since it addresses the distribution only of servers and not of the operating institutions, the
location issue is likely to continue to add some political acrimony to any selection process that might
follow from the withdrawal of one of the current operators. (See Section 5.3.)
There is no standard hardware and software implementation of the root name servers. Each of the
responsible organizations uses its preferred equipment and operating and file systems, although most of
them run some version of the BIND name server software.47 Although there might be some operational
advantages to having standard implementations, most Internet technologists believe that variation in the
underlying hardware and software of the root name server system is highly desirable, since it ensures that
45 This information was obtained from <http://www.verisign.com> on February 13, 2005.
46 See "DNS Message Format" in Section 3.2.4 for an explanation of the technical limitations.
47 Since BIND 8 and BIND 9 have different code bases, this is less of a problem than it would be if they were
identical. The K root runs NSD name server software from NLnet labs of Amsterdam.
3-17
Prepublication Copy--Subject to Further Editorial Correction
TABLE 3.1 The 13 Root Name Servers and Their Anycast Satellites as of December 2004
Name Operator
Locations
Country
A
VeriSign Naming and
Dulles, VA
USA
Directory Services
B Information
Sciences
Marina del Rey, CA
USA
Institute,
University of Southern
California
C
Cogent Communications
Herndon, VA; New York City; Chicago; Los Angeles
USA
D
University of Maryland
College Park, MD
USA
E
NASA, Ames Research
Mountain View, CA
USA
Center
F Internet
Systems
Ottawa; Palo Alto; San Jose, CA; New York City; San
USA
Consortium, Inc.
Francisco; Madrid; Hong Kong; Los Angeles; Rome;
Auckland; Sao Paulo; Beijing; Seoul; Moscow; Taipei;
Dubai; Paris; Singapore; Brisbane; Toronto; Monterrey;
Lisbon; Johannesburg; Tel Aviv; Jakarta; Munich;
Osaka; Prague
G
U.S. DOD Network
Vienna, VA
USA
Information Center
H
U.S. Army Research
Aberdeen, MD
USA
Laboratory
I
Autonomica/NordUNet
Stockholm; Helsinki; Milan; London; Geneva;
Sweden
Amsterdam; Oslo; Bangkok; Hong Kong; Brussels;
Frankfurt; Ankara; Bucharest; Chicago; Washington,
DC; Tokyo; Kuala Lumpur
J
VeriSign Naming and
Dulles, VA (2 locations); Mountain View, CA; Sterling, USA
Directory Services
VA (2 locations); Seattle, WA; Amsterdam; Atlanta,
GA; Los Angeles, CA; Miami; Stockholm; London;
Tokyo; Seoul; Singapore
K
Reseaux IP Europeens--
London; Amsterdam; Frankfurt; Athens; Doha; Milan;
UK
Network Coordination
Reykjavik; Helsinki; Geneva; Poznan; Budapest
Center
L ICANN
Los
Angeles
USA
M
WIDE Project
Tokyo; Seoul; Paris
Japan
SOURCE: This table derives directly from information provided at <http://www.root-servers.org> as accessed on
February 13, 2005.
an error in a particular piece of hardware or software will not lead to the simultaneous failure of all of the
root servers.
As the number and rate of queries to the root name servers have increased, hardware and software
upgrades have enabled the servers to keep up.48 However, the pace of inquiries is likely to continue to
grow and it is conceivable that it could, in principle, exceed the capacity of a system comprising even the
most powerful single computers. Because of anycasting and multiprocessing, through which a root server
can comprise multiple processors, the number of computers at each root-server address is effectively
unrestricted. Moreover, it is plausible to expect continued improvements in computing and
communications performance. Consequently, it is unlikely that the query load will ever be able to outrun
the computing capacity of the 13 named root name servers and their satellites.
48 This is only a portion of the total query load to the root zone file because of caching of queries by many name
servers, and especially those of large ISPs, as noted above.
3-18
Prepublication Copy--Subject to Further Editorial Correction
3.3.3 Institutional Framework of the Root Zone
Because the root is central and critical to the operation of the DNS, decisions about the root zone
and the root name servers are of substantial importance, and the institutions that bear responsibility for
them take on an important role as stewards of the DNS.
Those institutions carry out four critical functions:
1. Deciding what new or revised entries will be permitted in the root zone file;
2. Creating the root zone file, keeping it current, and distributing it to all the root name servers;
3. Selecting the locations and the operators of the root name servers; and
4. Establishing and continually and reliably operating the root name servers.
The diverse collection of institutions that performs these functions includes a not-for-profit
corporation--ICANN; a U.S. government agency--the Department of Commerce; a corporation--
VeriSign; and an informal group consisting of the commercial, non-commercial, and governmental root
name server operators.
Approving the Root Zone File--U.S. Department of Commerce and ICANN
The fundamental importance of the root zone file to the operation of the DNS and, therefore, of
the Internet means that special attention is paid to the process by which new or revised entries to the file
are authorized. Some process must be in place to decide whether a change is legitimate; otherwise,
persons or organizations with malicious motives or inadequate capabilities could make or revise entries.
Currently the authority to make changes lies with the U.S. Department of Commerce (DOC).49 However,
the day-to-day operational responsibility is at VeriSign. As part of the DOC's delegation of responsibility
to ICANN (see Box 3.5), the process of authorization for new or modified entries in the root zone was
changed. All such requests go first to the Internet Assigned Numbers Authority (IANA) (now a function
of ICANN) and then to the DOC for final approval. Once the addition or change is approved, the DOC
notifies IANA and VeriSign. VeriSign Naming and Directory Services then makes the change in the
hidden primary, which distributes the changed root zone file to the other root name servers (see
"Operating the Root Name Servers" in Section 3.3.3).
There are three kinds of changes to the root zone file. The first kind of change is a modification of
the data associated with an existing resource record. This might entail a change in the IP address of one
or more of the name servers resulting, for example, from a change in the network service provider. The
data entry process is straightforward, and so such changes should be routine and rapid. However, they do
require a stage of verification to ensure that the request is legitimate and not, for example, an effort by a
third party to capture a top-level domain. Nevertheless, such requests should be processed in a few hours
or days.
The second kind of change is a shift in the responsibility for a TLD, typically a ccTLD. In such
redelegation cases, the questions that must be resolved may be more difficult and time-consuming. (See
"Selecting the Organizations Responsibile for the TLDs" in Section 3.4.3 for a discussion of the issues.)
In particular, they may entail judging which organization has the "right" to operate the registry for a
ccTLD, which can become embroiled in national politics. These changes will generally take longer but
should proceed according to a formal and transparent process.
The third kind of change is the addition of data about a new TLD to the root zone file (see
"Selecting the Organizations Responsible for the TLDs" in Section 3.4.3). This is a single process for new
gTLDs. An ICANN selection process recommends both the domain name that shall be added and who
49 See Section 2.7 for a history of that authority.
3-19
Prepublication Copy--Subject to Further Editorial Correction
BOX 3.5
The Internet Corporation for Assigned Names and Numbers
As described in Chapter 2, the Internet Corporation for Assigned Names and Numbers (ICANN)
is a not-for-profit corporation founded in October 1998 in California by a group of individuals
interested in the Internet. It was sponsored by the U.S. Department of Commerce (DOC) to serve as a
technical coordination body for the Internet. Consequently, ICANN has assumed responsibility (under
a memorandum of understanding--and its six amendments--with the DOC) for a set of technical
functions previously performed under U.S. government contract by the Internet Assigned Numbers
Authority (IANA) and other groups. However, in practice, many of its most important and
controversial activities have been as a policy-setting, rather than as a technical coordination, body.
IANA continues as a function of ICANN with overall administrative responsibility for the
assignment of IP addresses, autonomous system numbers, top-level domains, and other unique
parameters of the Internet. In addition, ICANN is charged with coordinating the stable operation of
the Internet's root server system.
ICANN's primary governing body is its board of directors, which now comprises 15 voting
members and the president, ex officio. Dissatisfaction with the composition of the board and with the
nature of the selection process inspired a reform effort that resulted in new bylaws that guided the
selection of a new board in 2003. (See Section 5.2.4, Alternative F, for a description of this reform.)
ICANN has three supporting organizations: the Address Supporting Organization (ASO), which
deals with the system of IP addresses; the Country-Code Names Supporting Organization (ccNSO),
which focuses on issues related to the country-code top-level domains; and the Generic Names
Supporting Organization (GNSO), which handles issues related to the generic top-level domains. In
addition, it has four advisory committees: the At-Large Advisory Committee (ALAC) for the Internet
community at-large; the DNS Root Server System Advisory Committee (RSSAC) for root server
operators; the Governmental Advisory Committee (GAC) for governments; and the Security and
Stability Advisory Committee (SSAC) for security. There is also the Technical Liaison Group (TLG)
for standards-setting organizations and an Internet Engineering Task Force liaison who provides
technical advice to ICANN. The supporting organizations and advisory committees together represent
a broad cross section of the Internet's commercial, technical, academic, non-commercial, and user
communities and advise the board on matters lying within their areas of expertise and interest.
As part of the reform effort, ICANN adopted a new mission statement:
The mission of ICANN is to coordinate the stable operation of the Internet's unique identifier systems. In
particular, ICANN:
1. Coordinates the allocation and assignment of three sets of unique identifiers of the Internet--domain
names, IP addresses and autonomous system (AS) numbers, and protocol ports and parameter numbers.
2. Coordinates the operation and evolution of the DNS's root name server system.
3. Coordinates policy-development as reasonably and appropriately related to the performance of these
functions.
ICANN is open to the participation of any interested Internet user, business, or organization. It
holds several meetings a year at locations around the world.50
ICANN has been the subject of many controversies regarding its governance, its processes, and
its decisions since its founding. The primary issues are discussed in Section 5.2. A good sense of the
full range of controversies that have surrounded ICANN can be obtained from
<http://www.icannwatch.org>, CircleID (<http://circleid.com>), and ICANNFocus
50 Information about ICANN was derived from <http://www.icann.org> on February 13, 2005.
3-20
Prepublication Copy--Subject to Further Editorial Correction
(<http://www.icannfocus.org>), through the resources that can be linked to from these sites, and from
innumerable articles written about ICANN.
shall operate it. It is a two-step process for new ccTLDs. Who will be responsible for operations is a
separate recommendation from the decision to add a ccTLD name to the list of ccTLDs. Such changes
should take place within a few days after the appropriate decisions have been made.
Maintaining the Root Zone File--VeriSign
VeriSign, as the operator of the hidden primary root zone server, is responsible for maintaining
the root zone file and for distributing it to the secondary servers. It performs this function under the terms
of a memorandum of understanding (MoU) with the DOC.
Since any errors in the root zone file can affect large numbers of sites and users, accurate and
error-free preparation and distribution of the file are essential. In the first instance, this is a human
function. Someone must enter additions and updates into the database, create a new zone file, and check
it for errors. Individuals at the secondary sites must check to ensure that the file has not been corrupted
during its distribution. However, computer techniques and aids can be used to support this process and
reduce the demands on humans. Furthermore, regular queries of the root by each of the TLD operators
can be used to test the entries corresponding to their TLDs and provide further assurance that no
undetected errors are present in the file.
Selecting the Root Name Server Operators--Self-Selection
The current root name server operators were not selected through a formal evaluation and
qualification process, although they play a fundamental role in ensuring the availability and reliability of
the root. Rather, the group is the cumulative result of a sequence of separate decisions taken over the
years since the establishment of the DNS. It is a loosely organized collection of autonomous institutions
whose names are given in Table 3.1. Ten of them are based in the United States. Of those, three are
associated with the U.S. government (National Aeronautics and Space Administration (NASA),
Department of Defense (DOD), and the U.S. Army), two are universities (University of Maryland and
University of Southern California), two are corporations (VeriSign and Cogent Communications), and
two are not-for-profits (ISC, Inc. and ICANN). Three are based outside the United States: one in Sweden,
one in the United Kingdom, and one in Japan.
One of the responsibilities that ICANN assumed under its agreement with the DOC is
coordinating the stable operation of the root server system. To do so, it established the DNS Root Server
System Advisory Committee, whose responsibilities were spelled out in ICANN's bylaws (Article VII,
Section 3(b)).
The responsibility of the Root Server System Advisory Committee shall be to advise the
Board (of ICANN) about the operation of the root name servers of the domain name system.
The Root Server System Advisory Committee should consider and provide advice on the
operational requirements of root name servers, including host hardware capacities, operating
systems and name server software versions, network connectivity and physical environment . . .
should examine and advise on the security aspects of the root name server system . . . [and] should
review the number, location, and distribution of root name servers considering the total system
performance, robustness, and reliability.
The parties will collaborate on a study and process for making the management of the
Internet (DNS) root server system more robust and secure.
3-21
Prepublication Copy--Subject to Further Editorial Correction
ICANN's intent is to enter into an MoU51 with each server operator that will spell out the root name
server performance requirements, such as service levels, reliability, and security. However, as of
February 2005, no MoUs had yet been signed.
In the absence of an agreed oversight role for ICANN, there is, at present, no formal process for
selecting a new root name server operator if one of the incumbents should withdraw, although it is clear
that the set of remaining operators could, and probably would, work together to make the selection. (See
Section 5.3 for a discussion of this issue.)
Operating the Root Name Servers--The Root Name Server Operators
The role of the operators of the 13 root name servers is to maintain reliable, secure, and accurate
operation of the servers containing the current root zone on a 24-hour-a-day, 365 days-per-year-basis.
Each server is expected to have the capacity to respond to many times the rate of queries it receives and
must increase its capacity at least as fast as the query rate increases. An attempt to define the
responsibilities of the root name server operators was made in RFC 2870, issued in June 2000,52 but the
ideal that it describes has not been achieved.
Historically, the operators of the root servers have not charged fees for resolving Internet address
queries, instead obtaining support in other ways for the substantial costs they incur in providing the
service. These operators choose to do so either because (1) they believe that operating a root server is a
public service (and sufficiently inexpensive that they can afford the cost) or (2) they believe that operating
a root server conveys a business, or other, advantage to them. Nevertheless, it is a valuable service,
whose provision is a little-known and little-appreciated gift in kind to all users of the Internet.
3.3.4 Assessment
Conclusion: The system of DNS root name servers currently responds to several billion queries
per day and does so reliably and accurately as shown by its virtually uninterrupted availability and the
very low occurrence of root-caused misdirections. Because the majority of queries are served from cached
answers lower in the hierarchy, the entire DNS responds to many times that number each day with
correspondingly good results. However, the robust operation of the root name servers is potentially
vulnerable to an excessive query load, either inadvertent or malicious, that might slow down their
responses or cause them to fail to respond.
Data collected about root name server operation has revealed that a substantial fraction--between
75 percent and 97 percent--of the load on those servers may be the result of erroneous queries.53 These
errors fall into three categories: stupid--for example, asking for the IP address of an IP address; invalid--
for example, asking for the IP address of a nonexistent domain; and repetitive--for example, continuing
to send an incorrect query even after receiving a negative response. Analysis has revealed that the
sources of many of these errors lie in faulty resolver or name server software and faulty system
management that misconfigures name servers or resolvers and does not monitor performance closely
enough to catch errors. The latter is not purely a technical issue but poses an institutional issue.54
51 The DNS Root Server System Advisory Committee has drafted a model MoU, available at
<http://www.icann.org/committees/dns-root/model-root-server-mou-21jan02.htm>.
52 See Randy Bush, Daniel Karrenberg, Mark Kosters, and Raymond Plzak. "Root Name Server Operational
Requirements." RFC 2870. June 2000
53 The 97 percent figure is from the Wessels and Fomenkov study, op. cit. However, according to an anonymous
reviewer, VeriSign's experience on its two servers is closer to 75 percent.
54 These analyses have been sponsored by the Cooperative Association for Internet Data Analysis (CAIDA) and
have been reported in many publications. In addition to the Wessels and Fomenkov study, see, for example: Nevil
Brownlee, k.c. claffy, and Evi Nemeth. 2001. "DNS Measurements at a Root Server." CAIDA, Proceedings of IEEE
3-22
Prepublication Copy--Subject to Further Editorial Correction
Software developers, system administrators, and users generally have few incentives to make an effort to
prevent the occurrence of this extra load.
In addition, the system of root name servers may be vulnerable to malicious attempts to overload
it. In October 2002, the root name server system was subjected to such a, denial-of-service attack that
sought to swamp the system with queries.55 Eight of the 13 servers were inaccessible for an hour or more,
but the remaining 5 served the Internet without observable degradation. Although the system successfully
resisted this attack, which lasted only an hour and a half, it should serve as a warning about the potential
for longer and more sophisticated attacks in the future.
Conclusion: The root name servers receive far too many incorrect or repetitive queries,
increasing the load that they must serve. This unnecessary load arrives at the root name servers because
many sites on the Internet employ faulty software, misconfigure their resolvers or name servers, or do not
manage their systems adequately. The root name server operators, however, lack the means to discipline
the sites at fault.
Conclusion: The root name servers are subject to malicious attack, but through overprovisioning
and the addition of anycast satellites have substantially reduced their vulnerability to denial-of-service
attacks. Furthermore, the widespread caching of the root zone file and its long time to live mean that the
DNS could continue to operate even during a relatively long outage of most or all of the root name
servers and their satellites.
Recommendation: To be able to continue to meet the increasing query load, both benign and
malign, the root name server operators should continue to implement both local and global load balancing
through the deployment of anycast satellites.
Conclusion: Notwithstanding the deployment of anycast satellites, the concentration of root
servers in the Washington, D.C., area and, to a lesser extent, in the Los Angeles area remains a risk, since
anycast satellites depend on the 13 base root name servers to obtain root zone information.
Conclusion: The system of root name servers lacks formal management oversight, although the
operators do communicate and cooperate. Not everyone would agree that formal oversight is desirable.
Should one or more of the current root name server operators withdraw from that responsibility, or fail to
exercise it reliably, effectively, or securely, there would be no responsible organization or formal process
for removing the failed operator or for recruiting and selecting a replacement. In their absence, the
informal, collegial processes that led to the current group of operators would likely continue to be used.
Conclusion: The root name server operators have provided effective and reliable service to the
community of Internet users without any form of direct compensation for that service from the users.
With the growth in the scale and economic importance of the Internet, and with the expense of ensuring
secure operation, the root name server operators face increasing costs and potential liabilities that some, at
least, may find too great to meet without compensation.56 Indeed, the current system for maintaining root
Globecom, San Antonio, Texas. November. pp. 1672-1676. Also see
<http://caida.org/outreach/papers/2001/DNSmeasroot/>.
55 See, for example: David McGuire and Brian Krebs. 2002. "Attack on Internet Called Largest Ever." Washington
Post, October 22. Three root server operators coauthored an authoritative report about the attack. It can be found at
<http://d.root-servers.org/october21.txt>.
56 As President's Report: ICANN--The Case for Reform, February 23, 2002, notes ". . . some organizations that
sponsor a root name server operator have little motivation to sign formal agreements [with ICANN], even in the
form of the MOU that is now contemplated. What do they gain in return, except perhaps unwanted visibility and the
attendant possibility of nuisance litigation? They receive no funding for their efforts, so why should they take on any
3-23
Prepublication Copy--Subject to Further Editorial Correction
servers may well face additional economic pressures, as well as technical ones, as the volume of Internet
traffic increases, especially if the number of TLDs were to be expanded.
The root zone must be kept secure and robust in the face of possible future threats. Moreover, the
continued stable management and financing of root zone operations must be ensured for the DNS to
function. These challenges and approaches to meeting them are discussed in Section 5.3.
3.4 IMPLEMENTATION--THE TOP-LEVEL DOMAINS
The portion of the DNS hierarchy that has captured the most public attention and attracted the
greatest controversy is the level just below the root, the top-level domains. As noted above, in February
2005 there were 258 such domains in the two major categories defined in the early days of the DNS (see
Section 2.2.1): 243 country code top-level domains (ccTLDs) and 15 generic top-level domains (gTLDs).
These TLDs are, in turn, the top of a hierarchy of second-level domain names. Typically, the commercial
gTLDs have very flat structures with many second-level names, but the others vary widely, some having
very deep structures. The ccTLDs also have a wide range of structures, some having several levels of
hierarchy, which may be structured geographically or generically.
3.4.1 Characteristics of the TLDs
ccTLDs
The 243 ccTLDs are each associated with a nation (or external territory) and designated by the
two-letter abbreviation for that entity assigned by the International Organization for Standardization in
ISO 3166-1.57 Examples of ccTLDs are .ke for Kenya, .jp for Japan, and .de for Germany.58 The
expectation was that a ccTLD would signify a location and would be supervised and administered by an
organization in the corresponding country, and be limited to registrants with a presence there; however,
these criteria are not effectively enforced. Moreover, a number of small nations have licensed
administration of their domains--for example, .tv for Tuvalu and .cc for the Cocos Islands--to
commercial bodies that register anyone who wishes to use that ccTLD's two-letter domain. Such ccTLDs
are for all practical purposes equivalent to commercial gTLDs. This equivalence is further explored
in"Recharacterizing TLDs" in Section 3.4.1.
The largest ccTLDs are listed in Table 3.2, as are most of those ccTLDs, shown in boldface, that
have contracted for commercial use of their domains. The .us domain, which had been limited to third-
and fourth-level registrations in a locality-based hierarchy, is shown in italics. In April 2002, registration
at the second level in .us was opened with the intent that any U.S. citizen or resident and any business or
organization with a bona fide presence in the United States could register a domain name in .us.59
contractual commitments, however loose?" The same logic raises questions about their incentives to continue to
operate the root name servers.
57 See <http://www.iso.org/iso/en/prods-services/iso3166ma/index.html> for a list of the abbreviations.
58 There are a few exceptions to the use of ISO 3166-1 two-letter abbreviations. For example, the United Kingdom
is assigned .uk rather than .gb (for Great Britain). ICANN has also assigned ccTLD two-letter codes to each of the
Channel Islands and to Ascension Island, which are not in ISO 3166-1, because it was anticipated that they would be
added to the list.
59 The locality-based use of .us seems to be declining, which raises questions about the relative merits of
registrations at the second level and their associated revenue motivations versus the benefits of the locality-based
structure of .us.
3-24
Prepublication Copy--Subject to Further Editorial Correction
Table 3.2 shows the number of domains registered at the first available level under each top-level
domain in February 2003. The total at that time was just over 19 million. By December 2003, almost 24
million domains had been registered in ccTLDs, and by November 2004 it had reached 25.6 million. As
noted above, some country code TLDs have further generic or geographic substructures. In those cases,
the count of domains is the sum of those registered under each second- or third-level domain, depending
on the highest level at which registration by the general public is permitted.
gTLDs
There are 15 gTLDs, 8 that date from the early years of the DNS--.net, .com, .org,
.edu, .gov, .mil, .int, and .arpa--and 7 that were authorized by ICANN in November
2000. As their designations suggest, the expectation was that registration in the original gTLDs would be
by types of organizations. Commercial organizations were expected to register in .com, accredited
educational organizations in .edu, network infrastructure organizations in .net, U.S. government
organizations in .gov and .mil, and international treaty organizations in .int. The .org TLD was
created for organizations that did not fit into one of the other gTLDs. The designation .arpa was
assigned for network infrastructural use.
In announcing the authorization of the seven new gTLDs--.biz, .info, .name, .aero,
.museum, .coop, and .pro, ICANN distinguished between sponsored and unsponsored TLDs.
Those that are sponsored have a not-for-profit organization representing the community of potential
registrants. The charters of the sponsored TLDs specify that registrants are restricted to those satisfying
criteria appropriate to that community. Thus, .aero is restricted to people, entities, and government
agencies that (1) provide for and support the efficient, safe, and secure transport of people and cargo by
air and (2) facilitate or perform the necessary transactions to transport people and cargo by air.
Registrations in .museum are restricted to entities that are recognized by the International Council of
Museums as museums, professional associations of museums, or individuals who are professional
museum workers. And registrations in .coop are restricted to members of the international cooperative
movement, which is further defined by membership in one or more of eight specific classes. ICANN
allows unsponsored TLDs to be either restricted or unrestricted. Thus, .info is unrestricted--anyone
can register a name in .info, whereas .name is restricted to individuals and .biz is restricted to bona
fide business or commercial uses. Determination of who is eligible to register is up to the domain
operator operating under the terms of its agreement with ICANN.
The 15 generic TLDs are shown in Table 3.3 together with, for each, its type and purpose, the
organization responsible for its operation, and the number of second-level domains that are registered in
it. Note, however, that in many domains there are far more registrants at the third and lower levels.
3-25
Prepublication Copy--Subject to Further Editorial Correction
TABLE 3.2 Large Country Code Top-Level Domains
ccTLD
Country Name
Registered Domainsa
.de
Germany
6,117,000
.uk
United Kingdom
4,168,000
.nl
Netherlands
827,000
.it
Italy
767,000
.ar
Argentina
627,000
.jp
Japan
568,000
.us
United States
529,000
.kr
Republic of Korea
507,000
.cc
Cocos (Keeling) Islands
500,000
.ch
Switzerland
500,000
.dk
Denmark
428,000
.br
Brazil
427,000
.au
Australia
343,000
.ca
Canada
310,000
.at
Austria
272,000
.tv
Tuvalu
262,000
.be
Belgium
238,000
.ws
Western Samoa
183,000
.cn
China
179,000
.pl
Poland
175,000
.fr
France
163,000
.ru
Russian Federation
156,000
.za
South Africa
134,000
.tw
Taiwan
123,000
.nu
Niue
112,000
.to
Tonga
97,000
TOTAL (including ccTLDs not listed above)
25,637,000
NOTE: Individual domain data is for February 2003; the total is for November 2004.
aSOURCE: ICANN's Budget for Fiscal Year 2003-2004. See
<http://www.icann.org/financials/revised-proposed-budget-24jun03.htm>. Domain name counts where not
available are estimated from the average of all other ccTLDs for which data is available (from Web sites or other
direct information). These estimated counts represent about 16 percent of all ccTLD domain names. The total (for
November 2004) was provided by Matthew Zook, Department of Geography, University of Kentucky.
Recharacterizing TLDs
Although a distinction between generic TLDs and national or country code TLDs is widely
accepted and used in policy discussions, the reality of practice is that the distinctions have been
significantly eroded.
Among the generic gTLDs, three--.edu,60.mil, and .gov--are currently restricted to new
registrations by U.S. organizations and, in principle, could have been established as second-level domains
under the .us ccTLD.
As noted above, among the ccTLDs, a number--including .cc, .tv, .bz, .ws, .nu,
and .to--actively seek global registrants and function as though they were gTLDs.
60 Some non-U.S. educational institutions, such as the University of Toronto and the United Nations University,
retain their registrations from an earlier, less restrictive time. Also, registrations from foreign but U.S.-accredited
educational institutions are currently being accepted.
3-26
Prepublication Copy--Subject to Further Editorial Correction
Moreover, the registrants in some gTLDs have not been limited to those originally expected. In
practice, .com, .net, or .org have all been operating as unrestricted TLDs--any person or
organization can register in them.
Since many policy issues concern the desirable number and type of TLDs, it is useful to introduce
a characterization of TLDs that better captures the reality of their current state.
In Table 3.4, the TLDs are recharacterized into eight types, designated by the numbers 1 to 8,
which are given in the first column. The second column, "TLD," indicates whether the domain is
currently considered a gTLD or a ccTLD.
The "Scope" column shows whether the TLD is open to registrants from anywhere on the
globe--global--or is primarily for those who are located within the national boundaries of the country--
national. (Many ccTLDs that are primarily national will accept some non-national registrants, but usually
they must have an association with the country.) In addition, the .arpa TLD is open only to register
elements of the infrastructure of the Internet, so its scope is designated as infrastructural.
TABLE 3.3 Generic Top-Level Domains in 2004
gTLD Type Current
Purpose
Organization
Domainsa
.com
Unsponsored Unrestricted
VeriSign
GRS
33,352,000
.net
Unsponsored
Unrestricted
VeriSign GRS
5,324,000
.org
Unsponsored
Unrestricted
Public Interest Registry (PIR) as of
3,307,000
January 1, 2003
.edu
Sponsored
U.S. accredited higher
Educause
7,400
educational institutions
.mil
Sponsored
U.S. military
U.S. DOD Network Information
?
Center
.gov
Sponsored
U.S. governments
U.S. General Services
1,100
Administration (GSA)
.arpa
Sponsored Internet
infrastructure
Internet Architecture Board/
?
Internet Assigned Numbers
Authority (IANA)
.int
Unsponsored International
treaty
IANA
88
organizations
.info
Unsponsored
Unrestricted
Aflilias, LLC
3,334,000
.biz
Unsponsored Businesses
Neulevelb
1,088,000
.name
Unsponsored
Individuals
Global Name Registry
87,000
.pro
Unsponsored Professionals
Registry.pro
--c
.museum Sponsored
Museums
MuseDoma
658d
.aero
Sponsored
Air-transport industry
SITA
4,000+e
.coop
Sponsored
Cooperatives
DotCooperation, LLC
7,992f
TOTAL
46,412,000g
aSOURCE: ICANN's Budget for Fiscal Year 2003-2004. See
<http://www.icann.org/financials/revised-proposed-budget-24jun03.htm>. Domain count data provided courtesy of
Matthew Zook, Department of Geography, University of Kentucky. Ongoing data series is available at his Web site
<http://www.zooknic.com/>
bNeulevel is a joint venture of Neustar, Inc. and Australia-based Melbourne IT, Ltd.
c.pro started accepting registrations in the United States on June 1, 2004, from licensed MDs, lawyers, and CPAs;
added Canadian and U.K. professionals in Septemeber 2004; and added engineers in February 2005.
dData provided by Cary Karp, president and CEO, MuseDoma, private communication, February 20, 2004.
eAs listed on the .aero Web site in February 2005. See <http://www.information.aero/users.php>
fAs of February 2004. Carolyn Cooper, dot Coop Operations Center, private communication, March 17, 2004.
gTotal reported on the Zooknic Web site (<www.zooknic.com>) February 2005.
3-27
Prepublication Copy--Subject to Further Editorial Correction
The "Restriction" column in Table 3.4 indicates whether the generic TLD or, within national
boundaries, the ccTLD has second- or third-level domains that are intended to be restricted to members of
specific communities (however, the enforcement of these restrictions varies widely). Most ccTLDs have
no restrictions on registrations at the second level, but some, such as .ar (Argentina) and .au
(Australia), and the .us (United States) until recently, register only at the third level under a limited
number of restricted second-level domains, such as com.ar and com.au for commercial organizations.
However, Great Britain, .uk, has some second-level domains that are restricted, such as ltd.uk and
plc.uk, and others, such as co.uk, that are not. As with other aspects of the DNS, restriction within
ccTLDs is not really "yes" or "no," but more accurately "yes," "no," or "some." That situation is
reflected in Table 3.4 by treating second-level domains of such ccTLDs as though they were "separate"
TLDs--see the examples in 7 and 8.
TABLE 3.4 Types of Top-Level Domains
Type TLD
Scope
Intended
Restriction Sponsor
Examples
1 gTLD
Global
No
No .com, .net,
.info, .org
2 gTLD
Global
Yes
Yes .aero,
.museum,
.coop
3 gTLD
Global
Yes
No .biz, .name,
.pro, .int
4 gTLD National
Yes
Yes .mil, .gov,
.edu
5 ccTLD
Global
No
- .cc, .tv, .bz
6 ccTLD National
No
- .jp, .fr,
.us, .co.uk
7 ccTLD National
Yes
- com.au,
id.au,
.ltd.uk,
8 gTLD Infrastructural
Yes
Yes .arpa
The "Sponsor" column indicates whether an organization representative of a community has
responsibility for managing a gTLD and for enforcing registration restrictions, if any. The concept of
sponsor for a ccTLD is less clear. To some degree, for example, the governments of the United States and
of France, for example, can be viewed as the sponsors of their ccTLDs. The corresponding entries are left
blank.
Thus, among the 15 current gTLDs, 4 are of Type 1--.com, .net, .org, and .info.
Type 2 includes three TLDs--.museum, .aero, and .coop. There are four in Type 3: .name,
.biz, .pro, and .int. That leaves three in Type 4--.edu, .mil, and .gov, which are
discussed below as ccTLDs--and one in Type 8, .arpa.
It has not been possible to assign a type to each of the 243 ccTLDs, but examples of each of the
four types have been identified in Table 3.4.
Type 5 comprises many ccTLDs that function as generic TLDs. As noted above, they are
generally small countries that have recognized, or been shown, that their two-letter designation can be
marketed globally to companies and individuals who would find it commercially or personally valuable.
Thus, the lease of the domain name of Tuvalu (population: 11,000) will provide that Pacific Island nation
with $50 million in royalties over the next dozen years. The .TV Corporation, a subsidiary of VeriSign,
in April 2004 listed on its site such "premium registrations" as sports.tv, which is available for $1 million,
and real.tv, which would cost the registrant $250,000. The administrator of this TLD is the Ministry of
3-28
Prepublication Copy--Subject to Further Editorial Correction
Finance and Tourism of Tuvalu, although in fact, the ministry appears to have delegated all of its
decision-making authority to the .TV Corporation as a part of the lease. Other nations are managing their
globally available domains themselves. Western Samoa (population: 178,000), another Pacific island
nation, markets .ws directly and handles the registration locally. Western Samoa had two ISPs and 3000
Internet users in 2002.61
While some ccTLDs function as gTLDs, Type 4 comprises the three gTLDs that function like
ccTLDs--.edu, .gov, .mil. All three are limited to registrants in the United States that are, in
turn, restricted to specific communities--primarily accredited higher educational institutions,62 civilian
government63 agencies, and federal military agencies.
The remaining two types distinguish between restricted and non-restricted ccTLDs. Almost all
ccTLDs are unrestricted at the second and third levels and fall into Type 6, but some, such as Australia,
Argentina, and Austria, have introduced categories resembling the gTLD categories as their second levels.
They belong to Type 7. Thus, Australians cannot register directly in the .au domain but must instead
use the category appropriate to their status: com.au for commercial organizations, asn.au for
associations, id.au for individuals, and so on.
Thus, the apparently simple distinction between gTLDs and ccTLDs is really more complex. The
differences among TLDs lie in the differences in the policies that they operate under, not in whether they
were originally associated with a country code or a generic category.
3.4.2 Technical System of the TLDs
Every TLD has an associated zone file, which is stored in name servers whose addresses are
recorded in the root zone file. ICANN requires that there be at least two name servers for each ccTLD
and at least five for each gTLD with which it has agreements. Some TLDs have as many as 13 name
servers, depending on the query load, the need for security against attack, and their desire to improve
access by their users. Each name server is implemented on one or more computers, most of which run a
version of BIND.64
The zone files on all TLDs are larger, generally very much larger, than the root zone file. At the
extreme, .com contains more than 33 million second-level domains, but even Greenland has more than
1200 domains registered. Moreover, because of the hierarchical nature of DNS search, the ease of
caching the labels and associated resource record sets in the small root zone file, and the long TTLs
within that file, the TLD name servers receive a greater number of queries than the root name servers. For
example, according to VeriSign .com and .net alone receive over 14 billion queries per day, while the
root receives several billion queries per day.
TLD name servers face specific unique technical issues distinct from those that involve the roots.
One issue is increased traffic resulting from low TTLs on second-level zone records. A popular second-
level zone can increase traffic to its parent TLD name servers by lowering its TTL, effectively defeating
the DNS's caching mechanism. (The root name servers do not suffer from this potential problem to the
61CIA. 2004. The World Factbook. Available at <http://www.cia.gov/cia/publications/factbook/index.html>.
62 As noted previously, some non-U.S. academic institutions have been "grandfathered in" or will be registered if
they are accredited in the United States. Also, there are some other exceptions such as the Thomas Jefferson High
School for Science and Technology, whose domain name is tjhsst.edu.
63 Originally it was limited to federal agencies. It is now open to registration by state and local governments and
Native Sovereign Nations.
64 However, the name server for .org (and for some other TLDs) is operated by UltraDNS, which uses its own
proprietary name server software; and VeriSign, which runs .com, .net, .bz, and .tv, also uses its own
proprietary name server software, Atlas.
3-29
Prepublication Copy--Subject to Further Editorial Correction
same extent, since TLD name servers give out mostly referrals. As a result, name server caches
throughout the Internet retain the copy of the TLD records from the root zone with their 48-hour TTLs.65)
TLDs probably receive some bogus queries, but perhaps not as many as the root, since at least a
portion of the query must be correct--the TLD name. Their name servers face the same vulnerabilities
that are faced by the root name servers. However, although the effect would be significant if the
operations of large TLDs such as .com or .uk were to be interrupted, the consequence of a short
interruption of most TLDs, individually, would not be significant for the overall Internet. An attack that
could take out a substantial number of TLD servers would be significant but difficult to sustain because of
the number of distinct targets that would be involved.
3.4.3 Institutional Framework of the TLDs
The effective operation of the top-level domains requires that an institutional framework perform
four functions:
1. Deciding which new TLDs will enter the root zone file,
2. Determining the organization to be responsible for a TLD,
3. Determining the organization to operate a TLD's name server, and
4. Operating the TLD registry.
Many different organizations, international and national, governmental and private, for-profit and
not-for-profit, including ICANN, VeriSign, and the DOC, are engaged in these activities. Their processes
and interactions are complex and, often, controversial.
Selecting New TLDs
The original DNS design assumed a single, unified, name space (in which the set of names that
one user is able to look up is the same set of names that any other user is able to look up).66 Unless
uncoordinated entry into the root zone file is permitted, which would require that the operators of the root
servers recognize any TLD that chooses to operate, some entity must decide how many and which TLDs
there will be and who will operate them. "Selecting new TLDs" means deciding which new TLDs will
enter the root zone file. As described above, that decision is made by the U.S. Department of Commerce
upon the recommendation of ICANN. Therefore, it is in the first instance a decision for ICANN. The
decision process that is employed differs between ccTLDs and gTLDs.
ccTLDs
There is generally no need for a complex decision process for entry of ccTLDs since, as noted
earlier, they are available to countries and external territories represented by country codes in ISO 3166-1.
This list has been used as the authoritative source for country codes because, as was stated in RFC 1591,
"the IANA is not in the business of deciding what is and what is not a country."67 When new entities are
assigned a two-letter identifier by the ISO, that entity is automatically entitled to have a ccTLD.
However, two situations have arisen that cannot be resolved solely by this rule. The first occurs when a
country is removed from the ISO list. The two-letter code for the Soviet Union, SU, was removed from
the list in September 1992 and placed in "transitional reserved status," which means that its use should be
65 Information provided by an anonymous reviewer.
66 It is this assumption that alternative or multiple roots violate. This discussion assumes a single root.
67 Jon Postel. 1994. "Domain Name System Structure and Delegation." RFC 1591. Internet Engineering Task Force.
March. p. 6. Available at <ftp://ftp.rfc-editor.org/in-notes/rfc1591.txt>.
3-30
Prepublication Copy--Subject to Further Editorial Correction
stopped as soon as possible. But, although this issue is on ICANN's agenda, it has not yet addressed the
complicated issues that arise when a country is removed from the ISO 3166-1 list. Indeed, it is still
possible to register in the .su domain, and this domain remains in the root.
The second situation occurs when an international entity requests a ccTLD that is not on the ISO
3166-1 list. In July 2000, the European Commission wrote to ICANN requesting the inclusion of the .eu
domain in the DNS root.68 Its request noted that the ISO had agreed to use of the two-letter code EU as a
TLD. (The code, although not in ISO 3166-1, had "exceptional reserved status" enabling its use for
specific ISO-approved purposes.) At its September 25, 2000, meeting, the ICANN board passed a
resolution that approved for delegation as ccTLDs those codes from the ISO's exceptional reserved list
for which the reservation permits any application requiring a coded representation of the entity.69 In
March 2005, ICANN authorized the creation of the .eu TLD, which is expected to begin operation in
early 2006.70 It will be open to any person living in the EU, as well as businesses with their headquarters,
central administration, or main base in the EU. 71 The exceptional reserved list is no longer published,
and a policy has been implemented to prohibit the creation or reservation of an unrestricted name that is
not on the ISO 3166-1 list.
The process of deciding who will be delegated responsibility for operating a ccTLD upon its
first entry into the root, or for redelegating responsibility subsequently, can become very complex. This
process is discussed in the next section and in Section 5.5.
gTLDs
The gTLDs are a different matter. They fall into two groups: the first eight, which were selected at
the time of initiation of the DNS--the legacy gTLDs; and the seven that were selected by ICANN in 2000
for addition to the root--the new gTLDs. (An additional 4 to 10 are expected to be added during 2005 as
the result of an ICANN selection process initiated in 2004. See Alternative A under "What Selection
Process Should Be Used" in Section 5.4.2.)
The legacy gTLDs were selected by the developers of the DNS and a group of network and
information center operators. Jon Postel, writing almost 10 years later, still maintained a policy that he
expressed as: "It is extremely unlikely that any other TLDs will be created."72 However, by the following
year, Postel had changed his mind and recommended the creation of new TLDs to compete with NSI,
which had a monopoly in commercial gTLD registrations, and in 1996 he recommended the creation of
150 or 300 new TLDs. At the same time, the rapid growth in size and scope of the Internet, driven by the
introduction of the World Wide Web, created a heavy demand for second-level domain names in the
gTLDs, especially in .com. (See Section 2.5.1.) That, in turn, led to a public demand for additional
gTLDs. In response to that demand (some would argue it was a belated response), ICANN created a
process, which it used during the year 2000 to select the new gTLDs. ICANN treated the addition of
gTLDs as an experiment in order to seek compromises that would satisfy the contending interest groups,
although that did not prevent the additions from becoming controversial. Since that process also entailed
selecting the organizations responsible for the TLDs and the TLD name server operators, its description is
deferred to "Selecting the TLD Registry Operators" below.
68 Letter from Erkki Liikanen, member of the European Commission, to Mike Roberts, (then) CEO and president of
ICANN, dated July 6, 2000. Available at
<http://europa.eu.int/ISPO/eif/InternetPoliciesSite/DotEU/LetterLiikanenRoberts.html>.
69 ICANN. 2000. "Preliminary Report. Special Meeting of the Board." September 25. Available at
<http://www.icann.org/minutes/prelim-report-25sep00.htm#00.74>.
70 See Ellen Dumout. 2005. "ICANN approves .eu Net domain." March 24. c/net news.com. Available at
<http://news.com.com/2100-1038_3-5634121.html>.
71 See the October 2004 EU Fact Sheet, "Open for Business in 2005: yourname.eu.", available at
<http://europa.eu.int/information_society/doc/factsheets/017-doteu-november04.pdf>. There is a more complex
story behind the .eu TLD, but it is beyond the scope of this chapter.
72 Postel, 1994, RFC 1591, p. 1.
3-31
Prepublication Copy--Subject to Further Editorial Correction
To at least some degree, TLDs compete with one another for the patronage of those entities that
wish to register domain names, although the maximum prices that ICANN has negotiated with the gTLDs
limit the extent of this competition. This competition might be more intense--both with respect to the
prices charged and the services offered--the larger the number of competitors, although beyond some
point the effect of additional entry is likely to be small and the costs of switching from one domain to
another are likely to give incumbents a strong advantage. In any event, even when firms wish to operate
TLDs, either because they observe incumbents earning large profits or because they believe they can offer
better or cheaper services, entry is constrained by their need to obtain approval from ICANN for inclusion
in the root file.73
Over the past few years, the demand for registrations in the TLDs has gone through several
changes. While the ccTLD registrations have grown continually throughout the period, those in the
previously rapidly growing gTLDs declined in the aftermath of the .com bust and only began to grow
again in mid-2002. According to ICANN writing in mid-2003: "The domain name counts for ccTLDs
have jumped 22% over the numbers used last year [in the budget]. The count for gTLDs, however, has
declined 5%, largely due to a drop-off in .com whose statistics dominate the overall gTLD count because
of its comparative size."74 In fact, the name counts in all three of the largest gTLDs--.com, .net, and
.org--declined from 2002 to 2003. Both .net and .org declined by 14 percent. However, by
August 2003, another source reported that the total number of .com, .net, and .org domain names
had returned to the high mark of 30.7 million reached in October 2001.75 Sustained growth had returned
in July 2002, and over the next 13 months the total registrations in those three domains grew an average
of 250,000 per month. As further confirmation of the renewed demand for those gTLDS, VeriSign
reported76 that an average of 1.2 million new registrations for domain names ending in .com and .net
were added each month in the third quarter of 2004--a 33 percent increase over the third quarter of
2003."77
Selecting the Organizations Responsible for the TLDs
ICANN has been delegated authority by the DOC (and subject to the DOC's approval) over
entries in the root zone and, consequently, it can determine which organization is delegated responsibility
for each ccTLD and gTLD. The delegated responsibility entails arranging for the establishment and
operation of (1) name servers for the TLD satisfying Internet technical requirements and (2) a domain
name registration process that meets the needs of the local or international Internet communities.
In the case of ccTLDs, the organizations with delegated responsibility are designated managers or
sponsors, and they are designated the sponsors for sponsored gTLDs. Sponsors are primarily either
government or not-for-profit organizations that provide their own funding, although profit-making
organizations run the commercial gTLDs and some ccTLDs. In both groups of TLDs, the responsible
organization need not operate the required name server and domain registration functions itself and
generally contracts with a specialist organization, which may be a commercial service, to carry out those
73 Some limitations on entry may have a legitimate practical basis. Nor is it clear whether a small number of large
TLDs are to be preferred to a large number of smaller ones. In any event, incumbents can be expected to wish to
limit the competition that they face, whether or not there is a legitimate basis for such limits.
74 Source: ICANN's Budget for Fiscal Year 2003-2004. See
<http://www.icann.org/financials/revised-proposed-budget-24jun03.htm>.
75 Zooknic Internet Intelligence. 2003. "gTLD Domains Returning to 2001 Levels." Press release. August 25.
Available at <http://www.zooknic.com/pr_2003_08_25.html>.
76VeriSign. 2004. "Verisign Issues Quarterly Domain Name Industry Brief; Overall Domain Name Registration
Tops Past Record of 66.3 Million." December 1. Available at <http://www.verisign.com/ceerisign-mc/news-and-
events/news-archive;us-news-2004/page_019484.html.>
77 See also Linda Rosencrance. 2004. "Domain Name Registrations Hit All-Time High." Computerworld. June 8.
Available at <www.computerworld.com/developmenttopics/websitemgmt/story/0,10801,93716,00.html>.
3-32
Prepublication Copy--Subject to Further Editorial Correction
functions. In the case of the seven unsponsored gTLDs (other than .int), the responsible organization
and the operating organization are the same and had until recently all been commercial services.
However, ICANN designated Public Interest Registry (PIR), a not-for-profit, to manage .org beginning
in 2003. PIR has contracted with a Dublin-based company, Aflilias, to provide the registration services
and Afilias has contracted, in turn, with a commercial provider of DNS services, UltraDNS, to run the
name servers.
For the ccTLDs and the legacy gTLDs, ICANN must have a process for recognizing the
organizations that will be responsible for the TLD when a new ccTLD is added or when a change of
responsibility is desired for whatever reason. The processes used for the ccTLDs and the legacy gTLDs
are different. They are described below. For the new gTLDs, the processes of selecting a manager and
selecting an operator were combined since the prospective manager's choice of operator was one factor in
the manager selection decision. That combined process is described below in "Selecting the TLD
Registry Operators."
ccTLDs
IANA began delegating responsibility for ccTLDs shortly after the deployment of the DNS and
most delegations predate the formation of ICANN. ICANN's policy has been not to challenge these
except in cases where a government seeks redelegation.78 In the early days of the DNS, responsibility for
ccTLD management was usually assigned to the Internet pioneers who volunteered for the task.
Generally, there was only one interested organization since, at the time, the commercial prospects were
thought to be minimal. Even so, there was considerable due diligence on many applications to determine
that other possible applicants had been identified and, if there were any, that they supported the active
application. There were, however, some cases of multiple applications and post-delegation challenges by
those who sought various other benefits such as prestige or the ability to leverage the role into sale of
Internet services. The managers agreed to abide by a set of policies for the administration and delegation
of ccTLDs that covered technical requirements and the circumstances under which IANA would make or
change a delegation of responsibility.79 Often the corresponding governments did not know or did not
care about the Internet or the applicable ccTLD.
With the growth in the size and importance of the Internet and the formation of ICANN, that
situation has changed. Governments increasingly want to participate in the selection and oversight of the
manager of their ccTLDs.80 Furthermore, ICANN felt the need for more precisely described agreements
spelling out the mutual obligations and responsibilities among governments, ICANN, and the delegated
managers of ccTLDs. Consequently, the board of ICANN authorized the development of such
agreements with the ccTLDs.
According to ICANN, it was soon realized that no single agreement or, even, structure of
agreement would fit every ccTLD. However, after consideration of the wide variety of specific
circumstances in the 243 ccTLDs, ICANN found that most would fit into one of two general situations
that differ principally in the involvement of the local government or public authority. In the first, legacy
situation, the government is not involved. In the second, triangular situation, it is, thus yielding three
participants: a ccTLD, ICANN, and a local government. ICANN proposed two types of agreements,
corresponding to these two situations.
According to the proposed agreement for the legacy situation, the ccTLD manager would operate
under the oversight of ICANN only, subject of course to the laws of the country. ICANN would have the
78 This section draws extensively on: ICANN. 2001. "Update on ccTLD Agreements." September 20. Available at
<http://www.icann.org/montevideo/cctld-update-topic.htm>. See also Jon Postel, 1994, RFC 1591.
79 The general responsibilities of the ccTLD managers are documented in RFC 1591 and in the ICANN publications
ICP-1, Internet Domain Name System Structure and Delegation (ccTLD Administration and Delegation), May 1999,
and ccTLD Constituency Best Practice Guidelines for ccTLD Managers, 4th Draft, March 10, 2001. However,
neither of the ICANN documents appears to have achieved consensus among all the ccTLD managers.
80 See discussion in Section 5.5.2.
3-33
Prepublication Copy--Subject to Further Editorial Correction
sole responsibility to ensure that the ccTLD manager operates as a trustee for both the local and the
international Internet communities.
According to the proposed agreement for the triangular situation, ICANN would retain the
responsibility to see that the ccTLD manager meets its responsibilities to the international Internet
community and to any non-national registrants, while the local government would assume responsibility
for ensuring that the interests of the local Internet community are served.
According to ICANN, the decision as to which arrangement to pursue would be reached by the
government and the ccTLD manager (or candidate manager) in consultation with the local Internet
community, with ICANN adopting "a neutral stance."
In the legacy situation, ICANN would have the full authority to select and, when necessary,
change the ccTLD manager. (Although they are not signatories to the agreements, governments are
notified if one is in preparation in case they want to be involved.) In the triangular situation, the relevant
government or public authority would communicate its designation of a ccTLD manager to ICANN,
which would then decide whether or not to accept the designee and, assuming a positive decision, seek to
negotiate an appropriate agreement with the manager.
The proposed agreements with the ccTLDs are intended to cover the following areas: (1) the
delegation of responsibility to the ccTLD and description of the circumstances that would lead to its
termination, (2) specification of the local and global policy responsibilities of the ccTLD, (3)
characterization of the relationship with ICANN and their respective responsibilities, and (4) funding for
ICANN.
Despite ICANN's efforts to get ccTLDs to enter into agreements with it, by December 2004 it
had completed only 12 of them. A number of ccTLDs object to accepting ICANN's formal authority over
their operations. This issue is discussed in detail in Section 5.5.
gTLDs
ICANN has acted to change the organization responsible for several of the eight legacy gTLDs.
The most significant instance was its negotiation with VeriSign Global Registry Services, the legacy
manager of .com, .net, and .org. Because those three gTLDs contain the registrations of the vast
majority of the Internet's gTLD second-level domains and, in particular, almost all of those on its
unsponsored and unrestricted domains, VeriSign's position as the profit-making sole supplier of those
three was felt by many in the Internet community to be detrimental to the long-term health of the Internet.
In May 2001, VeriSign, Inc., ICANN, and the DOC signed a revised agreement in which VeriSign agreed
to give up its operation of .org at the end of 2002 while extending the term of its operation of .net to
the beginning of 2006 and of .com to November 2007. Both of the latter agreements are renewable,
although under different terms: under existing agreements, .net had to be put out for bid by ICANN by
the end of 2005, while VeriSign has presumptive renewal rights for .com, unless it materially breaches
the agreement. ICANN initiated an open bidding process for .net in 2004 and will select an operator in
2005.81
To select a new manager for .org, ICANN issued an RFP in May 2002. In response, it received
11 proposals from a variety of organizations, both commercial and not-for-profit. According to ICANN,
those proposals were reviewed by three independent evaluation teams that were charged with looking at
technical issues and at the ability of the proposals to meet the specific needs of .org. Comments were
also received from the public and the applicants, which, according to ICANN, were used by the ICANN
staff to prepare an evaluation report and recommendation. The ICANN board accepted the staff
recommendation and ICANN contracted with the PIR, a wholly-owned subsidiary of the Internet Society,
to become the manager of .org, effective January 1, 2003.
81 See ICANN.2004. ".NET Request for Proposals." December 10. Available at <http://www.icann.org/tlds/dotnet-
reassignment/net-rfp-final-10dec04.pdf>.
3-34
Prepublication Copy--Subject to Further Editorial Correction
Selecting the TLD Registry Operators
An organization that is responsible for reliably performing the functions of (1) operating the TLD
name servers and (2) registering second-level domains in the TLD is called a registry.82 It may or may
not be the same as the delegated manager for the TLD.
For example, VeriSign is the manager and operates the registry for .com and .net. PIR is the
manager of .org, but, as noted above, it has subcontracted with Afilias to operate the TLD registry,
which has contracted the name server function to UltraDNS. Afilias also operates the registry for .info,
for which it also serves as the manager, and for .vc, the ccTLD for residents of St.Vincent and the
Grenadines, which is managed by the Ministry of Communications and Works of St.Vincent and the
Grenadines.
There is always one, and only one, registry for a given TLD, but, as noted above, an organization
can be the registry operator for more than one TLD. While the majority of TLD managers are non-
commercial organizations, some registry operators are commercial organizations that operate for profit;
they register the vast majority of domain names.
ccTLDs
The manager of a ccTLD may also be the registry operator, or it may subcontract the registry
services in whole or in part to other organizations. The process for selecting the registry services operator
is entirely up to the ccTLD manager, subject only to whatever restrictions the national government may
impose. The situations differ widely among the 243 ccTLDs.
Since the growth of the World Wide Web has vastly extended the scope, scale, and importance of
the Internet, two phenomena have worked to shape the operational arrangements of ccTLDs in a country.
First, there has been a movement from the early informal arrangements, which often involved voluntary
efforts by the computer science department of a university in the country, to more formal arrangements
that provide legal protection and engage a wider national community in policy-setting roles. Second,
there has been a tendency to contract the actual operations to commercial organizations more willing and
able to undertake the responsibilities than academic institutions.
For example, in Austria, the current manager and registry is Nic.AT, which is a limited-liability
company that since 2000 has been wholly owned by a charitable foundation, the Internet Private
Foundation Austria. Nic.AT was established in 1998 by the Austrian ISP Association to take over
responsibility for the ccTLD from the University of Vienna, which had managed it from its inception but
was faced with an increasing number of registrations, legal questions, and name conflicts beyond its
competence. While Nic.AT handles the name registration, it contracts with the University of Vienna
computer center to run the .at name servers.
In contrast, the new registry and registry operator for the .us TLD is a commercial company,
Neustar, which also is the registry and registry operator for the new gTLD .biz. In the .us case, the
manager, the U.S. DOC, decided to change the operational model from a deeply hierarchical, mostly
geographic, extensively delegated structure to one that would be exploited commercially at the second
level. Unlike the Austrian case, there was no pressure for the change in strategy from the previous
manager or operator, and no significant pressure from users/registrants in the domain--indeed, many of
them argued against it. And the DOC RFP essentially required a commercial operator with commercial
intentions.
82 Registries can exist at any level, except the root, in the DNS (although in some respects ICANN could be viewed
as the registry for the root). In this section, only TLD registries are considered. The term "registry" is unfortunately
used ambiguously in this context. The database maintained by a registry is also called a registry, as are the
organizations that some registries subcontract with for database maintenance and operation, which are here called
registry operators.
3-35
Prepublication Copy--Subject to Further Editorial Correction
Legacy gTLDs
The registries for the legacy gTLDs are the consequence of history. NSI had been operating the
registries for .com, .org, and .net by agreement with the U.S. government when VeriSign
purchased it and assumed the responsibility. As noted above, PIR, upon becoming manager of .org,
contracted with Afilias to run the registry. The organizations shown in Table 3.3 for each of the other
legacy gTLDs are the associated registries (and also sponsors).
New gTLDs
In July 2000, the ICANN board adopted a policy for the introduction of new gTLDs that called for
the solicitation and submission of proposals to sponsor or operate them. In August 2000, the RFP was
published. It specified the contents of the detailed multipart proposal, which was to be accompanied by
extensive supporting documentation and a non-refundable $50,000 application fee. The deadline for
applications was October 2000.
As explained by ICANN, two types of gTLDs were specified: sponsored and unsponsored. In the
latter case, the application was to be submitted directly by the organization proposing to serve as the
registry. In the former case, the application was to be submitted by the sponsoring organization but
would include the proposal of an organization that had agreed to perform the registry functions for the
sponsoring organization. Thus, the registries for the new TLDs were selected through the ICANN
process whether ICANN made the decision directly or accepted the sponsoring organizations' selections.
ICANN announced that the selection criteria would be the following:
The need to maintain the Internet's stability;
The extent to which selection of the proposal would lead to an effective proof of concept
concerning the introduction of top-level domains in the future;
The enhancement of competition for registration services;
The enhancement of the utility of the DNS;
The extent to which the proposal would meet previously unmet types of needs;
The extent to which the proposal would enhance the diversity of the DNS and of registration
services generally;
The evaluation of delegation of policy-formulation functions for special-purpose TLDs to
appropriate organizations;
Appropriate protections of rights of others in connection with the operation of the TLD; and
The completeness of the proposals submitted and the extent to which they demonstrate
realistic business, financial, technical, and operational plans and sound analysis of market needs.
ICANN received 47 applications, of which 2 were returned for non-payment of the fee and 1 was
withdrawn, leaving 44 to be evaluated. The ICANN staff carried out evaluation with the assistance of
outside technical, financial/business, and legal advisors. ICANN's goal was to select a "relatively small
group of applications" that (1) were functionally diverse and (2) satisfied the selection criteria.
At its November 2000 meeting, the ICANN board acted on the staff evaluation and selected the
seven new gTLDs--.biz, .info, .name, .pro, .museum, .aero, and .coop. Four
were unsponsored--.biz, .info, .pro, and .name--and, therefore, amounted to the direct
selection of a registry as well as the TLD. The other three were sponsored, and each included a
designated registry chosen by the sponsor to operate its TLD.
The registries for .com, .net, .org and for the seven new gTLDs have agreed to pay
certain fees and adhere to certain requirements as spelled out in ICANN's sponsored and unsponsored
TLD agreements. (The registries for .edu, .gov, and .mil operate under separate agreements
with agencies of the U.S. government. ICANN is the registry for .int, and the Internet Architecture
Board (IAB) manages .arpa. Therefore, they do not have agreements with ICANN.)
3-36
Prepublication Copy--Subject to Further Editorial Correction
ICANN's TLD agreement obligates the sponsor and the registry to (1) satisfy functional and
performance specifications set by ICANN; (2) enter into agreements with any ICANN-accredited registrar
(see "Selecting the Organizations to Register Domains" in Section 3.5.2) desiring such an agreement and
accord the registrar fair treatment; (3) provide query and bulk access to registrant data--Whois
information (see Box 3.6); (4) periodically deposit its registrant data into escrow with an approved escrow
operator; and (5) comply with consensus policies established by ICANN.
The ICANN process for adding gTLDs that was implemented in 2000 was quite controversial.
Many participants and observers complained about the design and implementation of the process. The
issue of whether and how to add new gTLDs is examined in detail in Section 5.4.
BOX 3.6
Whois Service
Whois services provide contact information about the registries, registrars, or registrants in the
DNS. (See Sections 2.3.4 and 2.5.3 for information on the development of the Whois service and
background on the issues surrounding it.)
ICANN-accredited registrars are contractually obligated to collect and provide access to
information about the name being registered, the names and IP addresses of its name servers, the
name of the registrar, the dates of initiation and expiration of the registration, the name and postal
address of the registrant, and the name and postal, telephone, and e-mail addresses of the technical
and administrative contacts for the registered name. These must be made available either directly by
the registrar or, in some cases, by the registry.
There are many separate Whois services on the Internet run by registrars, registries, and other
organizations (often, as with universities, of their own second- or third-level domains). In addition,
there are numerous Web sites that provide links to many of the Whois sites, such as Allwhois.com
and Better-Whois.com.
Operating the TLD Registries
Every TLD registry operator must perform two basic functions: register domain names requested
by registrants and operate the name servers that will link those domain names with their IP addresses and
other critical information. Even these basic responsibilities may be divided between organizations, some
commercial and some non-commercial, as noted above in the cases of Austria and of .org. In contrast,
a single commercial organization, VeriSign, is the manager, runs the registry, and runs the name servers
for .com and .net.
The registration operation produces the entries to the zone file for that domain, the content of the
Whois file, and records of billing and payment, where appropriate. When the TLD has restrictions on who
may register either in the domain (such as restricting registrations to nationals or residents of a country or
to professionals or museums) or in its generic subdomains (such as Australian businesses in com.au or
British limited liability corporations in ltd.uk), each application for a domain name must be examined
to ensure that those restrictions are satisfied.
The ICANN agreements with 12 gTLDs include functional and operational specifications that the
registry operators are responsible for meeting, while the few agreements with ccTLDs specify only
general requirements for Internet connectivity, operational capability, and adherence to key RFCs, as well
as agreements to make financial contributions to ICANN. Ideally, all operators of TLD name servers
should satisfy certain minimal technical conditions to ensure their compatibility with the Internet and that
3-37
Prepublication Copy--Subject to Further Editorial Correction
they are configured so as not to pose a danger to the stability of the Internet, although there is no
mechanism for enforcing this for the TLDs not covered by ICANN agreements.
3.4.4 Assessment
Conclusion: The level of technical capability and competence varies widely across the 258 TLD
registries. The gTLDs and the large ccTLDs generally operate at a high level of availability and
responsiveness. Although there are no readily available measures of the performance of the majority of
ccTLDs, they appear to provide adequate service.
Recommendation: Regular and systematic testing of the availability and operation of secondary
servers should be adopted by top-level domain registry operators. Policies and procedures should be
developed to clarify what to do when problems are identified and what measures can be taken when
problems are not resolved within a reasonable period of time.
Conclusion: No single organization has the authority and the ability to oversee the operation of
all the TLDs. ICANN's formal authority extends only as far as the provisions of its agreements with 10
gTLDs and 12 or so ccTLDs and the authority it has to recommend changes in the root zone to
accommodate new or reassigned TLDs.
Even where there is a contract, ICANN's authority has been tested. VeriSign's introduction in
October 2003 of its Site Finder service raised fundamental issues of both a technical and an institutional
nature and has been challenged in the courts.83
3.5 IMPLEMENTATION--THE SECOND- AND THIRD-LEVEL DOMAINS
The domain names in the DNS hierarchy that Internet users interact with most directly are those
at the second level (or in those ccTLDs with fixed second-level domains, such as ltd.uk, those at the
third level). They are generally the key identifiers in e-mail addresses (such as
recipient@mailserver1.nas.edu) or a Web address (such as http://www.nas.edu). They are the names that
businesses, individuals, government agencies, non-profit organizations, and various other groups acquire
to identify themselves on the Internet--the names on their signposts in cyberspace. Over 70 million
second-level (and, in some instances, third-level) domain names had been registered by early 2005, with
about two-thirds in the gTLDs (more than half in the two largest gTLDs--.com and .net) and about one-
third in the ccTLDs.84
3.5.1 Technical System of the Second- and Third-Level Domains
Second- and third-level domains may have their own name servers to respond to queries to their
zone files, as most large organizations do, but often the services are provided by ISPs or other Web site
hosting organizations that store the zone file on their name servers. This is the course taken by most small
organizations and individuals, although there are many exceptions.
The zone file of a second- or third-level domain may be very small if it belongs, for example, to
an individual, or it may be quite large, if it is owned by a commercial or governmental organization. In
the latter case, a great many of the entries may be associated with the e-mail addresses of the thousands of
83 See Chapter 4 for a discussion of the Site Finder case.
84 See Tables 3.2 and 3.3.
3-38
Prepublication Copy--Subject to Further Editorial Correction
employees of the institution, while several, tens, or hundreds may be associated with the name servers of
lower-level zones. Often, institutions will own multiple domain names (e.g., nas.edu and
nationalacademies.org) that point to the IP address of the same server, enabling access to it under
different domain names.
3.5.2 Institutional Framework of the Second- and Third-Level Domains
The effective operation of the second- and third-level domains requires that three functions be
performed:
1. Selecting the organizations to register second-level domains,
2. Registering second-level domains, and
3. Resolving second-level domain name conflicts.
The principal organizations participating in this institutional framework are ICANN, the TLD registries--
the organizations that actually register most second-level domains--the registrars, and the organizations
that provide dispute resolution services. Although many of the organizations at this level are commercial,
numerous not-for-profit and governmental organizations play an active role as well.
Selecting the Organizations to Register Domains
In many cases, especially in the ccTLDs and some of the gTLDs, only the registry carries out the
registration of second- or third-level domains. However, in a 1998 white paper85 the DOC, responding to
a policy goal of privatizing and increasing competition in the market for domain name registration,
recommended opening the business of registering lower-level names in gTLDs to competition. It
subsequently amended its agreement with NSI, then the operator of the .com, .org, and .net registries,
to require it to develop a system of multiple registrars and put it into operation in 1999. The DOC
designated ICANN as the organization that would oversee the establishment of the Shared Registration
System (SRS) and would be responsible for establishing and implementing a system for registrar
accreditation. The SRS and registrar accreditation began operation in 1999. Before the multiple registrar
system, NSI charged $35 per year for registrations in its domains. At the beginning of 2005, registrations
in those domains in the United States could be obtained for less than $10 per year.86
Under the terms of their agreements with ICANN, gTLD registries are required to permit
registrars to provide Internet domain name registration services within their top-level domains. In
addition, these agreements regulate the price that registries can charge registrars--the "wholesale price,"
with the current regulated price being a maximum of $6 per year per registrant. One can think of the
regulation of the wholesale price as intended to constrain the exercise of market power by registries and
the requirement for competing registrars as intended to constrain the retail "margin."
To the extent that regulation of the wholesale price is intended to limit the exercise of market
power in the wholesale market, however, it is not entirely obvious why the wholesale price that can be
charged by new gTLDs, especially new gTLDs that are intended to serve diverse users, must be
regulated.87 Indeed, increased future competition, especially as the number of gTLDs is expanded, might
reduce or eliminate the need to regulate the wholesale price that VeriSign or other registries can charge.
But if regulation of the wholesale price is intended to prevent registries from exploiting existing
customers that may be locked in, there may be a continuing need to regulate wholesale rates even if the
85 Department of Commerce. 1998. "Management of Internet Names and Addresses." Federal Register. Vol. 63. No.
111. June. p. 31741.
86 For example, in February 2005, godaddy.com was offering .com registrations for $8.95.
87 Some specialized TLDs might continue to have market power even if the total number of TLDs were very large.
3-39
Prepublication Copy--Subject to Further Editorial Correction
registry market were to become more competitive. The significance of lock-in will depend on the
importance of switching costs, the flow of new registrants relative to the existing stock, and on whether
registries can discriminate between new and existing registrants.
There were in February 2005 more than 460 registrars from more than 20 countries accredited to
register domain names in 1 or more of the 10 eligible gTLD domains.88 Many of them have decided to
operate, at least in part, as wholesalers and suppliers of registrar services; those operations have enabled
many agents to sell domain names without any relationship with, or accreditation by, ICANN. Although
most ccTLDs use authorized agents, many ccTLDs have adopted the notion of multiple registrars, and
many ICANN-accredited registrars also register ccTLD second-level domain names.
ICANN accredits registrars through an open application process. Any organization wishing to
become an ICANN-accredited registrar must complete a detailed application concerning its technical and
business qualifications and pay a $2500 application fee. If approved by ICANN, the applicant must
execute the standard Registrar Accreditation Agreement89 and pay a yearly accreditation fee that is $4000
for the first TLD and $500 for each additional TLD for which the registrar is accredited. In addition, the
registrar must pay a quarterly accreditation fee to cover a portion of ICANN's operating expenses. The
fee is based, in part, on the registrar's share of registrations in the TLDs for which it is accredited.
Registrars that are accredited by ICANN must also enter into accreditation agreements with the registries
in the TLDs in which they want to register domains. Those agreements specify, among other things, the
fees to be paid to the registries for each registration. As noted above, a ceiling is imposed on that fee
structure by ICANN for the gTLDs that have signed agreements with ICANN.
The ICANN Registrar Accreditation Agreement imposes certain requirements on registrars. The
registrar is obligated to (1) submit specified information90 for each registrant to the registry; (2) enable
public Internet access to a file of information about registrants--the Whois file--both in query and bulk
access form; (3) maintain a file of all registrant information submitted to the registry; (4) regularly submit
a copy of the file to ICANN or to an escrow agent; (5) comply with consensus policies established by
ICANN; and (6) have for the resolution of name disputes a policy and procedures that comply with
ICANN's Uniform Dispute Resolution Policy. (See "Resolving Domain Name Conflicts" below.)
However, some of the newer gTLD agreements anticipate the possibility of "thick" registries, for
example, ones in which Whois and similar data are maintained by the registry, not the registrars. This
changes requirement (2) and has some impact on the others.
Registering Domain Names
Registration of second-level (or third-level) domain names occurs according to different
processes in the different types of TLDs. For the 10 gTLDs that use accredited registrars and for a
number of ccTLDs--for example, Great Britain, Australia, Canada, and Denmark--registrars compete to
sell second-level domain names in the TLDs they represent. They are free to set whatever fees they like,
subject only to competitive market forces and their obligations to pay registration fees to the registries.
For the .edu, .gov, .mil, .int, and .arpa gTLDs, as well as for most ccTLDs, registration
by members of the restricted group occurs directly at the registries.
The registrar stage of the DNS process appears to be quite competitive, with entry being
relatively easy91 and competition taking place along a number of dimensions. Registrars for the same
88 For the current list, see the ICANN site at <http://www.icann.org/registrars/accredited-list.html>.
89 A copy of the agreement can be found at
<http://www.icann.org/registrars/ra-agreement-17may01.htm>.
90 See Box 3.6.
91 This competition is facilitated by the Shared Registration System protocol, which allows registrars to enter names
directly in registries.
3-40
Prepublication Copy--Subject to Further Editorial Correction
registry compete with one another for the patronage of registrants92--what is sometimes called intra-
brand competition--with competition being based on both the prices and the services offered. These
services include the efficiency with which registrations take place as well as value-added services that
may be bundled with registration.93 Switching registrars within a given registry is not particularly
difficult, but there have been complaints that registrars have not always responded promptly to requests
for switching and that some registrars have aggressively and misleadingly solicited other registrars'
customers. In addition, domain name theft has been one of the problems associated with inadequate
procedures and security measures put in place by the registrars of domain names. In such cases, a third
party fraudulently claims to be the registrant in order to have the domain name transferred to its
ownership.94 There have also been instances of fraud charges against domain name registries and
registrars of domain names.
The
SnapNames
State of the Domain report listed 148 registrars in the CNO domains (.com,
.net, and .org) in the first quarter of 2003.95 However, "market shares" in these domains were
skewed, with the VeriSign registrar (now Network Solutions)96 having more than 25 percent of all
registrations in .com--which was, however, a significant decline from its 40 percent share only 15
months earlier;97 Tucows having about 10 percent; Register.com having approximately 9 percent; and
GoDaddy having somewhat over 6 percent. Thus, the share of the "market" controlled by the top four
firms in .com--the four-firm concentration ratio--was about 52 percent.98 Seven other registrars each
had more than 1 percent of all .com registrations. (More recent data were not available at the time of this
writing.)
The situation was somewhat different in the then newly opened .biz domain according to the
SnapNames State of the Domain, first quarter 2003 report. Although the VeriSign registrar (Network
Solutions) was the market leader, its share was only about 19 percent, 6 percent less than its share in the
.com domain. Other registrars with shares in excess of 6 percent were Register.com (10 percent),
Tucows (9 percent), and Melbourne IT (6 percent),99 so that the four-firm concentration ratio here was
only about 44 percent. SnapNames reports that there were 127 registrars of .biz names. As a result of
the wide disparity in the sizes of the various domains, Network Solution's approximately 25 percent share
of .com was about 5.8 million names, while its approximately 19 percent share of .biz was only about
170,000 names.100
92 This is not to say that registrars for different TLDs do not also compete with one another, a form of interbrand
competition. In addition to registering new domain names, registrars also participate in the secondary market for
domain names, acting as brokers, as well as in assisting registrants in applying for expired names.
93 SnapNames reported that GoDaddy, a registrar, gained 70,000 registrants in a month when it launched its free
online tax preparation software, presumably available only to its registrants. See the next section for a discussion of
value-added services, some of which are provided by firms that are not registrars.
94 In April 2004, the original operator of sex.com received a $15 million settlement from VeriSign because its
registrar service had incorrectly transferred ownership of the name to a fraudulent claimant.
95 SnapNames.com, Inc. 2003. State of the Domain, First Quarter 2003. May 13. Available at
<http://www.sotd.info/sotd/content/documents/SOTDQ103.pdf>. The SnapNames report showed over 150 ICANN-
accredited registrars operational at that time (pp. 31-34).
96 VeriSign sold its registrar, Network Solutions, to a private investment company for about $100 million in October
2003.
97 SnapNames.com, Inc. 2002. State of the Domain, January 2002. February 26.
98 The quotation marks around "market" and "market shares" are intended to indicate that no claim is being made
that registrar services in the .com domain constitute a relevant antitrust market. SnapNames reported that the top 10
registrars had about 75 percent of the market in the first quarter of 2003, down from about 91 percent at the end of
2001.
99 Recall that Melbourne IT is part of a joint venture with NeuStar, the operator of the .biz registry.
100 For further discussion of market issues and presentation of market data, see "Generic Top Level Domain Names:
Market Development and Allocation Issues," Organisation for Economic Co-operation and Development,
Directorate for Science, Technology and Industry, Committee for Information, Computer and Communications
3-41
Prepublication Copy--Subject to Further Editorial Correction
Finally, although registrars charge the same prices to all registrants, some registrars offer a back-
order service under which, for a fee, they will track the expiration of a desired domain name and attempt
to register it immediately if the registration lapses. However, multiple registrars may be trying
electronically to register the same name at the instant it becomes available. The one that tries at just the
right instant wins the prize. Because of this chance element, consumers often enter back orders with
multiple registrars. In March 2002, ICANN asked VeriSign to conduct a 12-month trial of a single wait-
listing service, which would take just one order--at a $24 fee directly from the consumer--for an
expiring name on a first-come, first-served basis. Thus, from the consumer's side, the need to use
multiple registrars would be eliminated, but from the registrar's side, the opportunity to derive additional
revenue would be lost. On July 15, 2003, a coalition of name registrars filed a lawsuit against ICANN
seeking to block the launch of VeriSign's global waiting list for domain names.101 At its March 2004
meeting, ICANN's board voted to seek the DOC's agreement to its approval of VeriSign's 1- year trial of
the wait-listing service.
Resolving Domain Name Conflicts
One of the most difficult institutional roles that the operation of the DNS requires is the resolution
of conflicts among competing claimants for domain names. These conflicts arise for a number of reasons
that are discussed in detail in Section 2.5. The one that has attracted the most attention is the use of
trademarked words in domain names, which is covered in "Trademark Conflicts" in Section 2.5.2.
Although domain names can be used for a number of legitimate purposes other than as an address for a
World Wide Web site, such as identifying a host, an e-mail server, an FTP site, and so on, the vast
majority of the disputes involving domain names are associated with their very visible use in association
with World Wide Web sites. Conflicts can also arise over names in which individuals, organizations, or
governments claim a proprietary interest other than a trademark.
Whatever the source, the practical use of the DNS, which assumes that every domain name will
be registered to one and only one entity, cannot proceed without some means for resolving conflicting
claims for the same name. In the early days of the Internet, before strong financial and political interests
were involved, such conflicts were handled informally, usually on a first-come, first-served basis, and
they still are in many ccTLDs.102 However, as domain names appeared on the signposts on the World
Wide Web and in e-mail addresses, and some gained visibility and potentially great value, the need to use
more formal processes became 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
Policy, Working Party on Telecommunication and Information Service Policies. July 13, 2004. Available at
<http://www.oecd.org/dataoecd/56/34/32996948.pdf>.
101 See Susan Kuchinskas. 2003. Embittered Registrars Sue Embattled ICANN. July 15. Available at
<http://siliconvalley.internet.com/news/print.php/2235661>.
102 See, for example, the terms and conditions for the .uk registry available at <http://www.nic.uk>.
3-42
Prepublication Copy--Subject to Further Editorial Correction
strict policies and regulations. The available techniques include imposing policies on the assignment of
names at the point of registration, name reservations103 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.104 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.105 ICANN has provided all of its newly
authorized registries with a list of reserved names that consisted of names and acronyms of organizations
related to the IETF and ICANN.106
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. Withdrawing 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.
103 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.
104 For example, see "Seven Dirty Words," Wikipedia online encyclopedia. Available at
<http://en.wikipedia.org/wiki/Seven_dirty_words>.
105 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>.
106 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-appk-26apr01.htm>.
3-43
Prepublication Copy--Subject to Further Editorial Correction
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 (UDRP). An answer, implemented by
ICANN in December 1999, based on a recommendation from WIPO, was the Uniform Domain Name
Dispute Resolution Policy (UDRP). 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. In agreeing to the registration agreement, the registrant also must 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:
(i)
registrant's domain name is identical or confusingly similar to a trademark or service
mark in which the complainant has rights; and
(ii)
registrant has no rights or legitimate interests in respect of the domain name; and
(iii)
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:
(i)
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
(ii)
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
(iii)
primarily for the purpose of disrupting the business of a competitor; or
3-44
Prepublication Copy--Subject to Further Editorial Correction
(iv)
intentionally to attract, for commercial gain, Internet users to registrant's Web site or
other on-line 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:
(i)
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
(ii)
registrant has been commonly known by the domain name, even if it has acquired no
trademark or service mark rights; or
(iii)
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.107 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 involving15,710 domain names had been brought under
the UDRP.108 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,109 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.
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 on-line dispute resolution service
has been effective in dissuading Internet pirates from hijacking names."110 It may also be partly the
consequence 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
107 The approved providers are listed at <http://www.icann.org/dndr/udrp/approved-providers.htm>. There were
four approved providers in February 2005.
108 ICANN. 2004. "Statistical Summary of Proceedings Under Uniform Domain Name Dispute Resolution Policy."
January 30. Latest version available at <http://www.icann.org/udrp/proceedings-stat.htm>.
109 eResolution ceased operating as a dispute-resolution provider for ICANN in late November 2001.
110 WIPO. "WIPO Continues Efforts to Curb Cybersquatting." Press Release PR/2002/303. February 26. Available
at <http://www.wipo.org/pressroom/en/releases/2002/p303.htm>.
3-45
Prepublication Copy--Subject to Further Editorial Correction
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.111
350
300
250
200
150
100
50
0
0
2
2
-99
r-00
02
n-00
-00
c-0
r-01
n-01
-01
c-01
r-02
p-0
c-0
r-03
n-03
-03
c-03
r-04
Dec
Ma
Ju
Sep
De
Ma
Ju
Sep
De
Ma
Jun- Se
De
Ma
Ju
Sep
De
Ma
FIGURE 3.3 UDRP fillings 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.
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 holders could challenge bad-faith claimants
111 See ICANN. 2003. "Staff Manager's Issues Report on UDRP Review. August 1. 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.
3-46
Prepublication Copy--Subject to Further Editorial Correction
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.
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 a trademark owner with a further cause
of action that was specifically directed to domain names.112 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.113 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 domain 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 action114 against the domain name itself in the judicial district
112 15 U.S.C. § 1125(d).
113 18 U.S.C. § 706 ("Red Cross") or 36 U.S.C. § 220506 ("Olympic").
114 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).
3-47
Prepublication Copy--Subject to Further Editorial Correction
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.115 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.
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
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 72 million 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.
115 See <http://arbiter.wipo.int/domains/cctld/index.html> for an example.
3-48
Prepublication Copy--Subject to Further Editorial Correction
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 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.
3-49
Prepublication Copy--Subject to Further Editorial Correction
4
The Domain Name System: Technology Prospects
4.1 INTRODUCTION
The Domain Name System, as described in Chapter 3, has met most of the naming needs of the
Internet and the applications that rely on it, even as their uses and usage have expanded rapidly.
However, the broadening and deepening penetration of the Internet and its applications into global
communications, commerce, and culture pose new challenges to the basic technology of the DNS. In
anticipation of and in response to those challenges, the technology community has been developing
modifications of and extensions to the current technology.
This chapter is a review of the challenges and the prospective or actual technology responses to
them. Each challenge and responsive technology is described and evaluated and the implications for the
Internet and its applications are explained. Where the committee is in agreement, its conclusions and
recommendations are presented. In all cases, the goal is to provide a clear description of the challenges,
the technologies, and their prospects in order to inform forthcoming policy deliberations affecting or
affected them.
The following challenges and responsive technologies are addressed in this chapter:
1. Improving the security of the DNS DNSSEC,
2. Linking the telephone and Internet naming systems ENUM,
3. Internationalizing domain names IDN, and
4. Responding to domain name errors aggregation and Site Finder.
Some of these technologies are in or ready for the first stages of implementation, whereas others may
never enter into wide-scale usage. Nevertheless, a basic understanding of each of them will enable wiser
decisions about them and other innovations in the future.
4.2 IMPROVING SECURITY OF THE DOMAIN NAME SYSTEM--DNSSEC
Because of its central role in the operation of the Internet, the DNS is a natural target for
mischievous and malicious attacks. These can take a wide variety of forms depending upon the ingenuity
of the attacker and on which of the potential vulnerabilities is attacked.1 The most severe recent attack
was the denial-of-service attack launched in October 2002 and described in Section 3.3.4. It swamped 8
of the 13 root name servers for up to an hour and a half. However, the remaining 5 servers handled the
regular requests to the root without difficulty. Since that attack, the root name server operators have taken
a number of steps, including the widespread distribution of anycast satellites and diversification of
network connectivity, to reduce their vulnerability to such attacks and to mitigate their effects.
1 See, D.Atkins and R.Austein. 2004. "Threat Analysis of the Domain Name System." August. IETF. RFC 3833.
Available at: <http://www.ietf.org/rfc/rfc3833.txt?number=3833>.
4-1
Prepublication Copy--Subject to Further Editorial Correction
Furthermore, although some steps have been taken,2 more could be done to continuously monitor
the performance and traffic flows of the DNS infrastructure so as to enable rapid detection and response
to attacks or outages.
However, another serious vulnerability remains. As described in Section 2.4, "the original DNS
design did not include a mechanism to ensure that a name lookup was an accurate representation of the
information provided by the entity responsible for the information. DNS information was assumed to be
accurate as the result of general notions of network cooperation and interoperation (i.e., based on the
presumption that nobody would deliberately attempt to tamper with DNS information)." In more technical
terms, the initial design of the DNS did not incorporate "data origin authentication" and "data integrity
protection." However, because of increased fear of additional attacks on the DNS, these kinds of security
features have now become a major concern.
Data origin authentication is needed to help ensure that the results of DNS lookups come from
authoritative sources. A widely publicized case that involved the diversion of Internet users to an
undesired Web site drew attention to the lack of such authentication in the DNS.3
Data integrity protection is needed because DNS data flows could be compromised at any point
between the various name servers, resolvers, or other intermediaries; and the corrupted data can remain in
caches for extended periods of time.
To respond to these potential vulnerabilities, the technical community has over a number of years
developed DNS Security Extensions (DNSSEC).4 DNSSEC adds data origin authentication and data
integrity protection to the DNS. It aims to ensure that the recipient can validate that the data was sent
from an authoritative source and that it arrived at its destination unchanged.
4.2.1 Mechanics of DNSSEC
DNSSEC provides end-to-end protection through the use of cryptographic digital signatures that
are created by responding zone administrators and verified by a recipients' resolver software. In
particular, DNSSEC avoids the need to trust intermediate name servers and resolvers that cache or route
the DNS records originating from the responding zone administrator before they reach the source of the
query. DNSSEC also preserves the capacity for localized variations and independence within the DNS
hierarchy.5
In DNSSEC, resource record sets (RRSets) 6 within a zone are signed based on the model of
public key cryptography.7 To support each signing operation, two keys are generated: A private key (to
sign data) and the corresponding public key that is used to verify that the data were signed by the private
key. The process of signing takes data to be signed and a private key as inputs to produce digitally signed
2 Notably the establishment of the Operations Analysis and Research Center by the Internet Systems Consortium
see <https://oarc.isc.org/> and the on-line performance monitoring by the k-root < http://k.root-
servers.org/#stats>.
3 In 1997, Eugene Kashpureff diverted Internet users who were seeking Network Solutions Web site to his own site,
although this was intended as a publicity stunt rather than as a malicious attack. See "Locking Up DNS Troubles,"
Network Magazine, Rik Farrow, August 5, 2000, available online at
<http://www.networkmagazine.com/showArticle.jhtml?articleID=8702868>.
4 Defined in: Eastlake, D. 1999. "Domain Name System Security Extensions." March. IETF. RFC 2535. Available
at: <http://www.ietf.org/rfc/rfc2535.txt?number=2535>. New RFCs are in preparation that will obsolete this RFC.
5 For example, the control of the private and public keys remains within each respective zone.
6 Resource records that have the same label, class, and type are categorized as belonging to the same RRSet. See
Box 3.2 for a detailed explanation of resource records.
7 For a review of public key cryptography and digital signatures, see Paul Albitz and Cricket Liu. 2001. DNS and
BIND, 4th edition, Chapter 11. Sebastopol, Calif.: O'Reilly Media; and Chapter 4 in Trust in Cyberspace, Fred B.
Schneider, editor. 1999. Computer Science and Telecommunications Board, National Research Council.
Washington: National Academy Press.
4-2
Prepublication Copy--Subject to Further Editorial Correction
data as the output.8 However, DNSSEC involves signing the hash value of an RRSet, rather than signing
the full RRSet itself.9 (See Figure 4.1 for an illustration of the DNSSEC signing and verification process.)
Two copies of the RRSet are sent over the Internet to the recipient. One copy is not signed; the
other is hashed and then signed as described above. To verify the origin and integrity of the unsigned
RRSet, it is hashed using the same algorithm used by the sender. It is then compared with the verified, but
still hashed, copy of the RRSet created by the zone administrator. Matching hash values provides a high-
level of assurance that the non-signed RRSet is authoritative and that it has not been altered in transit.
DNSSEC can, when everything works correctly, give the data consumer (validating resolver)
some confidence that the received data is what the data producer (signing zone administrator) has sent. It
provides a basis for trusting that the data has been received without tampering. It does not, however,
assure that the data that the data producer sent is error-free or appropriate for the data consumer's
application.
The DNSSEC extensions are based on four new resource record (RR) types: the public key
(DNSKEY), the resource record digital signature (RRSIG), the delegation signer (DS) and the
authenticated denial of existence (NSEC).10 The public key used to verify the digital signature of an
RRSet is stored in the DNSKEY RR.11 The digital signature is stored in the RRSIG RR, and several
RRSIG RRs may be associated with an RRSet, if more than one cryptographic algorithm is used for
signing the RRSet.
DNSSEC depends on establishing the authenticity of the DNS hierarchy leading to the domain
name in question, and thus its operation depends on beginning the use of cryptographic digital signatures
in the root zone. The DS RR facilitates key signing and authentication between DNS zones to create an
authentication chain, or trusted sequence of signed data, from the root of the DNS tree down to a specific
domain name. To secure all DNS lookups, including those for non-existent domain names and record
types, DNSSEC uses the NSEC RR to authenticate negative responses to queries. NSEC is used to
identify the range of DNS names or RR types that do not exist among the sequence of domain names in a
zone.12
8 The crucial property of the digital signature is that it could have been produced only by someone with access to the
private key.
9 A hash algorithm is a mathematical process that converts a message to a probabilistically-unique fixed-length
string of digits that represents the original message. A hash algorithm is essentially uni-directional: Given a hash
value, it is nearly impossible to reverse the process to derive the original message. Since a hash value is typically
much less data than contained in an RRSet, it is generally more efficient to sign hash values rather than RRSets.
10 For detailed information about these RRs, see Roy Arends, Rob Austein, Matt Larson, Dan Massey, and Scott
Rose, "Resource Records for the DNS Security Extensions," IETF, RFC 4035, July 15, 2004, to be published in
2005 and will be available at <http://www.ietf.org/rfc/rfc4035.txt?number=4035>.
11 The private key must be closely protected from public access, of course, and so it is not stored in a RR.
12 The implementation of DNSSEC also necessitates other changes that are too detailed to discuss here. For the
specifics on the two "new message header bits" (CD and AD) in DNSSEC, see Roy Arends, Matt Larson, Rob
Austein, Dan Massey, and Scott Rose, "Protocol Modifications for the DNS Security Extensions," IETF, RFC 4034,
July 15, 2004, to be published in 2005 and will be available at <http://www.ietf.org/rfc/rfc4034.txt?number=4034>.
4-3
Prepublication Copy--Subject to Further Editorial Correction
Authentic
Hash
Hashed
RRSet
RRSet
Private Key
Sign
Signed
SENDER
hash of
RRSet
1.
Internet
Public Key
2.
Internet
Verify
RECIPIENT
signature of
RR Set hash
Received
Hashed,
Verified
RRSet
Hash
received
=?
received
RRSet
hash of
RRSet
If Hashed RRSets are =, the Received RR Set is authentic; if not, it is not.
FIGURE 4.1 Use of DNSSEC to authenticate an RRSet.
4-4
Prepublication Copy--Subject to Further Editorial Correction
4.2.2 Deployment of DNSSEC
DNSSEC implementation on a global level faces a number of technical and non-technical
challenges. The process of cryptographically signing hash values derived from resource records, along
with the increase in the DNS packet size to accommodate large key sizes, adds significant operational
costs for organizations that manage DNS servers because of the increase in DNS data and the associated
increases in server computations and communications traffic.13 The implementation of DNSSEC also
increases the volume of Internet traffic and that, in turn, could increase the vulnerability of the Internet to
denial-of-service (DoS) attacks--a threat DNSSEC does not protect against, although DNSSEC may offer
more confidence in the responses of anycast satellites, which do provide a measure of defense against
DoS attacks. DNSSEC could also cause more timeouts that would degrade the quality of service for end-
users.14 DNSSEC also introduces more complexity to the DNS, and would add to the administrative
requirements for managing the security mechanism.15 For instance, the administrator of a large zone
would probably experience great difficulty in re-signing his or her entire zone daily. This would require
dividing the task among many smaller parallel operations that could be managed with software; a solution
that is feasible given the DNSSEC design (that makes signatures within a zone remain largely
independent), but would not be without additional costs.
Because public keys for the root zone will need to be replaced with new ones on a regular basis,
key management for the digital signatures presents another problem for DNSSEC. In particular, the
interaction of key revocation with global caching and the distribution of copies of a new public root key
remain unresolved,16 and this adds even more importance to the management of root zone keys. The
consequence of a corrupted root zone key is that it would break the chain of trust for source authentication
and data integrity that serves as the basis of DNSSEC. A related and more fundamental and thorny
problem that technical solutions could only partially resolve is reaching agreement over which
organization should have control of the root zone key. Obvious candidates for the controlling
organization include VeriSign, ICANN, and the Department of Commerce; other entities could also be
considered. However, until a controlling organization is identified, the deployment of DNSSEC is likely
to be delayed.17
While the introduction of DNSSEC imposes significant costs and does not eliminate all Internet
security concerns nor address all Internet threats,18 its implementation would represent considerable
progress in improving the security of the DNS. For example, it would raise the level of protection against
the falsification of DNS data to help in deterring identity-related theft and SPAM problems.19
13 Estimates for the increased computations and communications traffic associated with the introduction of DNSSEC
vary, but range from a five-fold to ten-fold increase. See Albitz and Liu (2001); Beth Cohen, "DNSSEC: Security
for Essential Network Services," May 12, 2003, available online at
<http://networking.earthweb.com/netsecur/article.php/2204801>; and "Securing the Domain Name System," Diane
Davidowicz and Paul Vixie, Network Magazine, January 1, 2000.
14 See David Berlind, "DNS Inventor Says Cure to Net Identity Problems is Right Under Our Nose," August 7,
2003, available online at: <http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2914447,00.html>.
15 See Cohen (2003).
16 Distributing new public root keys is difficult as they must be preconfigured in DNS root name servers, but they
cannot be delivered via DNSSEC extensions, and thus they may require an offline distribution mechanism. One
proposed solution involves the publication of a public root key in national and international newspapers, which
illustrates the magnitude of the problem.
17 Several facilities in the Netherlands and Sweden are examining how DNSSEC could operate when it is generally
deployed by examining procedures, such as key rollover, determining parameters for DNSSEC mechanisms, such as
key length and signature lifetimes, and other issues beyond the scope of this discussion. For more information about
current efforts of DNSSEC testing, see: <http://www.dnssec.net>.
18 See Derek Atkins and Rob Austein, "Threat Analysis of the Domain Name System," April 5, 2004 (work in
progress), available online at <http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-threats-07.txt>.
19 See Berlind (2003).
4-5
Prepublication Copy--Subject to Further Editorial Correction
Furthermore, DNSEC provides a basis to build trust on the Internet to support higher-level protocols
facilitating IP telephony and other Web services.20
Conclusion:
The security of the DNS would be significantly improved if DNSSEC were
widely deployed among name servers for the root zone and TLDs in particular, and throughout the DNS
in general.
Conclusion: Urgent attention is needed to identify the organization that would maintain
control of the root zone key. The deployment of DNSSEC is likely to be delayed until this organization is
identified.
Recommendation: DNSSEC should be deployed throughout the DNS as practical, with
highest priority given to deployment in the root zone and the TLDs.
4.3 LINKING THE TELEPHONE AND INTERNET NAMING SYSTEMS ENUM
The Internet and the traditional telephone network operate differently. When a traditional
telephone call is made, switches create a circuit between the caller and the person who is called. That
circuit remains in place for the duration of the call. The process is called "circuit-switching." However,
when a message is sent from one computer connected to the Internet to another computer no such circuit
is established. Rather, the message is broken into packets and each is routed through the network
independently, possibly even following different paths, and reassembled at their destination in the proper
order. That process is called packet-switching. For the most part, the circuit-switched world of telephony
and the packet-switched world of the Internet have remained distinct. However, in recent years, a
convergence between the two has begun to occur, with increasing use of the Internet to transmit telephone
calls through a process called "Voice over Internet Protocol" or VoIP.21
The recognition of the potential convergence of telephony and the Internet was one of the
motivations for consideration by the technical community of ways to bring telephone numbers into the
Domain Name System. Doing so, it was thought, would facilitate communications between the Internet
and the world's telephone networks. The method they developed is called the Telephone Number
Mapping protocol, more commonly known as the ENUM protocol.22 Under the ENUM scheme,
telephone numbers, called E.164 numbers,23 are mapped (via the ENUM protocol) to domain names.
These are then mapped (in the DNS) to various resources by DNS lookups that lead to Uniform Resource
Identifiers (URIs).24 The main premise underlying development of the ENUM protocol is that standard
telephone numbers--familiar, globally unique identifiers easily usable on numeric keyboards--are likely
20 See John Leyden, "DNS Inventor Calls for Security Overhaul," The Register, April 11, 2003, available online at:
<http://www.theregister.co.uk/content/7/30224.html>.
21 See, for example, the explanation of VoIP on the Federal Communications Commission Web site,
<http://www.fcc.gov/voip/>
22 See Patrik Fältström and Michael Mealling. 2004. "The E.164 to Uniform Resource Identifiers (URI) Dynamic
Delegation Discovery System (DDDS) Application (ENUM)." April. RFC 3761. Available online at: <ftp://ftp.rfc-
editor.org/in-notes/rfc3761.txt>. The mechanism used by ENUM for mapping telephone numbers into the DNS was
first specified in late 1992 as part of an Internet "Remote Printing" model that could substitute for fax and other
telephone-enabled transmission mechanisms. That application and the mapping mechanism are described in: Carl
Malamud and Marshall Rose. 1993. "Principles of Operation for the TPC.INT Subdomain: Remote Printing
Technical Procedures." October. RFC 1528. Available online at: <ftp://ftp.rfc-editor.org/in-notes/rfc1528.txt>.
23 E.164 refers to the global telephone numbering plan administered by the International Telecommunication Union.
RFC 3761 stipulates that the domain names generated through the ENUM protocol must adhere to the existing
E.164 country (or region) delegations.
24 See Chapter 6 for a definition of URIs.
4-6
Prepublication Copy--Subject to Further Editorial Correction
to persist. Consequently, making it easy to link the Internet and telephone naming systems may support
the development of new and improved services that use a telephony-like model.
Applications that can build on the ENUM protocol include voice communications, fax, e-mail,
and messaging. For example, a telephone call might originate from a standard desktop telephone set and
terminate at a telephone connected to the Internet (after passing through a gateway). The implementation
of the ENUM protocol may facilitate the completion of such VoIP telephone calls, although such calls do
not require the use of ENUM as an addressing mechanism. The ENUM protocol enables the use of a
single E.164 number to access applications based on the telephone network, the Internet network, or both
networks. Thus, it may enable increased functionality and/or lower costs for communications in such
interconnected networks.25
4.3.1 Mechanics and Operations of ENUM
The ENUM protocol specifies how telephone numbers are converted into domain names. The
conversion is best explained through an example. Begin with a telephone number such as +46-8-1234567.
Then remove all characters except the digits, put dots between the digits, and reverse the order, which
yields, in the example above, 7.6.5.4.3.2.1.8.6.4. Then a second level domain name is appended, which
for the implementation of the ENUM protocol is "e164.arpa."26 The resulting ENUM domain name is
then 7.6.5.4.3.2.1.8.6.4.e164.arpa.
The deployment of ENUM is typically envisioned in tiers. The highest level within the ENUM
hierarchy--tier 0--corresponds with the selected second-level domain e164.arpa.27 The name server
resource records in this second level domain would point to "national" tier 1 registries, such as
2.6.e164.arpa (for Indonesia - telephone country code 62) or 2.3.e164.arpa (for Belgium -
telephone country code 32).28 The delegation beyond tier 1 registries (and the definition of a "tier" itself)
may differ among countries. Various trials are underway in a number of countries to identify the most
effective models for those countries.29
A tier 1 registry could delegate directly to name servers that contain ENUM information.
However, in some models for the implementation of the ENUM protocol, a tier 1 registry would delegate
to multiple tier 2 operators (e.g., divided in a way that is based on how telephone numbers are partitioned
within a country). Tier 2 operators would then operate name servers that contain ENUM information that
25 The resources used to develop this subsection include presentations and discussions at the public forum of the
meetings of the Internet Corporation for Assigned Names and Numbers, Rio De Janeiro, Brazil, March 25, 2003,
available online at <http://www.icann.org/riodejaneiro/captioning-board-meeting-27mar03.htm>; materials from the
International Telecommunication Workshop on ENUM, Geneva, Switzerland, February 8, 2002, available online at
<http://www.itu.int>; the ENUM Web site of the International Telecommunication Union at
<http://www.itu.int/osg/spu/enum/>; "Frequently Asked Questions," available online at <http://www.enum.org>;
"The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational
Documents Contributed to ITU-T Study Group 2 (SG2)," RFC 3245, John C. Klensin, editor, March 2002; and
"Online Registries: The DNS and Beyond...," Release 1.0, September 16, 2003, New York: EDventure Holdings,
Inc.
26 e164.arpa is the second-level domain name recommended by the Internet Architecture Board for ENUM use
in RFC 3761. The .arpa TLD is intended to support Internet infrastructure initiatives such as the implementation
of the ENUM protocol.
27 The Réseaux IP Européens (RIPE) Network Coordination Centre (NCC) is the administrator of the e164.arpa
as determined by the Internet Architecture Board.
28 Twenty-six codes have been delegated (twenty-eight have been approved) as of March 4, 2005, as reported by
RIPE NCC at <http://www.ripe.net/enum/request-archives>.
29 For example, see <http://www.itu.int/ITU-T/inr/enum/trials.html>.
4-7
Prepublication Copy--Subject to Further Editorial Correction
takes the form of Naming Authority Pointer (NAPTR) resource records.30 These records include NAPTR
records for service-specific addresses (e.g., an e-mail address, cell phone number, fax number, etc.31),
which would all be returned in the response to any DNS query about a particular ENUM domain name.
An important feature of NAPTR records is that they can convey priority ordering (e.g., try this address
first--if there is no response, then try this one). The situation described above is referred to by some as
the "calling party control model" because the DNS query for the NAPTR records retrieves all possible
contact modes--that is, access to this information is determined by the requestor.
Tier 3 services could also be offered. Services at this level could support operations after the
completion of a lookup of ENUM information (i.e., some of these operations might not depend on the
DNS in any way). For example, a lookup from a tier 2 name server could point to a proxy server that
contains tailored user information, rather than to service-specific addresses directly. This tailored user
information could, in turn, provide office addresses to all queries and, in addition, home addresses only to
those requests with particular characteristics. Alternatively, all queries to the NAPTR records could be
directed to this tailored user information, thereby providing the called party with control over what
contact information is made available (i.e., the "called party control model").32
4.3.2 Technical and Public Policy Issues
The deployment of the ENUM protocol raises anew most of the challenges associated with the
DNS and raises a few new ones. Thus, the technical and policy context for ENUM implementation
includes a wide variety of issues that should be resolved prior to the widespread deployment of the
ENUM protocol and serves as an illustrative case study for other applications that might be developed on
top of the DNS. (It also illustrates another one of the core Internet navigation issues: While ENUM
provides mechanisms for mapping from telephone numbers to the DNS and from a domain name to
relevant resources, it does not address the problem of determining a telephone number given some
(possibly inexact) form of the name of a person or organization (and perhaps some additional qualifying
attributes). On a global basis, that navigation problem is far more difficult than the challenges associated
with ENUM.)
Registrars and consumers. An important implementation issue is who has control over the
information in the name servers. Conflicts over the inclusion or content of NAPTR records need to be
resolved in some way. The design of the mechanisms for managing these conflicts can draw from past
experience with the DNS and telephone networks, which has included dealing with slamming (the
unauthorized change in service providers), number portability, and recourse in the event of fraud.
Privacy. Since the records in the DNS are publicly accessible, there is some concern about
the privacy of the personal information stored there. Of specific concern are URIs in the NAPTR records
that refer to personal information that an individual would not wish to have linked to a telephone number
in a freely accessible way.33 Alternatives such as the called party control model described above accord
individuals the ability to specify what kind of information will be publicly available and an opt-in strategy
30 NAPTR records are described in Michael Mealling. 2002. "Dynamic Delegation Discovery System (DDDS) Part
Three: The Domain Name System (DNS) Database." October. RFC 3403.
31 These addresses may be specified using a variety of protocols that include the Session Initiation Protocol (SIP),
which supports the negotiation of the parameters between endpoints for a real-time session. See Mark Handley,
Henning Schulzrinne, Eve Schooler, and Jonathan Rosenberg. 1999. "SIP: Session Initiation Protocol." March.
RFC 2543.
32 This discussion was derived, in part, from "Enum: Mapping Telephone Numbers on to the Internet: Potential
Benefits with Public Policy Risks," April 2003, Center for Democracy and Technology, Washington, D.C., available
online at <http://www.cdt.org/standards/enum/>.
33 However, note that the storage of E.164 numbers themselves in name servers is not a privacy issue. The issue
arises when E.164 numbers are linked to personal information.
4-8
Prepublication Copy--Subject to Further Editorial Correction
provides individuals with the ability to decide whether his or her telephone number will be included in the
DNS as an ENUM domain name.
Authentication and security. Under a system in which an individual must make a deliberate
opt-in decision, authentication of his or her identity is critical in substantiating that the person who wants
a number is really that person and that he or she has the rights to use that number (and to make
subsequent modifications to ENUM information). In addition, ensuring that the results from lookups to
ENUM information are authentic suggests that the implementation of DNSSEC is as critical for ENUM
deployment as it is for other DNS applications, as discussed in Section 4.2.
Institutions. Because ENUM is also dependent on telephone numbers and the various
policies that pertain to telephone numbers, the institutional framework includes the International
Telecommunication Union (ITU). Also, as ENUM is based on telephone number country codes, national
policies must be considered. A clash of institutional approaches may result, given the strong regulatory
tradition associated with telephone numbering that contrasts with the traditionally less regulated
management of Internet naming and addressing.
An important design characteristic of the DNS is the existence of a root zone that provides the
operational basis for global uniqueness and coherence. By contrast, telephone service providers
determine the country codes that they use for routing telephone calls. Each provider might not use the
same set of codes. For example, the country code +866 is used from many, but not all, locations in the
world to complete telephone calls to Taiwan. The +866 country code is not officially allocated to Taiwan,
but it is being reserved by the ITU, which manages the country codes in the world. Because the ENUM
model as currently implemented requires ITU and national approval for each ENUM delegation, the use
of standard ENUM for communication in and with Taiwan has been prevented by the People's Republic
of China.
Other. The deployment of the ENUM protocol raises other issues that are too detailed to be
discussed here, such as the disposition of an ENUM domain name when an individual terminates the
service for the corresponding telephone number. The references provided in this section provide pointers
to documents that explore these issues.
4.3.3 Alternate Models
In principle, ENUM-like domain names could be based on a unique identifier other than a
telephone number. For example, consider the use of any random identifier that is globally unique, such as
a product bar code. Or one might tie ENUM more closely to the existing ccTLD model, using ISO 3166
numeric codes rather than E.164 country codes to identify the country-specific part of the number.
Another alternative could call for the use (at least in part) of a different domain than e164.arpa. Also,
the hierarchy of names need not be based on countries at all. However, it is unclear whether the adoption
of an alternate model instead of the ENUM protocol would provide the basis for a superior deployment.
The deployment of the ENUM protocol could support important new applications. However, it is
also the case that its deployment would reinforce the utility of telephone numbers. Assuming that it is
increasingly desirable to identify an individual or activity rather than a telephone number, the deployment
of the ENUM protocol might not be optimal in the long run because its use could forestall efforts to
develop systems with greater capabilities.
Conclusion: Overall, the plan to deploy the ENUM protocol could lead to applications that use
the DNS without necessitating any changes to DNS protocols or software. However, a number of
important technical and public policy issues would need to be resolved in each country that has an interest
in deploying ENUM. These issues include establishing the rights and requirements of registrars and
consumers, developing practices for the protection of personal privacy, implementation of procedures for
authentication and security, and development of an effective and efficient institutional framework for
operation of ENUM.
4-9
Prepublication Copy--Subject to Further Editorial Correction
4.4 INTERNATIONALIZED DOMAIN NAMES IDNs
One of the issues of particular interest in many countries is access to the Internet and the DNS
using home-country languages and scripts. As the number of users in countries with first languages that
are not based on the Roman characters used in the DNS increased dramatically through the 1990s, interest
developed in domain names based on non-Roman scripts (e.g., Chinese, Hebrew, Arabic, and so on).
Several major efforts were undertaken in the effort to accommodate internationalized domain names
(IDNs) within the Internet infrastructure.
Unfortunately, the design of the DNS presents formidable technical challenges for the
accommodation of languages that use non-Latin characters. As a lookup system, the DNS must be able to
determine unambiguously whether there is a match with a query or not. Comparing strings is much more
difficult than most people realize, because the definition of what is "equal" is often not deterministic. For
example, consider the case of the French language in Canada and France, for which there are different
rules of whether an accent stays over the character when it is converted from lower to upper case.34 And
some languages (e.g., Chinese) cannot even be reduced to a relatively small number of standardized
characters (e.g., the character set for English). As these challenges were articulated and analyzed by the
interested communities, it became clear that the widespread deployment of IDNs would necessitate a
number of compromises. Some of these compromises stemmed from intense arguments over the
preservation of cultural identities, the use of names that are semantically correct, and other linguistic
issues.
Other compromises have their roots in technical issues. Some of those who were very concerned
about the integrity of the DNS argued that internationalized domain names should be implemented in
applications (e.g., by reworking URL and similar formats to accommodate IDNs directly). Some other
technical experts argued that the deployment of IDNs should be executed through a major overhaul of the
Internet's infrastructure, rather than as an add-on. However, considerable pressure developed within the
interested communities to implement IDNs in the near-term and, therefore, solutions that would require
extensive changes in architectures or standards did not attract very much support. This pressure provided
the impetus for an effort led by the Internet Engineering Task Force (IETF) that culminated in a standard
solution, the Internationalizing Domain Names in Applications (IDNA) mechanism.35
4.4.1 Internationalizing Domain Names in Applications
The central goal of the IDNA scheme is to enable end-user viewing of IDNs (e.g., .cn)
without altering the DNS protocols themselves. Hence, even though an end-user may see an IDN, the
DNS itself only sees the usual LDH-style domain names.36 IDNA is entirely a client-side set of
procedures.
There are a number of encoding systems for representing various language scripts. In the
discussions leading to the adoption of IDNA as a standard, it became clear that a constraint would be
needed on the number of encoding systems so that the introduction of IDNs would be tractable. Unicode
34 Another example is the "a" with diaeresis "¨" ("ä") which in German should be sorted and looked at exactly as an
"a" with diacritical character, but in Swedish has nothing to do with the character "a" except the look. The same
way Å as the physical unit Ångström is one character, but the initial character of the word Ångström is another
(which in turn is different from an "A"). The other problem with the German "a" with diaresis ("umlaut") is that it
may be considered to match the string "ae", while not all names containing "ae" match "ä".
35 IDNA is described in: Fältström, Patrik; Paul Hoffman, and Adam M. Costello. 2003. "Internationalizing Domain
Names in Applications (IDNA)."March. RFC 3490,which is available online at: <http://www.rfc-editor.org/>.
36 These are domain names comprising letters, digits, and the hyphen--a subset of ASCII--as described in Chapter
2.
4-10
Prepublication Copy--Subject to Further Editorial Correction
was agreed to be the client-side encoding system for language scripts.37 Thus, any user application based
on other encoding systems would first have to translate its internationalized domain names to a Unicode
representation prior to processing by IDNA-compliant procedures.38
The algorithms that make up IDNA work on the individual parts of a domain name separated by
dots, which are called labels.39 Translation can occur in two directions: from Unicode to LDH format
(ASCII) or the reverse.
The input to the "ToASCII" algorithm is a single label comprising Unicode code points.
However, before labels are processed, they must be normalized because different Unicode strings can
represent the same domain name.40 Thus, a profile ("nameprep") is applied--a string preparation and
normalization procedure for Unicode that is partially derived from Unicode Technical Consortium
(UTC)-specified normalization procedures.41 An encoding system ("punycode") is then used for mapping
"nameprepped" labels into conventional LDH-style labels.42 These labels are then concatenated (with
dots in-between the labels) to generate the resulting domain name. In the process of assembling the
resulting domain name, "xn--" is added as a prefix to denote that the domain name is an IDN;43 an
example of such a domain name is xn--fiq43lrrlfy5a.tw. At this point, the DNS is used as
described in Chapter 3.
The process for going from ASCII to Unicode involves the use of the decoding algorithm in
punycode. The details of this process are described in RFC 3490.
Client-Side Support
There is a gap between "deploying IDNA" (i.e., adding IDNA-format (punycode) domain names
in DNS zones) and the actual ability of users to see, or provide as input, domain names expressed in
characters that are "native" to their preferred languages. The actual appearance of a domain name in
native characters on a screen or printout, or the ability to transcribe such characters from a sign on the
side of a bus into a URL to locate a Web page, requires that the relevant applications be upgraded to
recognize the IDNA format and to translate to and from local scripts.
Supporting Web Access
37 "Unicode is a coded character set containing tens of thousands of characters. A single Unicode code point is
denoted by "U+" followed by four to six hexadecimal digits, while a range of Unicode code points is denoted by
two hexadecimal numbers separated by ".." with no prefixes," as described in RFC 3490. Additional information
about Unicode may be found at <http://www.unicode.org>.
38 The mappings to and from Unicode may not be obvious (and may become controversial), as the local encodings
sometimes make distinctions that Unicode does not, or vice versa.
39 For instance, in www.example.com, there are three labels: www, example, and com.
40 For example, upper case characters would be converted to lower case characters. However, this case mapping
may be problematic, as in the case for handling diacritical marks where characters are mapped to upper case in
modern French as compared to older forms (still used in Québéc and elsewhere). Also, consider the Unicode string
"www.Exa$(not$)mple.com that would be normalized to www.example.com. Adopted from Eric A. Hall, "The
IDNA-to-ASCII Conversion Process," Network Magazine, June 1, 2004, p. 60.
41 See "Nameprep: A Stringprep Profile for Internationalized Domain Names," Paul Hoffman and Marc Blanchet,
RFC 3491, March 2003; and RFC 3454. For Unicode normalization, see "Unicode Normalization Forms," Unicode
Technical Report #15, Mark Davis and Martin Dürst, <http://www.unicode.org/reports/tr15/tr15-23.html>.
42 See "Punycode: A Bootstring Encoding of Unicode for Internationalized Domain names in Applications
(IDNA)," Adam M. Costello, RFC 3492, March 2003.
43 The description given here is a simplified one. The many details concerning the various algorithms may be found
in the RFCs referenced above.
4-11
Prepublication Copy--Subject to Further Editorial Correction
Some Web browsers have been upgraded to support IDNA names directly, whereas others,
including the most common browser, Internet Explorer, support IDNA through browser plugins.44 These
extensions to browser operations and syntax are not standardized and not consistent, leading to different
users getting different results depending on which tools they choose to use (or, more commonly, have
chosen for them).45 In the worst case, the consequence is a breakdown of the principle of referential
integrity--a putative domain name or URI, when passed from one user to another, acquires a different
meaning (or target) depending on the environments of the two users. Even when support for Web
browsers is achieved on a consistent and widespread basis, it will take a considerable period of time to
replace the million of copies of Web browsers. Forrester Research predicts that it will take at least two to
three years before IDNs can be really used for Web browsing and up to five years until 90 percent of
applications are IDN compatible.46
Supporting E-mail and Other Access
For applications other than the Web, the situation is yet more problematic. There is, in general,
no "patch" option equivalent to the browser plug-ins. While there are only a few heavily-used browsers,
there are very large numbers of client / user interface programs for e-mail, FTP, and other protocols.
Some of these programs are embedded in firmware on portable devices, which generally cannot be
upgraded in a practical way.
Electronic mail poses additional problems. For most users, the Web is largely passive: people
find and view Web pages, but relatively few users create their own Web content or need to establish
addressing or location information for it. E-mail, by contrast, is not passive. Most e-mail users are
actively engaged in the creation and receipt of e-mail. Addresses read over the phone or copied from
business cards or notes may well be more common for e-mail than for the Web. Moreover, Internet e-
mail operates in a "store and forward" mode: unlike, for example, the Web, there is normally no reliable
mechanism for a sender to determine, or negotiate, the capabilities of the receiver such as whether a
receiver can handle internationalized addresses. And, finally, users typically expect the left side or "local
part" (before the "@") of an e-mail address to reflect their names and related conventions (or other
personal identifiers such as nicknames) and to do so accurately.47 People are often extremely sensitive
about the spelling of their names (or other personal identifiers), and efforts to replace e-mail addresses
based on names with ones that involve semi-random strings have rarely been met with enthusiasm. Even
if the domain name part of the address internationalization problem were solved with appropriate user
agent software, it may well lead to more demand for properly-spelled and formatted local parts in local
scripts. Non-English-speaking users who have been using addresses containing Rom