RFC 1591

RFC 1591: Domain Name System Structure and Delegation 🎀

Okay bestie, let's get the title block out of the way first ✨

• RFC number: 1591
• Title: Domain Name System Structure and Delegation
• Working group: Network Working Group
• Author: J. Postel, ISI
• Category: Informational
• Date: March 1994
• Obsoletes / Updates: nothing listed, so it doesn't replace or change any other RFC 💅

Status of this Memo 🌸

This memo provides information for the Internet community. It does not specify an Internet standard of any kind, so it's more like a helpful explainer than a rulebook 🧚 Distribution of this memo is unlimited, so share it with everyone who's curious 🫶

1. Introduction 💖

Okay so this memo is all about how names work in the Domain Name System (DNS) 🦋 It focuses on the top-level domain names, and it also explains how domains get administered. Basically, it's the tea on who's in charge of what.

The Internet Assigned Numbers Authority (IANA) is the overall authority for IP Addresses, Domain Names, and a bunch of other parameters used across the Internet 👑 Day to day, the assigning gets handled by the Internet Registry (IR) and the regional registries. That covers IP Addresses, Autonomous System Numbers, and most top and second level Domain Names 💅

2. The Top Level Structure of the Domain Names 🦋

Here's the vibe. DNS naming for computers is a hierarchy of names, and the root of the system is unnamed 🌈 At the very top, there's a set of what are called "top-level domain names" (TLDs). These are the generic TLDs (EDU, COM, NET, ORG, GOV, MIL, and INT) plus the two-letter country codes from ISO-3166 ✨ It is extremely unlikely that any other TLDs will be created, so this list is pretty much the whole squad 💜

Under each TLD, a hierarchy of names can be created. Generally, the generic TLDs are very flat 🍓 That means lots of organizations register directly under the TLD, and any further structure is up to the individual organizations 🎀

The country TLDs are a whole different story because there's wide variation. Some countries are super flat, and others have a ton of structure 🔥 Some country domains use generic categories at the second level (such as AC, CO, GO, and RE). Others base their second levels on political geography, and some just list organization names directly under the country code. The organization for the US country domain is described in RFC 1480 [1] 🌸

Each generic TLD was created for a general category of organizations 💅 The country code domains (for example, FR, NL, KR, US) are each organized by an administrator for that country. Those administrators can further delegate the management of portions of the naming tree 🫶 They're doing a public service on behalf of the Internet community, which is honestly iconic of them 👑 Descriptions of the generic domains and the US country domain follow below ✨

Of these generic domains, five are international in nature, and two are restricted to use by entities in the United States 🌍

World Wide Generic Domains 🌐

• COM 💼 This domain is intended for commercial entities, meaning companies. It has grown very large, and there's concern about the administrative load and system performance if the current growth pattern keeps going. Consideration is being taken to subdivide the COM domain and only allow future commercial registrations in the subdomains 😭
• EDU 🎓 This domain was originally intended for all educational institutions. Lots of Universities, colleges, schools, educational service organizations, and educational consortia have registered here. More recently, a decision has been made to limit further registrations to 4 year colleges and universities. Schools and 2-year colleges will be registered in the country domains (see US Domain, especially K12 and CC, below) 📚
• NET 🛜 This domain is intended to hold only the computers of network providers, meaning the NIC and NOC computers, the administrative computers, and the network node computers. The customers of the network provider would have domain names of their own (not in the NET TLD) ✨
• ORG 🧺 This domain is intended as the miscellaneous TLD for organizations that didn't fit anywhere else. Some non-government organizations may fit here 🦋
• INT 🌏 This domain is for organizations established by international treaties, or international databases 🧚

United States Only Generic Domains 🇺🇸

• GOV 🏛️ This domain was originally intended for any kind of government office or agency. More recently, a decision was made to register only agencies of the US Federal government in this domain. State and local agencies are registered in the country domains (see US Domain, below) 🙈
• MIL 🎖️ This domain is used by the US military 🫡

Example country code Domain 🗺️

• US 🗽 As an example of a country domain, the US domain provides for the registration of all kinds of entities in the United States, based on political geography. It's a hierarchy of <entity-name>.<locality>.<state-code>.US. For example, IBM.Armonk.NY.US 💅 Branches of the US domain are also provided within each state for schools (K12), community colleges (CC), technical schools (TEC), state government agencies (STATE), councils of governments (COG), libraries (LIB), museums (MUS), and several other generic types of entities (see RFC 1480 for details [1]) 🌈

To find a contact for a TLD, use the "whois" program to access the database on the host rs.internic.net 🔍 Just append "-dom" to the name of the TLD you're interested in. For example:

whois -h rs.internic.net us-dom

or

whois -h rs.internic.net edu-dom

3. The Administration of Delegated Domains ✨

okay so the IANA (Internet Assigned Numbers Authority) is the main coordinator of the whole Domain Name System 💅, especially when it comes to handing out the chunks of name space called top-level domains 👑. Most of those top-level domains are two-letter country codes taken from ISO standard 3166 🌍.

A central Internet Registry (IR) got picked to handle the bulk of the day-to-day DNS admin 🗂️. New top-level domains (country code domains, for example) are handled by the IR, but it consults the IANA 🫶. The central IR is INTERNIC.NET. Second level domains in COM, EDU, ORG, NET, and GOV are registered by the Internet Registry at the InterNIC 📝. The second level domains in MIL are registered by the DDN registry at NIC.DDN.MIL 🪖. Second level names in INT are registered by the PVM at ISI.EDU 🌸.

