Network Working Group W A Simpson, Editor Internet Draft Daydreamer expires in six months November 1995 Domain Name System Delegation draft-simpson-dns-delegation-00.txt Status of this Memo This document is an independent submission. Comments should be submitted to the namedroppers@internic.net mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft. 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 obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference 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 top-level domain names. This document is a rewrite and update of RFC-1591. Simpson expires in six months [Page i] DRAFT ICMP Delegation November 1995 1. Introduction The Internet Activities Board (IAB), also known as the Internet Architecture Board, is responsible for the coordination of Internet Activities [RFC-1601]. The IAB is responsible for editorial management and publication of the Request for Comments (RFC) document series, and for administration 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 discretion in the execution of these duties is explicitly limited to technical and engineering considerations. The IAB has designated a separate Internet Secretariate to coordinate meetings, publish minutes and drafts, and administer funds related to the coordination of the Internet. 2. The Top Level Structure of the Domain Names In the Domain Name System (DNS) naming of computers, there is a hierarchy of names. The root of the system is unnamed, and is usually represented by a trailing dot ".", as at the end of a sentence. The small set of names which are registered 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. 2.1. Root The Internet Assigned Numbers Authority (IANA) has principle responsibility 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 1LDN delegation, or transfer delegation to another party which meets the established criterion. To this end, the number of primary-level domain names registered at the root is deliberately kept within humanly managable limits. Only a few hundred root entries are anticipated. Simpson expires in six months [Page 1] DRAFT ICMP Delegation November 1995 Day-to-day database storage and transaction activity may be distributed to other organizations. However, it is not anticipated that the root will be updated by external registration authorities. 2.1.1. Servers The DNS root is maintained and distributed to servers from IANA. These 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. The servers are currently in the domain root-servers.net. Another technical consideration is the load placed on the servers. To promote cached operation, primary root servers should refuse DNS requests from systems not named as Name Servers (NS) in their delegation. Operation of primary root servers is a voluntary service to the Internet community. When there are more than enough volunteers, IANA will select sites that are well distributed topologically. Consideration will also be given to technical considerations such as proximity to Internet exchanges, and demonstrated capability to operate such servers. 2.1.2. Establishment A new 1LDN is usually created and its management delegated to a "designated manager" all at once. Root domain delegations must demonstrate a significant world-wide constituency, and must serve a broad spectrum of the community. Each 1LDN should have at least 6 servers distributed over multiple continents. Delegations must provide a Charter with clear membership guidelines. Each 1LDN must be open to all qualifying applicants on a non- discriminatory basis. Requests for new or changed 1LDN delegation records should be submitted to root-delegation@iana.net. The proposed charter will be posted as an internet-draft, and a 28 day Last Call will be issued by the Internet Secretariate. IANA will make its decision based on the Simpson expires in six months [Page 2] DRAFT ICMP Delegation November 1995 results of the Last Call. Successful applications will be published by the RFC-Editor. 2.1.3. Termination Requests for termination of 1LDN delegation records should be submitted to root-delegation@iana.net. A 28 day Last Call will be issued by the Internet Secretariate. IANA will make its decision based on the results of the Last Call. 2.2. One Letter 1LDN Currently, there are no single alphabetic, numeric, or symbolic letter domains. Operation of single letter alphabetic domains will be distributed by lottery. Each year 9 alphabetic domains will be randomly paired with volunteer registries (the third year only 8 will be distributed). No registry may operate more than one such domain. Details are described in a separate charter. 2.2.1. Servers These domain servers are operated on a voluntary basis. Usually, the primary server for a one letter domain is co-located with one of the root-servers. 2.3. 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 maintained on an historical basis. The country code domains (for example, FR, NL, KR, US) are each organized 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 structure. In some countries the structure is very flat. In others there is substantial structural organization. Simpson expires in six months [Page 3] DRAFT ICMP Delegation November 1995 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]. 2.3.1. Servers These domain servers are operated on a voluntary basis by the country administrators, performing a public service on behalf of the Internet community. 2.4. Three Letter and Longer 1LDNs Longer 1LDNs are available for domains that cross geopolitical boundaries, that have not been recognized by its native country, or that choose for some other reason to be independent. Each of these 1LDNs was created for a general category of organizations. Some are network related (Net and Int), some are historic (ARPA, Gov, Mil), some are commercial (Com, Corp, Inc, Ltd), and others are organizational (Edu, 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. Unfortunately, this has engendered significant administrative and engineering problems. In particular, administrative, competitive, language and naming difficulties. There have been serious scaling problems. Certain popular 1LDNs have required tens of thousands of updates per month at a single registry, rather than having the updates distributed throughout the DNS across many registries. These problems are ameliorated by separating the server and registry functions. With the advent of DNS Security and Dynamic Update capability, it is recently possible to allow multiple registries to update the same 1LDN servers. Simpson expires in six months [Page 4] DRAFT ICMP Delegation November 1995 2.4.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 technical 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. Security Considerations Separating delegation of domain servers from sub-domain registration requires a robust DNS Security service. This is beyond the scope of this specification. Author's Address Questions about this memo can also be directed to: William Allen Simpson Daydreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 Bill.Simpson@um.cc.umich.edu bsimpson@MorningStar.com (prefered) Simpson expires in six months [Page 5] DRAFT ICMP Delegation November 1995 Table of Contents 1. Introduction .......................................... 1 2. The Top Level Structure of the Domain Names ........... 1 2.1 Root ............................................ 1 2.1.1 Servers ......................................... 2 2.1.2 Establishment ................................... 2 2.1.3 Termination ..................................... 3 2.2 One Letter 1LDN ................................. 3 2.2.1 Servers ......................................... 3 2.3 Two Letter 1LDN ................................. 3 2.3.1 Servers ......................................... 4 2.4 Three Letter and Longer 1LDNs ................... 4 2.4.1 Servers ......................................... 5 SECURITY CONSIDERATIONS ...................................... 5 AUTHOR'S ADDRESS ............................................. 5