1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc1591.txt b/doc/rfc/rfc1591.txt
new file mode 100644
index 00000000..89e0a254
--- /dev/null
+++ b/doc/rfc/rfc1591.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                          J. Postel
+Request for Comments: 1591                                           ISI
+Category: Informational                                       March 1994
+
+
+              Domain Name System Structure and Delegation
+
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+1. Introduction
+
+   This memo provides some information on the structure of the names in
+   the Domain Name System (DNS), specifically the top-level domain
+   names; and on the administration of domains.  The Internet Assigned
+   Numbers Authority (IANA) is the overall authority for the IP
+   Addresses, the Domain Names, and many other parameters, used in the
+   Internet.  The day-to-day responsibility for the assignment of IP
+   Addresses, Autonomous System Numbers, and most top and second level
+   Domain Names are handled by the Internet Registry (IR) and regional
+   registries.
+
+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 system is unnamed.  There are a set
+   of what are called "top-level domain names" (TLDs).  These are the
+   generic TLDs (EDU, COM, NET, ORG, GOV, MIL, and INT), and the two
+   letter country codes from ISO-3166.  It is extremely unlikely that
+   any other TLDs will be created.
+
+   Under each TLD may be created a hierarchy of names.  Generally, under
+   the generic TLDs the structure is very flat.  That is, many
+   organizations are registered directly under the TLD, and any further
+   structure is up to the individual organizations.
+
+   In the country TLDs, there is a wide variation in the structure, 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 [1].
+
+
+
+
+Postel                                                          [Page 1]
+
+RFC 1591      Domain Name System Structure and Delegation     March 1994
+
+
+   Each of the generic TLDs 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.  These
+   administrators may further delegate the management of portions of the
+   naming tree.  These administrators are performing a public service on
+   behalf of the Internet community.  Descriptions of the generic
+   domains and the US country domain follow.
+
+   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, that is
+         companies.  This domain has grown very large and there is
+         concern about the administrative load and system performance if
+         the current growth pattern is continued.  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.  Many Universities, colleges, schools,
+         educational service organizations, and educational consortia
+         have registered here.  More recently a decision has been taken
+         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, that is 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 taken to
+         register only agencies of the US Federal government in this
+         domain.  State and local agencies are registered in the country
+
+
+
+Postel                                                          [Page 2]
+
+RFC 1591      Domain Name System Structure and Delegation     March 1994
+
+
+         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
+        on the basis of political geography, that is, a hierarchy of
+        <entity-name>.<locality>.<state-code>.US.  For example,
+        "IBM.Armonk.NY.US".  In addition, branches of the US domain are
+        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.  Append "-dom" to the name of
+   TLD you are 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
+
+   The Internet Assigned Numbers Authority (IANA) is responsible for the
+   overall coordination and management of the Domain Name System (DNS),
+   and especially the delegation of portions of the name space called
+   top-level domains.  Most of these top-level domains are two-letter
+   country codes taken from the ISO standard 3166.
+
+   A central Internet Registry (IR) has been selected and designated to
+   handled the bulk of the day-to-day administration of the Domain Name
+   System.  Applications for new top-level domains (for example, country
+   code domains) are handled by the IR with consultation with 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 the 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 assist in the administration of the DNS, especially
+   in solving problems with a country administration.  Currently, the
+   RIPE NCC is the regional registry for Europe and the APNIC is the
+
+
+
+Postel                                                          [Page 3]
+
+RFC 1591      Domain Name System Structure and Delegation     March 1994
+
+
+   regional registry for the Asia-Pacific region, while the INTERNIC
+   administers the North America region, and 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 is
+   established are described in the following.  Also mentioned are
+   concerns raised when it is necessary to change the delegation of an
+   established domain 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 are relevant when a sub-domain is
+   delegated and in general the principles described here apply
+   recursively to all delegations of the Internet DNS name space.
+
+   The major concern in selecting a designated manager for a domain is
+   that it be able to carry out the necessary responsibilities, and have
+   the ability to do a equitable, just, honest, and competent job.
+
+   1) The key requirement is that for each domain there be a designated
+      manager for supervising that domain's name space.  In the case of
+      top-level domains 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.
+
+      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) These designated authorities are trustees for the delegated
+      domain, and 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.
+
+
+
+
+Postel                                                          [Page 4]
+
+RFC 1591      Domain Name System Structure and Delegation     March 1994
+
+
+      Concerns about "rights" and "ownership" of domains are
+      inappropriate.  It is appropriate to be concerned about
+      "responsibilities" and "service" to the community.
+
+   3) 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 (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) 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 later 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.
+
+
+
+
+Postel                                                          [Page 5]
+
+RFC 1591      Domain Name System Structure and Delegation     March 1994
+
+
+   5) 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) 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 that assure the
+      IANA that the transfer in 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 he is 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.
+
+
+
+
+Postel                                                          [Page 6]
+
+RFC 1591      Domain Name System Structure and Delegation     March 1994
+
+
+      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
+
+   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.
+
+
+
+
+Postel                                                          [Page 7]
+