Internet DRAFT - draft-wenzel-cctld-bcp

draft-wenzel-cctld-bcp




draft-wenzel-cctld-bcp-00.txt Zita Wenzel, Randy Bush, Steven Huter
Internet Draft draft-wenzel-cctld-bcp-00.txt
Category: Informational
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 [1].

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 
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at 
<http://www.ietf.org/shadow.html>.

Abstract

This document describes the issues and best current practices for the 
technical organization, operation, and management of country-code 
top-level domains (CCTLDs).

1. Introduction

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. 
<http://www/iso.ch/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/index.html>. 


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
Internet communities.

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 [3] and RFC 1035 [4], with 
clarifications, extensions, and modifications given in RFC 1123 [6], RFC 
1996 [7], RFC 2181 [8], 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 [4] 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 [3].

1.2.6 DNS names

DNS names can be represented in multiple forms, with different 
properties for internationalization. The most important ones are:

Domain name:

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 
length fields).

Email:

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 [5] 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 [6].

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 
domain name.

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 
name.

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 
policy.

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 
their CCTLD.

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 
educational institutions.

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 
non-profit organizations.

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 
consistent.

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
schools), etc

Geo-political organization by state (second-level domains) and city 
(third-level domains):

United States US wenzel.los-angeles.ca.us (ca is the state code for 
California)

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 [11]). 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 [12]). 
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 
the country.

4.1 Secondary servers: geographical diversity and contracts

See RFC 2182 [13] 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 
sub-delegations.

Geographical diversity of DNS servers of the CCTLD is REQUIRED. See 
section 5 of RFC 2182 [13]. 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 [13]. 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 
Presence (POPs).

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 
failures.

o See RFC 2870 [14] 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 [15].

o See RFC 2182 [13] 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
<http://www.sans.org/>

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 
are secondary.

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 
query load.

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.

4.5.3 Tools

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.

o "ping"

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 
firewalls.

o "traceroute"

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 [13] 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:

<ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-latest.tar.gz>

"rwhois" (remote whois service) is NOT RECOMMENDED.

Off-site backup for "whois" data is RECOMMENDED.

4.7 Serial numbers (yyyymmddnn)

See RFCs 1982 [16] and 2182 [13].

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:

2000mmddnn

and SHOULD NOT use the form:

00mmddnn

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 
[13] and RFC 1982 [16] 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 [17]. Also see RIPE Best Practices at 
<http://www.ripe.net/ripe/docs/ripe-203.html>.

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 [18] and 2832 [19] 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
group.

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).

5.1 Templates

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 Procedures

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 
POC).

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 [12].

5.2.2 Modifications

A completed template is REQUIRED from either the administrative or 
technical contact.

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.

5.2.3 Deletions

A completed template is REQUIRED from either the administrative or 
technical contact.

Approval SHOULD be received from both the administrative and technical 
contact.

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.

5.2.4 Redelegations

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 
people.

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.

5.5 Timeliness

"It is REQUIRED to respond to requests in a timely manner, and to 
operate the database with accuracy, robustness, and resilience."

See RFC 1591 [12].

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 [12].

Fair and equitable rules and regulations are REQUIRED. Everyone MUST be 
treated equally.

"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 [12].

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.

6.3 Fees

Fees SHOULD be fair and equitable (see RFC 1591 [12]).

Since the CCTLD Registry is a natural monopoly, and is intended for the 
good of the local community, fees SHOULD NOT significantly exceed expenses.

6.4 Trademarks

See the World Intellectual Property Organization (WIPO) "Best Practices 
for Prevention and Resolution of Intellectual Property Disputes" 
<http://ecommerce.wipo.int/>.

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 discuss@wwtld.org>. Subscribe by emailing 
<cctld-discuss request@wwtld.org?subject=subscribe>.

Note that there is also a technical CCTLD mailing list at 
<cctld-tech@wwtld.org>. Subscribe by emailing 
<cctld-tech-request@wwtld.org?subject=subscribe>.

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.
Email: zita@psg.com

Randy Bush
Email: randy@psg.com

Steven Huter
Network Startup Resource Center
1225 Kincaid Street
1212-University of Oregon
Eugene, OR 97403-1212 USA
Email: sghuter@nsrc.org

8. References

[1] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 
2026, October 1996.

[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 
Levels", RFC 2119, March 1997.

[3] Mockapetris, P., "Domain Names - Concepts and Facilities, RFC 1034, 
November 1987.

[4] Mockapetris, P., "Domain Names - Implementation and Specification", 
RFC 1035, November 1987.

[5] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.

[6] Braden, R., "Requirements for Internet Hosts -- Application and 
Support", RFC 1123, October 1989.

[7] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS 
NOTIFY)", RFC 1996, August 1996.

[8] Elz, R., Bush., R., "Clarifications to the DNS Specification", RFC 
2181, July 1997.

[9] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, 
March 1999.

[10] Harrenstien, K., Stahl, M., Feinler , E., "DOD Internet Host Table 
Specification", RFC 952, October 1985.

[11] Postel, J., Cooper, A. "The US Domain", RFC 1480, April 1993.

[12] Postel, J., "Domain Name System Structure and Delegation", RFC 
1591, March 1994.

[13] Elz, R., Bush, R., Bradner, S., Patton, M., "Selection and 
Operation of Secondary DNS Servers", RFC 2182, July 1997.

[14] Bush, R., Karrenberg, D., Kosters, M., Plzak, R., "Root Name Server 
Operational Requirements", RFC 2870, June 2000.

[15] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., Wellington, B., 
Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May
2000.

[16] Elz, R., Bush, R., "Serial Number Arithmetic", RFC 1982, July 1996.

[17] Barr, D., "Common DNS Operational and Configuration Errors", RFC 
1912, February 1996.

[18] Hollenback, S. Generic Registry-Registrar Protocol Requirements", 
RFC 3375, September 2002.

[19] Hollenback, S., Srivastava, M. "NSI Registry Registrar Protocol 
(RRP) Version 1.1, RFC 2832, May 2000.

[20] 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 
Science Foundation.

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.

Acknowledgement

Funding for the RFC Editor function is currently provided by the 
Internet Society.