Network Working Group W. Simpson, Editor Internet Draft DayDreamer expires in six months January 1996 Domain Name System Registration draft-simpson-dns-registry-01.txt (a) Status of this Memo Distribution of this memo is unlimited. This document is an Internet-Draft. Internet Drafts are working doc- uments of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute work- ing documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as refer- ence material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on: ftp.is.co.za (Africa) nic.nordu.net (Europe) ds.internic.net (US East Coast) ftp.isi.edu (US West Coast) munnari.oz.au (Pacific Rim) Abstract This document provides information on the administrative structure of the Domain Name System (DNS), specifically the domain name reg- istries. 1. Introduction The Internet Architecture Board (IAB), also known as the Internet Activities Board, is responsible for the coordination of technical, procedural, and (where appropriate) policy matters pertaining to the Internet and its enabling technologies [RFC-1601]. In particular, the IAB is responsible for editorial management and publication of the Request for Comments (RFC) document series, and for administra- tion of the various Internet assigned numbers. The IAB has designated an Internet Assigned Numbers Authority (IANA) to coordinate the registration of Internet protocol numbers, the top level Domain Names, and many other parameters used in the Internet [IANA-CHARTER]. IANA discretion in the execution of these duties is explicitly limited to technical and engineering considerations. A separate Internet Secretariat has been designated to coordinate meetings, publish minutes and drafts, and administer funds related to the coordination of the Internet [RFC-2028]. The principle purpose of the Domain Name System (DNS) is to provide an unlimited supply of unique names for mapping to machine resources (such as protocol addresses, numbers and services). The DNS provides for a hierarchy of servers, organized into distributed zones, with local caching to improve performance. The root of the DNS is unnamed, and is usually represented by a trailing dot ".", as at the end of a sentence. The small set of zone names that are delegated at the root are called "primary-level domain names" (1LDN). Under each 1LDN may be created a hierarchy of names, sometimes called "secondary-level domain names" (2LDN), "tertiary- level domain names" (3LDN), and so forth. With the advent of DNS Security and Dynamic Update capability, it is recently possible to allow multiple registries to update the same DNS servers. This document details the responsibilites of the designated managers of domains and the corresponding registration services. Delegation of 1LDNs is described in a companion document. 2. Designated Managers The Internet Assigned Numbers Authority (IANA) IANA has sole author- ity to create or remove a primary-level domain name (1LDN) delega- tion, or transfer delegation to another designated manager that meets the established criteria. A new 1LDN is usually created and dele- gated to a designated manager at the same time. However, it is also appropriate for interested parties to have some voice in selecting the designated manager. Significantly interested parties in the domain should agree that the designated manager is appropriate. There are two cases where the IANA may establish a new 1LDN and dele- gate only a portion of it: 1) there are contending parties that cannot agree, or 2) the applying party may not be able to represent or serve the whole domain. This case sometimes arises when a party outside a country is trying to be helpful in getting networking started within that country. This is sometimes called a "proxy" DNS service. The designated manager has principle responsibility for oversight of both operation and security of the delegated domain. 2.1. Responsibility The designated manager must be equitable to all groups in the domain that request domain names. 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 users (and oth- ers) are treated on an equal basis. No bias shall be shown regarding requests that may come from cus- tomers of some other business related to the manager. For example, no preferential service for customers of a particular data network provider. There can be no requirement that a particular mail system (or other application), protocol, or product be used. Concerns about "rights" and "ownership" of domains are inappropriate. The designated managers are trustees for the delegated domains, and have a duty to serve the community. In the case of primary-level domains (1LDNs) that are country codes, the designated manager is the trustee of the primary-level domain for both the country and the global Internet community. 2.2. Management There must be an administrative contact and a technical contact for each domain. Of course, these contacts must be on the Internet. There must be SMTP connectivity to the contacts and management staff. In the case of primary-level domains (1LDNs) that are country codes, this means that there is a manager that supervises the domain names and operates the Domain Name System in that country. inistra- tive contact should reside in the country involved. 2.3. Performance The designated manager must do a satisfactory job of operating the DNS service for the domain. That is, the actual management of the assigning of domain names, delegating sub-domains and operating name- servers must be done with technical competence. This includes keeping the regional registries (in the case of pri- mary-level domains) or other higher-level domain manager advised of the status of the domain, responding to requests in a timely manner, and operating the database with accuracy, robustness, and resilience. There must be a primary and a secondary nameserver that have Internet Protocol (IP) connectivity, and can be easily checked for operational status and database accuracy by the registries and the IANA. 2.4. Sub-Domains Most of these same concerns are relevant whenever a zone is dele- gated. There are no requirements on sub-domains of primary-level domains beyond the requirements on higher-level domains themselves. In general, the principles described here apply recursively to all delegations of the DNS name space. In particular, all sub-domains shall be allowed to operate their own domain name servers, providing in them whatever information the sub- domain manager sees fit (as long as it is true and correct). 2.5. Problems In cases when there are persistent problems with the proper operation of a domain, the delegation may be revoked, and possibly delegated to another designated manager. Reasons for revokation include (but are not limited to): 1) Domain is not adequately maintained. 2) Domain no longer serves the constituency specified in the Charter. 3) Manager SOA contact invalid or not answered for more than 72 hours. 4) Manager fails to meet other responsibilities specified for the domain. The IANA tries to have any contending parties reach agreement among themselves, and generally takes no action to change things unless all the contending parties agree. Only in cases where the designated manager has substantially mis-behaved would the IANA step in. 2.6. Transfer For any transfer of the designated manager trusteeship from one orga- nization to another, the higher-level domain manager (the IANA in the case of primary-level domains) must receive communications from both the old organization and the new organization that assure the IANA that the transfer is mutually agreed, and that the new organization understands its responsibilities. It is also very helpful to receive communications from other parties that may be concerned or affected by the transfer. 3. Registries To better distribute the administrative burden, multiple registries may be established to dynamically update a domain. Each registry is certified by the designated manager for the delegated domain. In addition to the responsibilities detailed above, any designated manager that performs registration services for its delegated domain must also meet the qualifications of a registry. There are many policy concerns involved when a registry is estab- lished. Additional concerns are raised when it is necessary to coor- dinate exchange of domain name registrations from one party to another. 3.1. Certification The major concern in certifying a registry is that it be able to carry out the necessary responsibilities, and have the ability to do an equitable, just, honest, and competent job. There must be an administrative contact and a technical contact for each registry. Of course, these contacts must be on the Internet. There must be SMTP connectivity to the contacts and management staff. A registry that desires to serve a particular domain must certify its eligibility to the designated manager for that domain. From time to time, at intervals specified by the designated manager for each domain, the registry must recertify its continuing eligibil- ity. Typically, this will be quarterly or semi-annually. 3.2. Performance Bond As an initial qualification, any organization desiring to serve as a registry must deposit a performance bond with the Internet Secre- tariat. In turn, the Secretariat will notify IANA when the registry has met the basic eligibility criteria. The amount of the performance bond must reflect the number of domains served by the registry, the number of transactions anticipated by the registry, and cover the amount of fees generated annually by the reg- istry. As a baseline, the performance bond will be $5,000 per domain served. Any monetary interest or capital appreciation accumulated by the bond will be used to fund the expenses of maintaining the Internet Secre- tariat. 3.3. Fees Whenever a registry charges fees for its DNS registration services, one third (1/3) of such fees shall be paid to the Internet Secre- tariat on a monthly basis. In turn, the Secretariat will notify IANA when the registry has met the continuing eligibility criteria. Should a registry bundle its services with some other business in such a manner that the registration fee is not distinguished, the one third (1/3) share shall apply to the total gross fees charged by the registry organization in any month. When the registration fee falls below $3, a minimum of $1 per annum fee per registration will be assessed. For certified non-profit registries that do not charge any fees, or whose monthly share payment would fall below $50, the minimum fees may optionally be waived, at the discretion of IANA. Should any registry fall more than 14 days behind in payment of the monthly fees, the fees shall be deducted from the performance bond, and the registry will lose certification until the performance bond is replenished. The fees will be used to fund the expenses of maintaining the IANA. 3.4. Problems The Internet DNS Names Review Board (IDNB), a committee established by the IANA, will act as a review panel for cases in which the par- ties cannot reach agreement among themselves. The IDNB's decisions will be binding. (This section is probably obsolete and should be replaced.) 3.5. Transfer For any transfer of the registry records from one organization to another, the expenses shall be deducted from the performance bond. Any remaining bond will be returned to the registry organization. Security Considerations Dynamic update of DNS by multiple registries requires a robust DNS Security service. This is beyond the scope of this specification. Changes Most of the text of this document is copied verbatim from RFC-1591, with brief extracts from other RFC documents describing specific Internet authorities, in the hope that use of previously published text would speed the resolution of issues. Terminology is consistent with that used in RFC-1591, but some acronyms have been slightly changed. The functions of the "designated manager" (of which there can be only one) have been more clearly distinguished from the functions of "reg- istries" (of which there may be many). A performance bond and fee schedule has been added. References [RFC-1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, Novem- ber 1987. [RFC-1035] Mockapetris, P., "Domain Names - Implementation and Specifi- cation", STD 13, RFC 1035, USC/Information Sciences Insti- tute, November 1987. [RFC-1480] Cooper, A., and J. Postel, "The US Domain", USC/Information Sciences Institute, June 1993. [RFC-1601] [RFC-2028] [IANA-CHARTER] Contacts Comments about this document should be discussed on the namedrop- pers@internic.net mailing list. Questions about this document can also be directed to: William Allen Simpson DayDreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 wsimpson@UMich.edu wsimpson@GreenDragon.com (preferred) bsimpson@MorningStar.com Simpson expires in six months [Page 8]