Last Revised November 1, 2006 Zita Wenzel, Randy Bush, Steven Huter Country-Code Top-Level Domain Best Current Practices Copyright Notice Copyright rests with the authors. Freedom to copy with attribution. 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 generic 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 approximately 23 9 two-letter codes (primarily defined by ISO 3166-1) that designate countries and entities of the world. See ISO 3166-1 . 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. For more background information on the Internet's administrative procedures, see "Guide to "Administrative Procedures of the Internet Infrastructure" . 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 are to be interpreted as described in RFC 2119 . Note that "cctld" in lower-case is used to represent a single 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. Also see RFC 434  which updates RFCs 1034, 1035, and 2181. 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 internal representation the software uses. 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 (canonical name) is rarely used, and only with great caution. A and MX (mail exchanger) are used by the mail sending application. See RFC 1035  for more information. For more background information, see the "DNS and BIND" book . 1.2.3 Primary server A primary server for a zone holds the original authoritative 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. It is to be noted that clients looking up names in the DNS do not differentiate between the primary server and secondaries. 1.2.5 Caching server A caching server holds temporary copies of DNS records; it uses resource 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. See RFC 4343 . 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 labels 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 or 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.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 and 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. Note, however, that this would now be a monopoly on two levels and separation later may be problematic. 2. Human resources RECOMMENDED 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 (POC), with different responsibilities, are REQUIRED. 2.1 Administrative Point of Contact (Admin POC) The Registry's Administrative POC's role 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 example.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 role 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 and 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, mycompany.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 (TLD). 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, hierarchical 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 company 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 allow abbreviations at any level. my-small-company.cctld and my-small-coop.cctld are uniquely identified and easily found. So are mysmallcompany.cctld and mysmallcooperative.cctld. 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-baccalaureate schools), etc. Geo-political organization by state (second-level domains) and city (third-level domains): United States US example.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 a flat structure with 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 There are pros and cons of the hierarchical distribution (as the United States ccTLD, .us, was originally organized) because the 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 ). If you don?t, you MAY have problems with inconsistent policies and implementation. 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 from RIPE) as your secondary servers, you will be in a more secure and reliable position. Technical stability is the key concern. It is the goal for the primary server to be in the country, but it is not mandatory. During the startup phase, the primary server MAY be out of the country. 4.1 Secondary servers 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 sub-delegations. 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. More are better. Of the server set, two MUST satisfy 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 Presence (POPs). 4.3 Physical and electronic security All of the servers, especially the primary server SHOULD be physically and electronically secure. The primary server SHOULD be in a burglar-proof building with sensor monitors or security guards. There SHOULD be an Uninterruptible Power Supply (UPS) and a power generator for electricity failures. 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 CERT . o The SANS (SysAdmin, Audit, Network Security) Institute is a cooperative research and education organization. See SANS . See 10. Security considerations for more information on DNS security. 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 You SHOULD 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 is best to move to UNIX or Linux as soon as possible, and learn as you go. The Internet Systems Consortium, Inc. (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  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 to measure 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-connected 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: ftp://ftp.ripe.net/ripe/dbase/software/whoisserver-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  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 accommodate 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  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 . An example is: $TTL 4h ; time-to-live of four hours @ 4h IN SOA example.com. hostmaster.example.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 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). See also section 1.2.7. 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. It is RECOMMENDED to get all of the same information for each registration. 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 . 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 . 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 extremely 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 correspondence. 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 same country as the ccTLD. 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 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 . 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 ). 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) "Domain Name Dispute Resolution Resources" . 6.5 Dispute resolution See ICANN's Uniform Dispute Resolution Procedure (UDRP), but determine if this is useful for your country. See ICANN's Uniform Dispute Resolution Procedure (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. There is a ccTLD Supporting Organization inside ICANN. See  for more information. Note that there is also a technical ccTLD mailing list. 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. Authors' Addresses Zita Wenzel, Ph.D. Information Sciences Institute University of Southern California 4676 Admiralty Way, Suite 1001 Marina del Rey, CA 90292 USA Email: email@example.com Randy Bush IIJ P.O. Box 128 Kapa`au, Hawai`i 96755 USA Email: firstname.lastname@example.org Steven Huter Network Startup Resource Center 1225 Kincaid Street 1212-University of Oregon Eugene, OR 97403-1212 USA Email: email@example.com Comments are solicited and should be addressed to the author(s). 8. References 8.1 Normative References  Bradner, S., "Intellectual Property Rights in IETF Technology", RFC 3979, March 2005.  ISO 3166-1, <http://www.iso.ch/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/index.html>.  Bradner, B., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.  Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 1034, November 1987.  Mockapetris, P., "Domain Names - Implementation and Specification", RFC 1035, November 1987.  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. III, "Domain Name System (DNS) Case Insensitivity Clarification", RFC 4343, January 2006.  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.  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 2000.  CERT, <http://www.cert.org/>.  SANS, <http://www.sans.org/>.  ISC and Bind <http://www.isc.org/>.  Elz, R., Bush, R., "Serial Number Arithmetic", RFC 1982, July 1996.  Barr, D., "Common DNS Operational and Configuration Errors", RFC 1912, February 1996.  RIPE "Best Practices", <http://www.ripe.net/ripe/docs/ripe-203.html>.  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.  World Intellectual Property Organization (WIPO) "Domain Name Dispute Resolution Resources", <http://arbiter.wipo.int/domains/resources/index.html>.  ICANN "Uniform Dispute Resolution Procedure (UDRP)", <http://www.icann.org/udrp/>.  ICANN "ccTLD Supporting Organization" <http://ccnso.icann.org>. 8.2 Informative References  Albitz, P. and Liu, C., "DNS and BIND", 4th Edition, O'Reilly Books, April 2001, ISBN 0-596-00158-4.9.  Wenzel, Z., Klensin, J., Bush, R., Huter, S., "Guide to Administrative Procedures of the Internet Infrastructure", RFC 2901, August 2000. 9. Security Considerations Please see "DNS Security Introduction and Requirements", <http://www.rfc-editor.org/rfc/rfc4033.txt>. In addition review "DNSSEC Operational Practices", <http://www.rfc-editor.org/rfc/rfc4641.txt>. 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. 10. 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 Jaap Akkerhuis, Rob Austein, Ayitey Bulley, Brian Candler, John Klensin, Andy Linton, Dave Meyer, Mike O'Dell, and Oscar A. Robles-Garay 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.