The Internet Corporation for Assigned Names and Numbers (ICANN) is
responsible for coordinating the Internet's naming, address allocation,
and protocol parameter assignment systems. These systems enable globally
unique and universally interoperable identifiers for the benefit of
the Internet and its users.
These systems are highly distributed: hundreds of registries, registrars,
and others, located around the world, play essential roles in providing
naming and address allocation services for the Internet. ICANN's paramount
concern is the stability of these remarkably robust services.
As overall coordinator of the Internet's systems of unique identifiers,
ICANN's role, while defined and limited, includes both operational and
In the operational sphere, the ICANN staff perform a range of day-to-day
(1) maintaining the DNS root zone file,
(2) allocating top-level blocks of IPv4 and IPv6 addresses and AS
numbers to the regional Internet registries,
(3) maintaining 120+ registries of protocol port and parameter numbers,
(4) publishing online databases of information about the top-level
domain registries included in the DNS root zone file,
(5) operating one of the thirteen authoritative DNS root name servers,
and coordinating the overall DNS root name server system,
(6) publishing the InterNIC website and related functions,
(7) operating the .int registry,
(8) maintaining common/technical IP address spaces, such as the private-use
(9) managing the reverse delegation namespace at the top level, and
(10) administering the DNS implementations of certain technical registries,
such as .arpa and the legacy infrastructure-related .int zones.
In addition, ICANN staff perform a set of day-to-day administrative
and policy functions relating to the generic top-level domain (gTLD)
(1) accreditation of competitive registrars;
(2) supervising the administration of the Uniform Dispute Resolution
(3) handling of complaints about registrations;
(4) monitoring and enforcement of registry and registrar agreements,
(5) implementation of data escrow programs.
For the country-code top-level domain (ccTLD) registries, ICANN staff
handle, investigate, and process requests for delegation and redelegation,
and for changes in the TLD nameservers specified in the root zone file.
Finally, ICANN has the responsibility for policy coordination with
respect to the security of the various parts of infrastructure that
make up the operational DNS. This activity is reflected in the recent
creation of the Standing Committee on Security and Stability. In addition,
ICANN has certain operational security responsibilities with respect
to ICANN's operational activities. Finally, ICANN attempts to nurture
and encourage continuing and serious attention to security and stability
issues by all participants in the DNS, and to ensure that necessary
tasks are undertaken by some responsible party.
In the policymaking sphere, ICANN is responsible for developing and
implementing policies related to each of its operational functions.
The nature and scope of ICANN's policymaking role differs for each function.
For example, in the area of IP address and AS number allocation, ICANN's
responsibility extends only to global addressing policies; local policies
are made by each regional Internet registry or lower-level Internet
registries. ICANN's policy role for the country-code top-level domain
registries (ccTLDs) is similarly limited to global policy coordination
with deference to each local Internet community's responsibility to
set its own registry-level policies (i.e., registration criteria, pricing,
dispute resolution, mechanisms for local community participation and
policymaking, etc.). In the area of protocol numbering, ICANN administers
the IANA registries pursuant to the instructions of the Internet Engineering
Task Force (IETF).
By contrast, ICANN plays a more direct and significant role in setting
registry-level policies for the global top-level domain registries (gTLDs),
such as .com, .net, .org, .info, .name, and .biz. In effect, ICANN serves
as the global Internet community's open policymaking forum for the gTLD
In its initial charge from the U.S. Government, embodied in the 1998
White Paper, ICANN policymaking was to be guided by a set of non-technical
principles: preserving stability; promoting competition; relying where
possible on private-sector, bottom-up, participatory mechanisms that
reflect the functional and geographic diversity of the Internet; development
of efficient dispute resolution alternatives (for the gTLD registries);
and promoting accountability in management (for all registries).
These principles are necessarily somewhat general, which has led to
some confusion and disagreement about the exact boundaries of ICANN's
policymaking mission. This has led some to suggest that those boundaries
should be restated and described in as much detail as is feasible, taking
into account the necessary flexibility required to effectively deal
with the rapidly changing nature of the Internet. Such an effort, to
the extent it produced useful guidance both for ICANN and the Internet
community as a whole, would undoubtedly be a helpful contribution to
the current ICANN reform discussions.
A note on terminology: Historically, most of the operational functions
described above were performed under the label of the Internet Assigned
Numbers Authority (IANA). Though administered by a single team at the
Information Sciences Institute of the University of Southern California,
the IANA functions were performed at the direction of two sources: the
IETF and the U.S. Government. Pursuant to an agreement with the U.S.
Government and a Memorandum of Understanding with the IETF, ICANN is
currently responsible for the full set of IANA functions. Thus, one
should keep in mind that IANA refers to a set of functions, and that
ICANN is the organization designated separately by the U.S. Government
and the IETF to perform the IANA functions for the benefit of the global
The following sections describe ICANN's responsibilities and activities
in greater detail.
On an operational level, ICANN's Internet naming responsibilities center
on two functions: the DNS root zone file and the DNS root name server
A. DNS Root Zone File
The DNS root zone file consists of a list of all top-level domains
in the authoritative public DNS (currently 259 TLDs), along with the
names and IP addresses of the primary and secondary name servers that
are authoritative for each TLD. As part of the IANA functions, ICANN
is responsible for defining the contents of the DNS root zone file,
which means maintaining and updating the list of recognized TLDs and
the name servers for each TLD. ICANN is also responsible for promulgating
the file for publication by the 13 authoritative root name servers.
The policy tasks related to the root zone file correspond to the three
basic operational functions required to maintain it: TLD delegation,
TLD re-delegation, and TLD name server changes. The particular scope
of ICANN's responsibilities for these functions differs for generic
TLDs and country-code TLDs, and varies according to the terms of the
formal registry agreements.
Under ICANN's existing relationship with the U.S. Government, all TLD
delegation, re-delegation, and name server change requests require the
final approval of the U.S. Government. Thus, at the moment ICANN's role
in this regard is limited to making recommendations for changes to the
US Department of Commerce, which has the operational oversight responsibility
for the DNS root zone file.
1. gTLD Delegation
The term "delegation" refers to the addition of a new TLD
to the DNS. In narrow technical terms, this means that a new TLD entry
is added to the DNS root zone file, along with the names and IP addresses
of the authoritative name servers for the new TLD. The addition of new
gTLDs is one of the policy objectives specifically assigned by the U.S.
Government's White Paper. In November 2000, ICANN selected an initial
group of seven diverse new generic TLDs (.info,. .biz, .name, .pro,
.aero, .museum, and .coop) to be added to the DNS as a proof of concept.
The policy tasks necessary to delegate new gTLDs include the preparation
of a request for proposals, the definition of selection criteria, the
evaluation of the proposals in light of those criteria, the analysis
of any public or expert comments, the selection of registries and registry
operators, and the negotiation of registry agreements (including, as
appropriate, the documentation of registry policies like pricing, registrar
competition, dispute resolution, data escrow, and Whois service).
Following the launch of a new TLD, ICANN is responsible for the monitoring
and enforcement of the registry agreement, the implementation of data
escrow requirements, and, in most cases, the administration of a registrar
2. gTLD Re-Delegation
The term "redelegation" refers to a change from one gTLD
sponsoring organization or manager to another. Once created, a new gTLD
is subject to potential redelegation if: (a) the sponsoring organization
or manager voluntarily chooses to abandon the registry; (b) it breaches
its registry agreement with ICANN; or (c) the term of the current registry
For example, the registry agreement for the .org TLD calls for the
current operator's delegation to terminate by 31 December 2002. ICANN
thus must undertake a redelegation process that covers the same basic
elements of the delegation process noted above.
3. gTLD Name Server Changes
On occasion, TLD registries modify one or more of their existing TLD
name servers. For example, a gTLD name server might change from one
ISP to another, or might decide to improve overall name resolution performance
by adding a new name server, or replacing an existing one. These changes
involve a change request to the IANA, followed by verification and implementation
procedures, according to the terms of the given registry agreement and
relevant technical considerations.
4. Monitoring, Enforcement, and Implementation
of gTLD Agreements
ICANN is responsible for monitoring and enforcement of the gTLD registry
agreements, along with certain operational tasks, including the accreditation
of competitive registrars, the implementation of data escrow programs,
and the administration of the Uniform Dispute Resolution Policy. Where
there are formal agreements for registration accreditation and data
escrow, ICANN must also undertake monitoring and enforcement of them,
along with any related operational tasks, such as the verification that
any registry data escrowed with ICANN is complete and generated in the
correct technical format.
As part of monitoring and enforcement, ICANN staff handles complaints
about registries and registrars, thus seeking to ensure that the policies
embodied in the agreements are being properly implemented (for example,
the requirement that registrars provide a free, online, query-based
Whois service, which provides contact information for gTLD domain name
ICANN performs a number of tasks in connection with the administration
of dispute resolution policies applicable to the gTLDs with which ICANN
has written agreements, such as the Uniform Dispute Resolution Policy
(UDRP), sunrise policies, and charter enforcement mechanisms. For example,
the UDRP provides a mandatory, non-binding, non-judicial, and relatively
inexpensive system for the resolution of claims of abusive, bad-faith
cybersquatting. ICANN's responsibilities include the approval of dispute
resolution providers and the maintenance of a master database of proceedings.
5. Internationalized Domain Names
As the Internet becomes more accessible to more of the world, and usage
by non-English speaking populations increases, the need for some workable
system of internationalized domain names also increases. This is both
a technical and a policy issue. The technical problem is extremely complex,
and is the subject of intense activity at the IETF aimed at the creation
of a workable technical standard. The policy issues are similarly complex,
as exemplified by the reports of the ICANN IDN Committee available on
the ICANN website.
6. ccTLD Delegation
Turning to the country-code TLDs, ICANN is responsible for the DNS
zone file administrative functions of ccTLD delegation, ccTLD re-delegation,
ccTLD TLD name server changes, and the implementation of ccTLD registry
agreements (where completed). ICANN policies for ccTLDs are set forth
in ICP-1, which is an updated description of current practices for the
implementation of RFC 1591, the 1994 document that sets forth the basic
IANA principles and policies for TLD structure and delegation.
The term "country-code TLD" is in fact a bit of a misnomer,
as a number of the two-letter TLDs in that category are not countries.
Specifically, the term refers to TLDs created on the basis of the ISO
3166-1 table, which is the International Standards Organization's list
of countries and geographically distinct territories together with the
unique 2- and 3-character abbreviations assigned to each. A more accurate
term would be "geographic TLDs," since this class of TLDs
is defined by their association with defined geographic units. The ISO
3166-1 table is widely used for a variety of purposes, from currency
abbreviations in the world's banking systems and financial markets to
the national origin stickers on the backs of automobiles. ICANN relies
on the ISO 3166-1 table both for the determination of whether a given
country of geographic territory exists and, if so, what two-letter code
should be used as its TLD label. By relying on this standard, ICANN
keeps itself out of the business of determining what is and is not a
country (or geographically distinct territory), and leaves that issue
to a politically recognized and expert authority.
To date, 245 ccTLDs have been delegated, leaving only two undelegated
codes. Thus, at this point, ICANN's responsibility for ccTLD delegation
involves little day-to-day work. The existing undelegated codes - along
with any new codes that may be added by the ISO 3166 Maintenance Agency
- are available for delegation under the terms set forth in ICP-1 and
RFC 1591. Those documents require that a proposed new ccTLD manager
demonstrate technical competence, the support of the local Internet
community in the country or territory to be served, and a commitment
to accept the basic community service and trusteeship responsibilities
that lie at the heart of the ccTLD concept.
7. ccTLD Re-Delegation
Far more common than ccTLD delegation matters are requests to ICANN
for the re-delegation of already-delegated ccTLD registries. Requests
for redelegation are judged according to the same basic criteria as
delegation requests, with the focus on technical competence, support
from the local Internet community, and commitment to accept the fundamental
public service responsibilities that are inherent in ccTLD trusteeship.
The handling of ccTLD redelegation requests requires significant ICANN
staff work, for reasons that may not be obvious. In some cases, these
requests arrive with the full support of the existing ccTLD manager;
more often, however, the requests are submitted without the knowledge
or with the open opposition of the current ccTLD manager. In all cases,
the requests must be investigated and evaluated against ICANN's published
criteria. Under ICP-1, ICANN generally makes re-delegations only with
the cooperation of the existing ccTLD manager. Where the manager disagrees
with the proposed re-delegation, IANA policy calls upon the disputing
parties to engage in cooperative dialogue, together with the local Internet
community, until a mutually agreeable solution can be found. Only in
cases of intractable conflict or recurrent technical failure by the
current manager has the IANA undertaken involuntary redelegations.
For all redelegation requests, IANA policy conducts an evaluation of
the views of the local Internet community, seeking input from affected
stakeholders and interested parties, including but not limited to governments.
This investigation and evaluation function is highly staff-intensive
and can lead to significant delays in the processing of re-delegation
requests. For major redelegations, ICANN publishes an IANA Report detailing
the request, its background, the results of its investigation, and its
8. ccTLD Name Server Changes
ICANN is responsible for processing ccTLD name server change requests.
As with redelegation requests, TLD name server changes require a surprising
amount of staff time and resources. Whenever a ccTLD manager wishes
to change one or more of its authoritative primary or secondary name
servers in the DNS root zone file, a name server change template must
be submitted to ICANN. ICANN reviews the request for completeness, and
ensures that the proposed change is consistent with published standards
for TLD name servers, such as the requirement that secondaries be placed
at dispersed locations on the Internet, to minimize the likelihood of
a single failure disabling all of them. ICANN then proceeds to verify
the request with the delegated administrative and technical contacts,
to make certain that it does not constitute an unauthorized hijacking
or stealth relegation of the ccTLD. Once the request has been verified,
ICANN tests the new name servers to see that they are functioning properly,
and proceeds to promulgate a new DNS root zone file with the updated
name server information for the ccTLD.
9. IANA TLD Database
ICANN maintains an online IANA database of contact information for
each ccTLD and gTLD registry, including the identity of the sponsoring
organization (meaning designated "trustee" for the ccTLD);
the name, physical address, e-mail address, and phone and fax numbers
for the delegated administrative and technical contacts; and the URL
for registration information. The IANA TLD database is available through
online web indices and via port 43 and port 80 Whois queries. ICANN
carefully investigates and verifies requested changes to this information
to prevent unauthorized hijacking and stealth redelegation in violation
of the IANA procedures documented in ICP-1 and RFC 1591.
B. DNS Root Name Server System
ICANN is responsible for coordinating the stable functioning of the
DNS root name server system. For top-level resolution of DNS queries,
the DNS relies upon 13 geographically distributed root name servers
(identified by letters of the alphabet). There are 12 different root
name server operators, ranging from universities to military institutions
to commercial enterprises to not-for-profit organizations (such as ICANN).
All of the root name server operators are independent volunteers, receiving
no outside compensation for their services. ICANN is responsible for
overall coordination of this system, which includes day-to-day communication
on operations and incident response. Through its Root Server System
Advisory Committee (RSSAC), which consists of the root name server operators
and invited experts, ICANN is also responsible for developing and implementing
policies relating to, for example, the distribution, location, and identity
of the root name server operators.
In partnership with the root name server operators, ICANN also participates
in research, measurement, and testing initiatives aimed at the overall
improvement of the DNS root name server system. For example, when planning
and implementation testing are complete, ICANN will operate a dedicated
primary root name server, a significant security enhancement that will
eliminate the need of the root name servers to rely on one of the machines
that handles public DNS queries to also provide the authoritative version
of the root zone file.
C. L Root Name Server
ICANN is the operator of the L root name server, one of the thirteen
authoritative DNS root name servers. This responsibility is purely operational
and entails a significant allocation of resources to support the necessary
technical staffing, hardware, and bandwidth.
D. InterNIC Service
ICANN is responsible for a set of Internet services designated by the
InterNIC service mark. These include the www.internic.net website, which
provides information on the gTLD registries, such as a listing of accredited
registrars and FAQs on dispute resolution.
E. .int Registry
ICANN currently operates the registry for the .int TLD, which is for
organizations established by international treaty. Historically, the
.int registry was also used for international Internet infrastructure-related
uses, such as .ip6.int, which was for a time designated as the location
of the reverse delegation tree for IPv6 addresses. In cooperation with
the IETF, ICANN is working to transition the infrastructure-related
domains away from .int into more appropriate TLDs, for example the new