Network Working Group W. Simpson, Editor Internet Draft DayDreamer expires in six months January 1996 Domain Name System Delegation draft-simpson-dns-delegation-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 organizational structure of the Domain Name System (DNS), specifically the primary-level domain names. 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. Unfortunately, over time this has encountered significant administra- tive, competitive, engineering, language and naming difficulties. There have been serious scaling problems. Certain popular domains have required thousands of updates per month at a single registry, rather than having the updates distributed throughout the DNS heirar- chy across many registries. New primary-level domain names have not been created in a timely manner. These problems may be ameliorated by separating the delegation and registration functions. This document details the delegation of 1LDNs. Registration services for additional levels of heirarchy are described in a companion document. 2. Root The Internet Assigned Numbers Authority (IANA) has principle respon- sibility for maintaining the root of the Domain Name System (DNS). IANA is responsible for oversight of both operation and security of the DNS root. IANA has sole authority to create or remove a primary- level domain name (1LDN) delegation, or transfer delegation to another designated manager that meets the established criteria. To this end, the number of 1LDNs registered at the root is deliber- ately kept within humanly managable limits. Only a few hundred root entries are anticipated. Day-to-day database storage and transaction activity may be dis- tributed to other organizations. However, it is not anticipated that the root will be updated by multiple external registration authori- ties. 2.1. Servers The DNS root is maintained and distributed to secondary servers from a primary master root server designated by IANA. These secondary root servers must be continuously available world-wide, and enjoy multiply-connected network topological distribution. Technical considerations restrict the number of root servers. The DNS UDP datagrams can support about 16 such servers. These servers are currently in the domain root-servers.net. Another technical consideration is the load placed on the servers. To promote cached operation, root servers should refuse DNS requests from systems not named as Name Servers (NS) in their delegation glue records. Operation of root servers is a voluntary service to the Internet com- munity. When there are more than enough volunteers, IANA will select sites that are well distributed topologically. Consideration will also be given to operational considerations such as proximity to regional Internet exchanges, and demonstrated capability to operate such servers. 2.2. 1LDN Establishment Requests for new or changed 1LDN delegation records should be submit- ted to root-delegation@iana.net. A proposed Charter will be posted as an internet-draft, and a 28 day Last Call will be issued by the Internet Secretariat. IANA will make its decision based on the results of the Last Call. Each Charter must: 1) contain a clear statement of purpose. 2) specify domain membership qualifications. 3) be open to all qualifying applicants on a non-discriminatory basis. 4) demonstrate a significant world-wide constituency. 5) serve a broad spectrum of the community. 6) provide for establishment and termination of 2LDNs. 7) provide naming guidelines and procedures for resolving name con- flicts. 8) indicate a "designated manager" and repository for the primary master zone server. 9) indicate support of at least 6 secondary servers distributed over multiple continents. Successful Charters will be published by the RFC-Editor. 2.3. 1LDN Termination Requests for termination of 1LDN delegation records should be submit- ted to root-delegation@iana.net. A 28 day Last Call will be issued by the Internet Secretariat. IANA will make its decision based on the results of the Last Call. 3. One Letter 1LDN Currently, there are no single alphabetic, numeric, or symbolic let- ter domains. One suggestion under consideration is operation of single letter alphabetic domains distributed by lottery. Each year 9 alphabetic domains will be randomly paired with volunteer designated managers (the third year only 8 will be distributed). No registry may operate more than one such domain. Details will be described in a separate charter. 3.1. Servers These domain servers are intended to be operated on a voluntary basis. 4. Two Letter 1LDN Most of the first level domains are two-letter country codes taken from the ISO standard 3166. Additional two letter codes are main- tained on an historical basis. The selection of the ISO 3166 list as a basis for country code domain names was made with the knowledge that ISO has a procedure for deter- mining which entities should be and should not be on that list. The IANA defers to ISO on the country code names, and these domain deci- sions are not appealable to the IAB. The country code domains (for example, FR, NL, KR, US) are each orga- nized by an administrator for that country. At their discretion, these administrators may further delegate the management of portions of their naming tree. There is a wide variation in the name struc- ture. In some countries the structure is very flat. In others there is substantial structural organization. In some country domains the second levels are generic categories (such as AC, CO, GO, and RE), in others they are based on political geography, and in still others organization names are listed directly under the country code. The organization for the US country domain is described in [RFC-1480]. 4.1. Servers These domain servers are operated on a voluntary basis by the named country administrators, performing a public service on behalf of the Internet community. 5. Three Letter and Longer 1LDNs Longer 1LDNs are available for domains that cross geo-political boundaries, that have not been recognized by a native country, or that choose for some other reason to be independent. These 1LDNs are sometimes called International Top Level Domains (ITLD). Each of these 1LDNs is created for a general category of organiza- tions. Some are network related (Net, Int), or historic US funding institutions (ARPA, Gov, Mil), or commercial (Com, Corp, Inc, Ltd), or related by social purpose (Edu), or are a category unto themselves (Org). Generally, under the generic 1LDNs the structure is very flat. That is, many organizations are registered directly under the 1LDN, and any further structure is up to the individual organizations. 5.1. Servers These domain servers are operated on a voluntary basis. When there are more than enough volunteers, IANA will select sites that are well distributed topologically. Consideration will also be given to tech- nical considerations such as proximity to Internet exchanges, and demonstrated capability to operate such servers. Usually, these servers are co-located with some of the root-servers. A. Example Charter for Net. This primary-level domain is intended for the computers of Internet Service Providers, Internet Registries, Internet Exchanges, and net- works supporting Internet research and development. Membership is limited to registration of NIC and NOC administrative hosts, internetwork routers, and other experimental network equip- ment. For these operational network members, a SOA responsible con- tact is expected to respond within 48 hours. Registration of 2LDNs is open to all qualifying applicants on a first-come first-served basis. The registration of a name does not correspond to any TradeMark or ServiceMark status. Member names are expected to correspond to one or more assigned ranges of IP addresses. Only one domain name (in the Net 1LDN) may be assigned to each such range. Customers of service providers will have domain names of their own (not in the Net 1LDN). The same or similar name should not be registered by the same organi- zation in any other zone of the DNS (such as under a country 1LDN). In any dispute as to the registration of a particular 2LDN, the reg- istration authority shall have no role or responsibility, other than to provide the contact information for all parties. The designated manager shall have final authority to resolve such conflicts; with administrative appeal to the IANA, followed by the IAB. Whenever it is determined that an error in registration has occurred (such as ineligibility, change in qualification status, SOA contact does not respond promptly, or multiple registrations), the 2LDN will be revoked 28 days after sending notification to the SOA specified contact. The same 2LDN will not be assigned to any other qualified applicant for an additional 91 days after any revocation. The designated manager of the repository for the primary master zone server shall be the Routing Arbiter organization. Because of the critical nature and usage of the Net 1LDN, secondary servers will be co-located with every DNS root-server. Security Considerations Separating delegation of primary-level domain names from other zone registration procedures facilitates a robust DNS Security service. The distribution and verification of keys and signatures can be care- fully constrained to limit exposure to malicious interference, to establish a well-known trusted root certificate authority, and to serve as a backstop in resolving credential loops. 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. Internally inconsistent language, It is extremely unlikely that any other TLDs will be created. ... A new top-level domain is usually created and its management delegated to a "designated manager".... has been replaced with new language describing the chartering, estab- lishment and termination of 1LDNs. Historic 1LDNs have been removed, pending creation of specific char- ters. The Net 1LDN charter is included as an example. Specific contentious issues, such as TradeMarks, are dealt with sepa- rately in each chartered 1LDN. Language detailing "designated managers" and "registries" has been removed to a separate document. Some ideas (such as a lottery) have been included from drafts of other persons. Comments on an earlier draft (circa late 1995) have been incorpo- rated, but this draft does not yet include more recent ideas. 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