While all requests for new top-level domains MUST be sent to the Internic (at hostmaster@internic.net), the regional registries are often enlisted to help run the DNS, especially when there's a problem with a country administration 🤝. Right now the RIPE NCC is the regional registry for Europe 🇪🇺, APNIC is the one for the Asia-Pacific region 🌏, and the INTERNIC handles North America plus all the as yet undelegated regions 🧭.

The contact mailboxes for these regional registries are:

         INTERNIC        hostmaster@internic.net
         APNIC           hostmaster@apnic.net
         RIPE NCC        ncc@ripe.net

The policy concerns involved when a new top-level domain gets established are coming up next 📋. We'll also cover what's up when an established domain's delegation needs to move from one party to another 🔄.

A new top-level domain is usually created and its management delegated to a "designated manager" all at once 🎀.

Most of these same concerns apply when a sub-domain gets delegated, and the principles here generally apply recursively to all delegations of the Internet DNS name space 🪆.

The major concern when picking a designated manager is that they can carry out the necessary responsibilities and do an equitable, just, honest, and competent job 💜.

1. The key requirement 🔑 is that every domain has a designated manager supervising that domain's name space. For top-level domains that are country codes, that means there's a manager who supervises the domain names and runs the domain name system in that country.

The manager MUST, of course, be on the Internet 🌐. There MUST be Internet Protocol (IP) connectivity to the nameservers and email connectivity to the management and staff of the manager 📡.

There MUST be an administrative contact and a technical contact for each domain. For top-level domains that are country codes, at least the administrative contact MUST reside in the country involved 🏳️.

2. Trustees, not owners 🫂. These designated authorities are trustees for the delegated domain, and they have a duty to serve the community.

The designated manager is the trustee of the top-level domain for both the nation (in the case of a country code) and the global Internet community.

Concerns about "rights" and "ownership" of domains are inappropriate 🙅‍♀️. It is appropriate to be concerned about "responsibilities" and "service" to the community 💖.

3. Equity for everyone ⚖️. The designated manager MUST be equitable to all groups in the domain that request domain names.

This means the same rules apply 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. There can be no requirement that a particular mail system (or other application), protocol, or product be used 🚫.

There are no requirements on subdomains of top-level domains beyond the requirements on higher-level domains themselves. That is, the requirements in this memo are applied recursively. In particular, all subdomains SHALL be allowed to operate their own domain name servers, providing in them whatever information the subdomain manager sees fit (as long as it is true and correct) 🧚.

4. Interested parties get a say 🗳️. Significantly interested parties in the domain SHOULD agree that the designated manager is the appropriate party.

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. However, it is also appropriate for interested parties to have some voice in selecting the designated manager.

There are two cases where the IANA and the central IR MAY establish a new top-level domain and delegate 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 country. The latter case sometimes arises when a party outside a country is trying to be helpful in getting networking started in a country -- this is sometimes called a "proxy" DNS service 🌱.

The Internet DNS Names Review Board (IDNB), a committee established by the IANA, will act as a review panel for cases in which the parties can not reach agreement among themselves. The IDNB's decisions will be binding 🏛️.

5. Running the DNS like a pro 🛠️. 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 subdomains, and operating nameservers MUST be done with technical competence. This includes keeping the central IR (in the case of top-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 IP connectivity to the Internet and can be easily checked for operational status and database accuracy by the IR and the IANA.

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 🔁.

6. Handovers 🤝. For any transfer of the designated manager trusteeship from one organization to another, the higher-level domain manager (the IANA in the case of top-level domains) MUST receive communications from both the old organization and the new organization. Those communications need to assure the IANA that the transfer is mutually agreed, and that the new organization understands its responsibilities.

It is also very helpful for the IANA to receive communications from other parties that may be concerned or affected by the transfer 💌.

---

4. Rights to Names 🎀

1) Names and Trademarks

In case of a dispute between domain name registrants as to the rights to a particular name, the registration authority SHALL have no role or responsibility other than to provide the contact information to both parties 📇.

The registration of a domain name does not have any Trademark status. It is up to the requestor to be sure they are not violating anyone else's Trademark 🙅.

2) Country Codes

The IANA is not in the business of deciding what is and what is not a country 🌎.

The selection of the ISO 3166 list as a basis for country code top-level domain names was made with the knowledge that ISO has a procedure for determining which entities should be and should not be on that list 📜.

5. Security Considerations 🚨

Okay bestie, this one is SERIOUS 😭. Security issues are not discussed in this memo.

6. Acknowledgements 🫶

Many people have made comments on draft version of these descriptions and procedures. Steve Goldstein and John Klensin have been particularly helpful 💜.

7. Author's Address 📮

   Jon Postel
   USC/Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA  90292

   Phone: 310-822-1511
   Fax:   310-823-6714
   EMail: Postel@ISI.EDU

---

7. References 📚

• [1] Cooper, A., and J. Postel, "The US Domain", RFC 1480, USC/Information Sciences Institute, June 1993.
• [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute, July 1992.
• [3] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, November 1987.
• [4] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.
• [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC 974, CSNET CIC BBN, January 1986.
• [7] Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, Internet Engineering Task Force, October 1989.