Internet DRAFT - draft-wenzel-cctld-bcp
draft-wenzel-cctld-bcp-00.txt Zita Wenzel, Randy Bush, Steven Huter
Internet Draft draft-wenzel-cctld-bcp-00.txt
24 September 2003 Expires 24 March 2004
Country-Code Top-Level Domain Best Current Practices
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026 .
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or made obsolete by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
The list of Internet-Draft Shadow Directories can be accessed at
This document describes the issues and best current practices for the
technical organization, operation, and management of country-code
top-level domains (CCTLDs).
A top-level domain (TLD) is one of the domains directly under root in
the Domain Name System (DNS) organization of the Internet. The most
common general top-level domains are .com, .net, and .org.
A country-code top-level domain (CCTLD) is one of the top-level domains
(TLDs). There are 239 two-letter codes (defined by ISO 3166-1) that
designate countries and entities of the world.
This document summarizes best current practices of CCTLD technical
design, operation, and management. Its main objective is to provide
helpful information and guidelines for the administrators and technical
staff who operate CCTLD Registries to serve their local
1.1 Definitions and conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document SHOULD be considered as a method to further explain the
meanings and principles adopted by the document.
Note that "cctld" in lower-case is used to represent a specific
country-code top-level domain (CCTLD), for example .kh for Cambodia or
.sn for Senegal. CCTLD refers to all country-code top-level domains.
1.2 Description of the Domain Name System
The Domain Name System is defined by RFC 1034  and RFC 1035 , with
clarifications, extensions, and modifications given in RFC 1123 , RFC
1996 , RFC 2181 , among others.
Over the years, many different words have been used to describe the
components of resource naming on the Internet (e.g., URL, URN). To make
certain that the set of terms used in this document are well-defined and
non-ambiguous, the definitions are given here.
1.2.1 Zone file
A zone file contains the domains names and related data for a specific
portion of the name space.
The zone file is the presentation format of the zone itself.
A zone basically contains the domain names and data that a domain contains.
1.2.2 DNS records
Domain Name System (DNS) records are specific records that hold data
about a specific domain name. They are called Resource Records or RRs.
Each RRs has one label (or name), a class, a type, and rdata (data on
the right-hand side). The RRs for DNS are A (address), CNAME
(canonical name), PTR (pointer), SOA (start of authority), and NS (name
server). A zone MUST have SOA and NS RRs. CNAME is occasionally used. A
and MX are used by most applications.
See RFC 1035  for more information.
1.2.3 Primary server
A primary server for a zone holds the main copy of the DNS records for
that zone. This copy is stored in a zone file. This is the location of
the zone file where changes are made.
1.2.4 Secondary server
A secondary server for a zone also holds a complete copy of the records
for that zone, which it obtains by transferring them from the primary
server whenever a change is made there.
Primary and secondary servers are listed in the NS (name server) records
for the zone, and are termed authoritative servers.
1.2.5 Caching server
A caching server holds temporary copies of DNS records; it uses records
to answer queries about domain names. Since it does not have a copy of
the zone file, but merely caches individual resource records it has
fetched, it is not authoritative for data in the zone(s).
Further explanation of these terms can be found in RFC 1034 .
1.2.6 DNS names
DNS names can be represented in multiple forms, with different
properties for internationalization. The most important ones are:
A domain name is a binary representation of a name used internally in
the DNS protocol. This consists of a series of components of 1-63
octets, with an overall length limited to 255 octets (including the
In most implementations of applications today, domain names in the
Internet have been limited to the much more restricted forms used, e.g.,
in email (Simple Mail Transfer Protocol: SMTP), which defines its own
rules. Names can be entered in a case-sensitive fashion, but they are
interpreted in a case-independent fashion. They are limited to the
upper- and lower-case letters a-z, the digits, and the hyphen-minus, all
in ASCII. In addition, the specification in RFC 2821  does not allow
the components of a domain name in SMTP to start or end with a hyphen.
Internationalized Domain Name:
In the DNS protocols, a name is referred to as a sequence of octets.
However, when discussing requirements for internationalized domain
names, the question is to find ways to represent characters that are
meaningful for humans.
There are current attempts to define the requirements for an
"Internationalized Domain Name" (IDN) to allow for other scripts and
characters. IDN is defined as a sequence of characters that can be used
in the context of functions where a name is used today, but contains one
or more characters that are outside the set of characters specified as
legal characters for names RFC 1123 .
Therefore, formally the DNS protocol can transport any octets as a name.
However, there are many applications that place restrictions on what
they accept. So we suggest that you limit registered names to the narrow
acceptability of SMTP. You can actually register whatever you wish, but
you SHOULD warn registrants of names that 1) MAY NOT work with many
applications, and 2) MAY be interpreted differently in different
(national, language, etc.) contexts.
1.2.7 Registry and registrar
A registry serves as the authoritative repository for all information
REQUIRED to resolve domain names registered in the registry's top-level
domain (TLD), or second-level domains (SLDs) if the reserved SLD mode is
used (e.e.g, co.uk, ac.nz). The registry also maintains additional
information such as the administration and technical contacts for the
domain name, the billing contact, and the registrar who registered the
A registrar provides services to the registrant (the person who
registered a domain name) and provides the information to the registry.
The registrar provides domain information (servers and contact/billing
information) to the registry. The registrar MAY also provide additional
value-added services to the registrant such as email, web hosting, etc.
The registrant is the individual end-user who is requesting the domain
Normally, the registry and registrar organizations are separate. There
is one registry which SHOULD be administered as a national trust because
it is a natural monopoly by definition, and multiple registrars provide
competition in registering names with the registry. A country MAY begin
registry services by also acting as the sole, initial registrar. These
functions MAY be kept separate and the registrar MAY eventually be
transitioned away from the registry as one of many registrars. However,
combining the functions MAY also provide a simple, more efficient,
organization with less overhead.
2. Human resources REQUIRED for CCTLD administration
There must be a designated manager for supervising each domain's name
space. In the case of a CCTLD, this manager must supervise the domain
names and operate the Domain Name System (DNS) in that country. Two
points of contact, with different responsibilities, are REQUIRED.
2.1 Administrative Point of Contact (Admin POC)
The Administrative POC's job is to make simple, publishable rules that
the applicants and registrars can follow unambiguously. It is a good
idea to think of each situation as if it had to be automated. For
example, given an application for foo.com.ng, you want to be able to
write a script which sends a query to some
whois.registry-of-companies.gov.ng and see if the street address is the
same as the registered company. The Administrative POC SHOULD be
representing the local Internet community and be ensuring that the CCTLD
is being run for the benefit of the country and its citizens.
2.2 Technical Point of Contact (Tech POC)
The Technical POC's job is to maintain the contents of the zone and to
make the system work. This person SHOULD be a programmer or someone
familiar with UNIX or Linux, UNIX or Linux tools, and a DNS expert.
2.3 Programmers and technical staff
The human resources necessary to run a CCTLD registry SHOULD typically
start with an Administrative POC to handle policy issues, and a
Technical POC to run the domain. A DNS expert, a UNIX systems
administrator, and a UNIX tools/web programmer SHOULD be added. These
SHOULD be unique individuals in well-defined roles. Note that the
technical staff SHOULD be carrying out policy decisions and not making
If you are charging any fees, you SHOULD also have a financial person or
billing manager. This is especially true if your registry and registrar
functions are combined.
A lawyer is also RECOMMENDED.
3. How to structure a CCTLD and why
Each country is free to develop their own system of domain naming within
3.1 Flat versus hierarchical designs
A flat design allows any name directly under the top-level country-code
domain (i.e., the second-level domain or SLD). For example, nsrc.cctld.
A hierarchical design provides categorized or affinity groups at the
second-level. For example, mycollege.edu.cctld, where "edu" specifies
3.1.1 Two- versus three-letter SLDs
Another choice is whether to use two or three-letter second-level names.
For example, some CCTLDs use "ac" for academic while others use "edu"
for education. Some CCTLDs use "co" for corporate or commercial while
others use "com" for commercial. This is largely a matter of preference,
but note that you SHOULD NOT change it later.
Also consider whether using "com" will be easier to match or harder to
discriminate from the .com top-level domain.
3.2 Pros and cons of design choices
Flat designs are easier to start because no definition of groups is
necessary (and therefore no decisions need to be made about what names
go into which groups) and everyone has equal access.
However, hierachical designs allow more unique domain names and provide
fewer disputes over who has the "rights" to a name. For example, does My
Single Company get msc.cctld or does My Small Cooperative get msc.cctld.
SLDs can be used to solve this problem. Assuming the business is a
commercial concern and the cooperative is not, My Small Company could
register msc.com.cctld and My Small Cooperative could register
msc.org.cctld, where "com" is for commercial entities and "org" is for
Another possibility is to not allowing abbreviations at any
level.my-small-company.cctld and my-small-coop.cctld are uniquely
identified and easily found.
It is in your, and your users, best interest to choose a design and be
See section 3.4 on Changing the Structure.
3.3 Survey of other CCTLD structures
Some examples are:
Country CCTLD Example
Flat (non-hierarchical) organization:
Senegal SN ucad.sn (Universite' Cheikh Anta Diop)
Hierarchical, affinity-based second-level domains:
Japan JP co.jp (co stands for corporations), ac.jp (ac
stands for academic), etc.
Hierarchical, affinity-based second-level domains:
Uganda UG sc.ug (sc stands for non-bacccalaureate
Geo-political organization by state (second-level domains) and city
United States US wenzel.los-angeles.ca.us (ca is the state code for
3.4 Changing the structure
You SHOULD NOT change the structure. Changing the structure later will
cause a number of problems and disputes.
If Mary registered mary.co.cctld and Maryanne registered mary.or.cctld,
who would get mary.cctld after a conversion to no SLDs?
Because people in general prefer short names, another possible problem
is if a person who has registered earlier has harry.cctld and a person
who is currently registering must register under a SLD (e.g.,
mary.co.cctld), there MAY be complaints. This is also true for the
reverse situation, i.e., if the first person had to register
harry.co.cctld and a new person registering can be registered directly
under the CCTLD (e.g., mary.cctld).
3.5 Distributed administration
The pros and cons of the hierachical distribution (as the United States
CCTLD, .us, was orignally organized) are that administration is
delegated along with the zone (see RFC 1480 ). For example, the name
los-angeles.ca.us is registered and then delegated to an entity chosen
by the city. Therefore, requests for names under los-angeles.ca.us go to
that entity and not to the .us CCTLD Registry. An advantage is less work
for the Registry. However, it is important to have a contractual
relationship with the delegated registrars so that they are following
all the rules and regulations of the CCTLD Registry (and RFC 1591 ).
It is important to communicate regularly with all delegated registrars.
4. Technical requirements for CCTLD administration
For hardware, you will need a primary server, one or more secondary
servers, and preferably, a test server. These servers SHOULD be robust,
geographically and physically separate, and on diverse networks. Note
that you SHOULD own and operate the primary server, but the secondary
servers are usually owned and operated elsewhere and you SHOULD have an
agreement with those organizations to run your secondary service. In
fact, if you can get competently managed and well-connected servers
(like NS.RIPE.NET) as your secondary servers, you will be in a more
secure and reliable position.
It is the goal for the primary server to be in the country, but it I not
mandatory. During the startup phase, the primary server MAY be out of
4.1 Secondary servers: geographical diversity and contracts
See RFC 2182  for rationale and RECOMMENDATIONS about the selection
and operation of secondary servers. Secondary servers are REQUIRED for
the continued operation of the Internet and it is up to the CCTLD
Registry to be firm in enforcing this requirement for the CCTLD and all
Geographical diversity of DNS servers of the CCTLD is REQUIRED. See
section 5 of RFC 2182 . Having secondary servers on different
continents is RECOMMENDED.
The NS RRset in the zone MUST match that in the root zone. A similar
requirement SHOULD be imposed on delegations below the CCTLD.
4.1.1 Secondary servers for CCTLD sub-delegations
More than one secondary server SHOULD be allowed.
Of the server set, two MUST satistfy RFC 2182 . It makes no
difference which two, they could be secondaries.
4.2 Physically separate networks
It is VERY STRONGLY RECOMMENDED to maintain name servers on physically
separate international backbones and physically separate Points of
4.3 Physical and electronic security
All of the servers, especially the primary server SHOULD be physically
and electronically secure. The server SHOULD be in a burglar-proof
building with sensor monitors or security guards. There SHOULD be an
Uninterruptable Power Supply (UPS) and a power generator for electricity
o See RFC 2870  and consider which of its recommendations are
appropriate for the scale of your particular zone.
o RECOMMEND the use of TSIG for zone transfer to your secondaries.
See RFC 2845 .
o See RFC 2182  for RECOMMENDATIONS.
o The CERT Coordination Center is a center of Internet security
expertise. See <http://www.cert.org/>
o The SANS (SysAdmin, Audit, Network Security) Institute is a
cooperative research and education organization. See
4.3.1 Zone transfer access
For each zone for which a server is primary, it SHOULD limit "axfr" zone
transfer access to agreed secondary servers for that zone. Secondaries
SHOULD NOT allow "axfr" zone transfer access to the zones for which they
4.4 Quality of service (QoS)
You SHOULD aim for 24 hours/7 days/365 days a year
connectivity/availability and ability and responsiveness to handle the
4.5 DNS software and tools
4.5.1 Operating system and BIND software
Do not use Microsoft servers for DNS service; they behave oddly, scale
poorly, and have very bad security problems. UNIX or Linux is
recommended as the operating system of choice.
To effectively run Internet services, and manage, upgrade, and care for
your systems, there is much to learn. While it might initially seem to
be easier with Windows, there is a lot to learn no matter which
operating system one chooses. So we have found that it's best to move to
UNIX or Linux as soon as possible, and learn as you go.
The Internet Software Consortium (ISC) is a not-for-profit corporation
dedicated to developing and maintaining production quality Open Source
reference implementations of core Internet protocols. ISC produces and
maintains BIND (Berkeley Internet Name Domain), which is an
implementation of the Domain Name System (DNS) protocols and provides an
openly redistributable reference implementation of the major components
of the Domain Name System, including:
o a Domain Name System server (named)
o a Domain Name System resolver library
o tools for verifying the proper operation of the DNS server
The BIND DNS Server is used on the vast majority of name serving
machines on the Internet, providing a robust and stable architecture on
top of which an organization's naming architecture can be built. The
resolver library included in the BIND distribution provides the standard
APIs for translation between domain names and Internet addresses and is
intended to be linked with applications requiring name service.
BIND software is complex, therefore it has a many year track record of
bugs and security issues. It is important to stay very current.
See http://www.isc.org/ for more information on ISC and BIND.
Note that there are other implementations of the DNS other than BIND.
4.5.2 Web-based registration software
Web-based registration software is also RECOMMENDED. This software
SHOULD be easy-to-use and well-documented. Use of pre-written text
responses (and FAQs) for common problems is also recommended. Scripts
are also RECOMMENDED.
Tools available and RECOMENDED for setting up on-line registration,
running, and management of a CCTLD include:
The use of the "dig" command/tool is RECOMMENDED:
o "dig" sends domain name query packets to name servers.
"dig" (Domain Information Groper) is a flexible command line tool which
can be used to gather information from the Domain Name System (DNS)
servers. Dig has two modes: simple interactive mode which makes a single
query, and batch which executes a query for each in a list of several
query lines. All query options are accessible from the command line.
The use of the "ping" command/tool is RECOMMENDED for times to sites to
determine if a server is up and running. Note that ping will not pass
The use of the "traceroute" command/tool is RECOMMENDED to follow routes
and to evaluate routing efficiency.
"traceroute", from a diversely and well-connnected host, is the best way
to look at RFC 2182  compliance.
4.6 Whois data
The maintenance and availability of registration information via a
"whois" server is RECOMMENDED, but it is not an RFC 1591 requirement.
"whois" data is information relating to the registration of a domain
name. These data MAY include name, address, and contact information. Use
the RIPE software:
"rwhois" (remote whois service) is NOT RECOMMENDED.
Off-site backup for "whois" data is RECOMMENDED.
4.7 Serial numbers (yyyymmddnn)
See RFCs 1982  and 2182 .
Before 1999, serial numbers were often in the form of 99mmddnn (where mm
is the numerical value for the month, dd is the numerical value for the
day, and nn is the consecutive number of modifications done in that day).
However, in order to accomodate the year 2000 forward, you SHOULD use
serial numbers in the form:
and SHOULD NOT use the form:
CCTLDs that use ddmmyynn MAY choose to use that system in their serial
numbers and SHOULD be consistent and document the choice.
Note that the ddmmyy format is dangerous unless the zone is being
updated frequently enough and the "soa expire" value is short enough so
that the "soa serial" number does not wrap before it expires.
For specific information on serial numbers, see section 7 of RFC 2182
 and RFC 1982  on serial number arithmetic.
4.8 TTL best practice
TTL stand for "time to live". You need to decide on a TTL for the data.
The TTL is the amount of time that any name server is allowed to cache
the data. After the TTL expires, the name server must fetch new data
from the authoritative name servers. This decision is a trade-off
between performance and consistency.
See RFC 1912 . Also see RIPE Best Practices at
An example is:
$TTL 4h ; time-to-live of four hours
@ 4h IN SOA rip.psg.com. hostmaster.psg.com. (
200212220 ; serial
86400 ; refresh every one day
3600 ; retry every hour
2592000 ; expire in 30 days
144400 ) ; default TTL of 4 hours
4.9 Lame delegations
A lame delegation is defined as when the parent zone and/or the primary
zone names a server which is not actually authoritative for the zone,
i.e., a listed secondary which is not really acting as a secondary is a
lame delegation from the parent or the authoritative zone file.
The tool "dig" is useful in finding and fixing lame delegations. It is
critical to be firm in not allowing lame delegations to take place
during the delegation process. Both primary and secondary servers MUST
be running correctly before delegation occurs.
It is also important to periodically test for lame delegations. A
suggested schedule SHOULD be considered for standard operation and
maintenance of the zone files.
4.10 Web site registration
Registration of domain names via a web site is RECOMMENDED.
See section 4.5.2.
4.11 Registrar registry protocol
The Provisioning Registry Protocol working group of the IETF has
developed the Extensible Provisioning Protocol (EPP) which has evolved
from the Registrar-Registry Protocol (RRP). This protocol is for the
exchange of information between registrars and registries and is only
needed for very large domains.
See RFCs 3375  and 2832  for more information.
5. Operational Aspects of CCTLD Administration
It is RECOMMENDED to set up a separate, non-profit, cost-recovery
organization for the administration of the CCTLD.
This will reduce the possibility of capture by any one special interest
It is possible to start with the registry and the sole registrar as one
organization, but the RECOMMENDED structure is to have one non-profit,
cost-recovery registry with many competing registrars (ISPs).
Templates are used by all CCTLD Registries and guarantee that standard,
and critical, information is collected for each registration. You can
incorporate the template information into a web version, but it is
RECOMMENDED to get all of the same information.
5.2.1 New registrations
A complete and correct template must be received.
The administrative contact MUST be from the organization actually using
the domain name. The technical contact MAY be from another organization
or Internet Service Provider (ISP).
The Administrative Point of Contact (Admin POC) is the person who will
make social and political decisions about the zone, arbitrate disputes,
and delegate technical authority to the Technical Point of Contact (Tech
The Technical Point of Contact (Tech POC) SHOULD be the programmer who
is editing the zone on the primary server. The Tech POC SHOULD be very
familiar with the Domain Name System (DNS).
Also see RFC 1591 .
A completed template is REQUIRED from either the administrative or
A new technical contact MAY NOT submit the template. This is to prevent
a rogue ISP or technical person from misappropriating the name without
the knowledge of the current administration.
A completed template is REQUIRED from either the administrative or
Approval SHOULD be received from both the administrative and technical
If it is a lame delegation, it is not necessary to obtain approval
although it is a good idea to send a notice to the contacts.
Always REQUIRE and test that:
o ALL servers are working
o NS RRSET returned from servers is equal to the NS RRSET being registered
o there are working technical and administrative contact email addresses
o there are working technical and administrative contact phone numbers
5.3 Zone transfers
It is RECOMMENDED that the CCTLD Registry require zone transfer (axfr)
access. This will allow the Registry to fix problems later.
5.4 Phone calls, faxes, emails
Decide how much technical and procedural help you are willing to give to
You are not obliged to be a training center. This MAY be an added
service, but SHOULD NOT be REQUIRED in order to register a domain name.
"It is REQUIRED to respond to requests in a timely manner, and to
operate the database with accuracy, robustness, and resilience."
See RFC 1591 .
5.6 Agreement to administer a domain
For an example, see Appendix A.
5.7 Other Suggestions
o When it gets difficult to manage, it is time to automate more.
o Someone who understands the DNS is REQUIRED.
o The administrative and technical contacts need to work together.
o Being unnecessarily formal now will force regularity which you will
appreciate when you have to scale up and automate later.
o Keep the registration application forms and all correspondance.
6. Policy Aspects of CCTLD Administration
6.1 Goal of the CCTLD
It is REQUIRED that the administrative contact (Admin POC) of the CCTLD
be a person from, and currently residing in, the country. The technical
contact (Tech POC) can be temporarily from outside the country, but it
is expected that the technical contact SHALL transition to someone
within the country. See RFC 1591 .
Fair and equitable rules and regulations are REQUIRED. Everyone MUST be
"This means that the same rules are applied to all requests, all
requests must be processed in a non-discriminatory fashion, and academic
and commercial (and other) users are treated on an equal basis. No bias
shall be shown regarding requests that MAY come from customers of some
other business related to the manager -- e.g., no preferential service
for customers of a particular data network provider (ISP)."
See RFC 1591 .
6.2 Generic domain names
It is up to the CCTLD to decide whether and how to register generic
domain names (for example, hotels.cctld). Note that this is a major
point of contention.
It is RECOMMENDED not to register generic domain names to avoid
arguments over who can register them.
Fees SHOULD be fair and equitable (see RFC 1591 ).
Since the CCTLD Registry is a natural monopoly, and is intended for the
good of the local community, fees SHOULD NOT significantly exceed expenses.
See the World Intellectual Property Organization (WIPO) "Best Practices
for Prevention and Resolution of Intellectual Property Disputes"
6.5 Dispute resolution
See ICANN's Uniform Dispute Resolution Procedure (UDRP), but determine
if this is useful for your country. <http://www.icann.org/udrp/>
See the ICANN Uniform Dispute Resolution Procedure (UDRP) and determine
if outside arbiters are useful for your country.
6.6 Relationship with ICANN
The CCTLD is delegated by the Internet Assigned Numbers Authority (IANA)
which is a function currently within the Internet Corporation for
Assigned Names and Numbers (ICANN). IANA maintains the authoritative
database of delegations of CCTLDs, including the administrative and
technical contacts (Admin and Tech POCs), and registration URLs. IANA is
the top-level authority for the Internet and is responsible for placing
the top-level domains (TLDs) in the root server (system) so that the TLD
is accessible throughout the international Internet.
Currently, all CCTLDs are part of the CCTLD Supporting Organization
(CCNSO) of ICANN. See the cctld-discuss mailing list for more
information <cctld email@example.com>. Subscribe by emailing
Note that there is also a technical CCTLD mailing list at
<firstname.lastname@example.org>. Subscribe by emailing
6.7 Relationship with registrars
It is RECOMMENDED to maintain contractual relationships with registrars
noting that they must maintain the principles set forth by the Registry.
7. Editors' Contact
Zita Wenzel, Ph.D.
Network Startup Resource Center
1225 Kincaid Street
1212-University of Oregon
Eugene, OR 97403-1212 USA
 Bradner, S., "The Internet Standards Process -- Revision 3", RFC
2026, October 1996.
 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
 Mockapetris, P., "Domain Names - Concepts and Facilities, RFC 1034,
 Mockapetris, P., "Domain Names - Implementation and Specification",
RFC 1035, November 1987.
 Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
 Braden, R., "Requirements for Internet Hosts -- Application and
Support", RFC 1123, October 1989.
 Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS
NOTIFY)", RFC 1996, August 1996.
 Elz, R., Bush., R., "Clarifications to the DNS Specification", RFC
2181, July 1997.
 Eastlake, D., "Domain Name System Security Extensions", RFC 2535,
 Harrenstien, K., Stahl, M., Feinler , E., "DOD Internet Host Table
Specification", RFC 952, October 1985.
 Postel, J., Cooper, A. "The US Domain", RFC 1480, April 1993.
 Postel, J., "Domain Name System Structure and Delegation", RFC
1591, March 1994.
 Elz, R., Bush, R., Bradner, S., Patton, M., "Selection and
Operation of Secondary DNS Servers", RFC 2182, July 1997.
 Bush, R., Karrenberg, D., Kosters, M., Plzak, R., "Root Name Server
Operational Requirements", RFC 2870, June 2000.
 Vixie, P., Gudmundsson, O., Eastlake 3rd, D., Wellington, B.,
Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May
 Elz, R., Bush, R., "Serial Number Arithmetic", RFC 1982, July 1996.
 Barr, D., "Common DNS Operational and Configuration Errors", RFC
1912, February 1996.
 Hollenback, S. Generic Registry-Registrar Protocol Requirements",
RFC 3375, September 2002.
 Hollenback, S., Srivastava, M. "NSI Registry Registrar Protocol
(RRP) Version 1.1, RFC 2832, May 2000.
 Albitz, P. and Liu, C., "DNS and BIND", 4th Edition, O'Reilly
Books, April 2001, ISBN 0-596-00158-4.
9. Acknowledgements and disclaimer
This document has been prepared in our individual capacities and does
not necessarily reflect the views of our past or present employers.
Several people, including Rob Austein, Ayitey Bulley, Brian Candler,
John Klensin, Andy Linton, Dave Meyer, and Mike O'Dell, have made
suggestions or offered editorial comments about earlier versions of this
document. These comments contributed significantly to whatever clarity
the document has, but the authors bear responsibility for the content.
This material is partially based upon work supported by the National
Science Foundation under Grant No. NCR-9981821. Any opinions, findings,
and conclusions or recommendations expressed in this material are those
of the authors and do not necessarily reflect the views of the National
10. Security Considerations
Please see the Internet Draft draft-ietf-dnsext-dnssec-intro-03.txt "DNS
Security Introduction and Requirements".
In general, delegation-signer is moving forward as a mechanism to sign
zones. However, do not worry if you do not currently have signed zones.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined
in the Internet Standards process must be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.
Funding for the RFC Editor function is currently provided by the