idnits 2.17.1 draft-simpson-dns-delegation-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1995) is 10390 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC-1601' on line 48 looks like a reference -- Missing reference section? 'RFC-1480' on line 178 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group W A Simpson, Editor 2 Internet Draft Daydreamer 3 expires in six months November 1995 5 Domain Name System Delegation 6 draft-simpson-dns-delegation-00.txt 8 Status of this Memo 10 This document is an independent submission. Comments should be 11 submitted to the namedroppers@internic.net mailing list. 13 Distribution of this memo is unlimited. 15 This document is an Internet-Draft. Internet Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its Areas, 17 and its Working Groups. Note that other groups may also distribute 18 working documents as Internet Drafts. 20 Internet Drafts are draft documents valid for a maximum of six 21 months, and may be updated, replaced, or obsoleted by other documents 22 at any time. It is not appropriate to use Internet Drafts as 23 reference material, or to cite them other than as a ``working draft'' 24 or ``work in progress.'' 26 To learn the current status of any Internet-Draft, please check the 27 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 28 Directories on: 30 ftp.is.co.za (Africa) 31 nic.nordu.net (Europe) 32 ds.internic.net (US East Coast) 33 ftp.isi.edu (US West Coast) 34 munnari.oz.au (Pacific Rim) 36 Abstract 38 This document provides information on the organizational structure of 39 the Domain Name System (DNS), specifically the top-level domain 40 names. 42 This document is a rewrite and update of RFC-1591. 44 1. Introduction 46 The Internet Activities Board (IAB), also known as the Internet 47 Architecture Board, is responsible for the coordination of Internet 48 Activities [RFC-1601]. The IAB is responsible for editorial 49 management and publication of the Request for Comments (RFC) document 50 series, and for administration of the various Internet assigned 51 numbers. 53 The IAB has designated an Internet Assigned Numbers Authority (IANA) 54 to coordinate the registration of Internet protocol numbers, the top 55 level Domain Names, and many other parameters used in the Internet. 56 IANA discretion in the execution of these duties is explicitly 57 limited to technical and engineering considerations. 59 The IAB has designated a separate Internet Secretariate to coordinate 60 meetings, publish minutes and drafts, and administer funds related to 61 the coordination of the Internet. 63 2. The Top Level Structure of the Domain Names 65 In the Domain Name System (DNS) naming of computers, there is a 66 hierarchy of names. The root of the system is unnamed, and is 67 usually represented by a trailing dot ".", as at the end of a 68 sentence. 70 The small set of names which are registered at the root are called 71 "primary-level domain names" (1LDN). Under each 1LDN may be created 72 a hierarchy of names, sometimes called "secondary-level domain names" 73 (2LDN), "tertiary-level domain names" (3LDN), and so forth. 75 2.1. Root 77 The Internet Assigned Numbers Authority (IANA) has principle 78 responsibility for maintaining the root of the Domain Name System 79 (DNS). IANA is responsible for oversight of both operation and 80 security of the DNS root. IANA has sole authority to create or 81 remove a 1LDN delegation, or transfer delegation to another party 82 which meets the established criterion. 84 To this end, the number of primary-level domain names registered at 85 the root is deliberately kept within humanly managable limits. Only 86 a few hundred root entries are anticipated. 88 Day-to-day database storage and transaction activity may be 89 distributed to other organizations. However, it is not anticipated 90 that the root will be updated by external registration authorities. 92 2.1.1. Servers 94 The DNS root is maintained and distributed to servers from IANA. 95 These servers must be continuously available world-wide, and enjoy 96 multiply-connected network topological distribution. 98 Technical considerations restrict the number of root servers. The 99 DNS UDP datagrams can support about 16 such servers. The servers are 100 currently in the domain root-servers.net. 102 Another technical consideration is the load placed on the servers. 103 To promote cached operation, primary root servers should refuse DNS 104 requests from systems not named as Name Servers (NS) in their 105 delegation. 107 Operation of primary root servers is a voluntary service to the 108 Internet community. When there are more than enough volunteers, IANA 109 will select sites that are well distributed topologically. 110 Consideration will also be given to technical considerations such as 111 proximity to Internet exchanges, and demonstrated capability to 112 operate such servers. 114 2.1.2. Establishment 116 A new 1LDN is usually created and its management delegated to a 117 "designated manager" all at once. 119 Root domain delegations must demonstrate a significant world-wide 120 constituency, and must serve a broad spectrum of the community. Each 121 1LDN should have at least 6 servers distributed over multiple 122 continents. 124 Delegations must provide a Charter with clear membership guidelines. 125 Each 1LDN must be open to all qualifying applicants on a non- 126 discriminatory basis. 128 Requests for new or changed 1LDN delegation records should be 129 submitted to root-delegation@iana.net. The proposed charter will be 130 posted as an internet-draft, and a 28 day Last Call will be issued by 131 the Internet Secretariate. IANA will make its decision based on the 132 results of the Last Call. Successful applications will be published 133 by the RFC-Editor. 135 2.1.3. Termination 137 Requests for termination of 1LDN delegation records should be 138 submitted to root-delegation@iana.net. A 28 day Last Call will be 139 issued by the Internet Secretariate. IANA will make its decision 140 based on the results of the Last Call. 142 2.2. One Letter 1LDN 144 Currently, there are no single alphabetic, numeric, or symbolic 145 letter domains. 147 Operation of single letter alphabetic domains will be distributed by 148 lottery. Each year 9 alphabetic domains will be randomly paired with 149 volunteer registries (the third year only 8 will be distributed). No 150 registry may operate more than one such domain. 152 Details are described in a separate charter. 154 2.2.1. Servers 156 These domain servers are operated on a voluntary basis. Usually, the 157 primary server for a one letter domain is co-located with one of the 158 root-servers. 160 2.3. Two Letter 1LDN 162 Most of the first level domains are two-letter country codes taken 163 from the ISO standard 3166. Additional two letter codes are 164 maintained on an historical basis. 166 The country code domains (for example, FR, NL, KR, US) are each 167 organized by an administrator for that country. At their discretion, 168 these administrators may further delegate the management of portions 169 of their naming tree. There is a wide variation in the name 170 structure. In some countries the structure is very flat. In others 171 there is substantial structural organization. 173 In some country domains the second levels are generic categories 174 (such as AC, CO, GO, and RE), in others they are based on political 175 geography, and in still others organization names are listed directly 176 under the country code. 178 The organization for the US country domain is described in [RFC- 179 1480]. 181 2.3.1. Servers 183 These domain servers are operated on a voluntary basis by the country 184 administrators, performing a public service on behalf of the Internet 185 community. 187 2.4. Three Letter and Longer 1LDNs 189 Longer 1LDNs are available for domains that cross geopolitical 190 boundaries, that have not been recognized by its native country, or 191 that choose for some other reason to be independent. 193 Each of these 1LDNs was created for a general category of 194 organizations. Some are network related (Net and Int), some are 195 historic (ARPA, Gov, Mil), some are commercial (Com, Corp, Inc, Ltd), 196 and others are organizational (Edu, Org) 198 Generally, under the generic 1LDNs the structure is very flat. That 199 is, many organizations are registered directly under the 1LDN, and 200 any further structure is up to the individual organizations. 202 Unfortunately, this has engendered significant administrative and 203 engineering problems. In particular, administrative, competitive, 204 language and naming difficulties. 206 There have been serious scaling problems. Certain popular 1LDNs have 207 required tens of thousands of updates per month at a single registry, 208 rather than having the updates distributed throughout the DNS across 209 many registries. 211 These problems are ameliorated by separating the server and registry 212 functions. With the advent of DNS Security and Dynamic Update 213 capability, it is recently possible to allow multiple registries to 214 update the same 1LDN servers. 216 2.4.1. Servers 218 These domain servers are operated on a voluntary basis. When there 219 are more than enough volunteers, IANA will select sites that are well 220 distributed topologically. Consideration will also be given to 221 technical considerations such as proximity to Internet exchanges, and 222 demonstrated capability to operate such servers. Usually, these 223 servers are co-located with some of the root-servers. 225 Security Considerations 227 Separating delegation of domain servers from sub-domain registration 228 requires a robust DNS Security service. This is beyond the scope of 229 this specification. 231 Author's Address 233 Questions about this memo can also be directed to: 235 William Allen Simpson 236 Daydreamer 237 Computer Systems Consulting Services 238 1384 Fontaine 239 Madison Heights, Michigan 48071 241 Bill.Simpson@um.cc.umich.edu 242 bsimpson@MorningStar.com (prefered) 243 Table of Contents 245 1. Introduction .......................................... 1 247 2. The Top Level Structure of the Domain Names ........... 1 248 2.1 Root ............................................ 1 249 2.1.1 Servers ......................................... 2 250 2.1.2 Establishment ................................... 2 251 2.1.3 Termination ..................................... 3 252 2.2 One Letter 1LDN ................................. 3 253 2.2.1 Servers ......................................... 3 254 2.3 Two Letter 1LDN ................................. 3 255 2.3.1 Servers ......................................... 4 256 2.4 Three Letter and Longer 1LDNs ................... 4 257 2.4.1 Servers ......................................... 5 259 SECURITY CONSIDERATIONS ...................................... 5 261 AUTHOR'S ADDRESS ............................................. 5