doc: Add RFC documents

1 files changed, 1739 insertions, 0 deletions

diff --git a/doc/rfc/rfc1386.txt b/doc/rfc/rfc1386.txt
new file mode 100644
index 0000000..fa3d18f
--- /dev/null
+++ b/doc/rfc/rfc1386.txt
@@ -0,0 +1,1739 @@
+
+
+
+
+
+
+Network Working Group                                          A. Cooper
+Request for Comments: 1386                                     J. Postel
+                                                           December 1992
+                             The US Domain
+
+Status of this Memo
+
+   This memo provides information for the Internet community. It does
+   not specify an Internet standard. Distribution of this memo is
+   unlimited.
+
+Table of Contents
+
+   1.  Introduction ................................................  2
+       1.1  The Internet Domain Name System.........................  2
+       1.2  Top Level Domains.......................................  3
+       1.3  The US Domain ..........................................  4
+   2.  Naming Structure ............................................  4
+       2.1  State Codes ............................................  5
+       2.2  City Codes or Locality Names............................  5
+       2.3  Examples of Names.......................................  5
+   3.  Registration ................................................  8
+       3.1  Requirements ...........................................  8
+       3.2  Direct Entries .........................................  9
+       3.2.1   UUCP Hosts ..........................................  9
+       3.2.2   Non-IP Hosts ........................................ 10
+       3.3  Delegated Subdomains ................................... 12
+       3.3.1   Schools ............................................. 12
+       3.3.2   State Agencies ...................................... 14
+       3.3.3   Federal Agencies .................................... 14
+       3.3.4   Delegation Requirement............................... 14
+       3.3.5   Delegation Procedures ............................... 15
+       3.3.6   Subdomain Contacts................................... 18
+   4.  Database Information......................................... 19
+       4.1  Name Servers ........................................... 19
+       4.2  Zone files ............................................. 20
+       4.3  Resource Records ....................................... 21
+       4.3.1   A Records ........................................... 22
+       4.3.2   CNAME Records ....................................... 22
+       4.3.3   MX Records .......................................... 22
+       4.3.4   HINFO Records ....................................... 23
+       4.3.5   PTR Records ......................................... 23
+       4.4  Wildcards .............................................. 23
+   5.  References .................................................. 24
+   6.  Security Considerations ..................................... 25
+   7.  Author's Address ............................................ 25
+   Appendix-I:  US Domain Names BNF................................. 26
+   Appendix-II: US Domain Questionnaire for Host Entry.............. 28
+
+
+
+Cooper & Postel                                                 [Page 1]
+
+RFC 1386                     The US Domain                 December 1992
+
+
+1. INTRODUCTION
+
+   1.1 The Internet Domain Name System
+
+   The Domain Name System (DNS) provides for the translation between
+   host names and addresses.  Within the Internet, this means
+   translating from a name such as "venera.isi.edu", to an IP address
+   such as "128.9.0.32".  The DNS is a set of protocols and databases.
+   The protocols define the syntax and semantics for a query language to
+   ask questions about information located by DNS-style names.  The
+   databases are distributed and replicated.  There is no dependence on
+   a single central server, and each part of the database is provided in
+   at least two servers.
+
+   The assignment of the 32-bit IP addresses is a separate activity.  IP
+   addresses are assigned by the Network Information Center
+   (Hostmaster@NIC.DDN.MIL).
+
+   In addition to translating names to addresses for hosts that are on
+   the Internet, the DNS provides for registering DNS-style names for
+   other hosts reachable (via electronic mail) through gateways or mail
+   relays.  The records for such name registration point to an Internet
+   host (one with an IP address) that acts as a mail forwarder for the
+   registered host.  For example, the host "bah.rochester.ny.us" is
+   registered in the DNS with a pointer to the mail relay
+   "relay1.uu.net".  This type of pointer is called an MX record.
+
+   This gives electronic mail users a uniform mail addressing syntax and
+   avoids making users aware of the underlying network boundaries.
+
+   The reason for the development of the domain system was growth in the
+   Internet.  The host name to address mappings were maintained by the
+   Network Information Center (NIC) in a single file, called HOSTS.TXT,
+   which was FTPed by all the hosts on the Internet.  The network
+   population was changing in character.  The timeshared hosts that made
+   up the original ARPANET were being replaced with local networks of
+   workstations.  Local organizations were administering their own names
+   and addresses, but had to wait for the NIC to make changes in
+   HOSTS.TXT to make the changes visible to the Internet at large.
+   Organizations also wanted some local structure on the name space.
+   The applications on the Internet were getting more sophisticated and
+   creating a need for general purpose name service.  The idea of a
+   hierarchical name space, with the hierarchy roughly corresponding to
+   organizational structure, and names using "." as the character to
+   mark the boundary between hierarcy levels.  A design using a
+   distributed database and generalized resources was implemented.
+
+   The domain system provides standard formats for resource data,
+
+
+
+Cooper & Postel                                                 [Page 2]
+
+RFC 1386                     The US Domain                 December 1992
+
+
+   standard methods for querying the database, and standard methods for
+   name servers to refresh local data from other name servers.
+
+   1.2  Top-Level Domains
+
+   The top-level domains in the DNS are EDU, COM, GOV, MIL, ORG, INT,
+   and NET, and all the 2-letter country codes from the list of
+   countries in ISO-3166.
+
+   Even though the intention was that any educational institution any
+   where in the world could be registered under the EDU domain, in
+   practice it has turned out with few exceptions only those in the
+   United States have registered under EDU, similiary with COM (for
+   commercial). In other countries, everything is registered under the
+   2-letter country code, often with some subdivision.  For example, in
+   Korea (KR) the second level names are AC for academic community, CO
+   for commercial, GO for government, and RE for research.  However each
+   country may go it's own way about organizing its domain, and many
+   have.
+
+   Their are no plans of putting all of the organizational domains .EDU
+    .GOV .COM etc., under .US.
+
+   However, there are some states registered in the .GOV domain (11 by 2
+   letter code), and 3 by full names)
+
+           ca.gov          la.gov          ohio.gov        va.gov
+           co.gov          md.gov          or.gov          wa.gov
+           hawaii.gov      nc.gov          sc.gov
+           ia.gov          ny.gov          texas.gov
+
+   Other names sometimes appear as top-level domain names.  Some people
+   have made up names in the DNS style without coordinating or
+   registering  with the DNS management.  Some names that typically
+   appear are ".BITNET", ".UUCP", and two-letter codes for continents,
+   such as ".NA" for North America (this conflicts with the official
+   Internet code for Namibia).
+
+   For example, the DNS style name "KA7EEJ.CO.USA.NA" is used in the
+   amateur radio network.  These addresses are never supposed to show up
+   on the Internet but they do occasionally.  The amateur radio network
+   people created their own naming scheme, and it interferes sometimes
+   with Internet addresses.
+
+
+
+
+
+
+
+
+Cooper & Postel                                                 [Page 3]
+
+RFC 1386                     The US Domain                 December 1992
+
+
+   1.3  The US Domain
+
+   The US Domain is an official top-level domain in the DNS of the
+   Internet community.  It is registered with the Network Information
+   Center.  The domain administrators are Jon Postel and Ann Westine
+   Cooper at the Information Sciences Institute of the University of
+   Southern California (USC-ISI).
+
+   US is the ISO-3166 2-letter country code for the United States and
+   thus the US Domain is established as a top-level domain and
+   registered with the NIC the same way other country domains are.
+
+   Because organizations in the United States have registered primarily
+   in the EDU and COM domains, little use was initially made of the US
+   domain.
+
+   In the past, the computers registered in the US Domain were primarily
+   owned by small companies or individuals with computers at home.
+   However, the US Domain has grown and currently registers hosts in
+   federal government agencies, state government agencies, K12 schools,
+   community colleges, private schools, libraries, county agencies, and
+   city utilities, to name a few.
+
+   The administration of the US Domain was managed solely by the Domain
+   Registrar in the past.  However, due to the increase of hosts,
+   administration of subdomains is being delegated to others.
+
+   Any computer in the United States may be registered in the US Domain.
+
+2. NAMING STRUCTURE
+
+   The US Domain hierarchy is based on political geography.  The
+   namespace under .US is the state namespace, then the city namespace,
+   then organization or computer name and so on.
+
+   For example:
+
+          SPK.WA.US
+         VANC.WA.US
+
+   There is of course no problem with running out of names.
+
+   The things that are named are individual computers.
+
+   If you register now in one city and then move, the database can be
+   updated with a new name in your new city, and a pointer can be set up
+   from your old name to your new name.  This type of pointer is called
+   a CNAME record.
+
+
+
+Cooper & Postel                                                 [Page 4]
+
+RFC 1386                     The US Domain                 December 1992
+
+
+   The use of un-registered names is not effective and causes problems
+   for other users.  Inventing your own name and using it without
+   registering is not a good idea.
+
+   2.1  State Codes
+
+   The state codes are the two letter US Postal abbreviations.
+
+   2.2  City Codes or Locality Names
+
+   Cities may be named (designated) by their full name (spelled out with
+   hyphens replacing spaces (e.g., Los-Angeles or New-York)), or by a
+   city code.  The first choice is the full city name, the second choice
+   is the city codes from Western Union's "City Mnemonics" list, and a
+   third choice is a code for your city chosen by the applicant.
+   However, it is very desirable that all users in the same city use the
+   same designator for the city.
+
+   Abbreviated city names are a good idea, particularly when the city
+   name is long, as there is much to type already.  One of the problems
+   is that the city codes in the Western Union City Mnemonics list are
+   sometimes not very good abbreviations.  Users sometimes tend to
+   prefer abbreviations that are commonly used already from that region.
+   Such as SF for San Francisco, MPK for Menlo Park.
+
+   Exceptions have been made in the abbreviations, even though this
+   causes extra work to keep track of these abbreviations.  One
+   abbreviation for one city.  Applicants are told what codes are
+   currently in use, however, if a city code is not used yet, and they
+   would prefer to use a different code that is more common among the
+   natives, then the new code is allowed.  However, once it's
+   registered, then everyone else who registers in that city will have
+   to use that code or spell out the full city name.
+
+   Some applicants have tried to get a copy of the Western Union City
+   Mnemonics code list but it is no longer available from Western Union.
+   However, we do have a copy but it is not online. If you are
+   requesting an abbreviated city code please let us know and we will
+   gladly look it up for you.
+
+   2.3  Examples of Names
+
+   For small entities like individuals or small businesses there is
+   usually no problem with selecting locality based names.
+
+         For example:  Zuckys.Santa-Monica.CA.US
+
+
+
+
+
+Cooper & Postel                                                 [Page 5]
+
+RFC 1386                     The US Domain                 December 1992
+
+
+   For large entities like large corporations with multiple facilities
+   in several cities or states this often seems like a unreasonable
+   constraint (especially when compared with the alternative of
+   registering directly in the .COM domain).  However, a company does
+   have a headquarters office in a particular locality and so could
+   register with that name.
+
+         For example:  IBM.Armonk.NY.US
+
+
+             EXAMPLES OF THE NAMING STRUCTURE IN THE US DOMAIN
+
+   PRIVATE (business or individual)
+   ================================
+
+   Camp-Curry.Yosemite.CA.US       <====  a business
+   IBM.Armonk.NY.US                <====  a business
+   Dogwood.atl.GA.US               <====  a business
+   Geo-Petrellis.Culver-City.CA.US <====  a restaurant
+   Zuckys-Santa-Monica.CA.US       <====  a restaurant
+   Joe-Josts.Long-Beach.CA.US      <====  a bar
+   Holodek.Santa-Cruz.CA.US        <====  a personal computer
+
+   FEDERAL
+   =======
+
+   Senate.FED.US           <====  US Senate
+   DOD.FED.US              <====  US Defense Dept.
+   DOT.FED.US              <====  US Transportation Dept.
+   USPS.FED.US             <====  US Postal Service
+   VA.FED.US               <====  US Veterans Administration
+   IRS.FED.US              <====  US Internal Revenue Service
+   Yosemite.NPS.Interior.FED.US    <====  a federal agency
+
+   STATE
+   =====
+
+   Senate.STATE.MN.US      <====  state Senate
+   House.STATE.MN.US       <====  state House of Reps
+   MDH.STATE.MN.US         <====  state Health Dept.
+   HUD.STATE.CA.US         <====  state House and Urban Dev. Dept.
+   DOT.STATE.MN.US         <====  state Transportation Dept.
+   Caltrans.STATE.CA.US    <====  state Transportation Dept.
+   DMV.STATE.CA.US         <====  state Motor Vehicles Dept.
+   Culver-City.DMV.STATE.CA.US  <====  a local office of DMV
+
+
+
+
+
+
+Cooper & Postel                                                 [Page 6]
+
+RFC 1386                     The US Domain                 December 1992
+
+
+   CITY | COUNTY
+   ==============
+
+   Police.CITY.Culver-City.CA.US       <====  a city department
+   Fire-Dept.CITY.Los-Angeles.CA.US    <====  a city department
+   Fire-Dept.COUNTY.Los-Angeles.CA.US  <====  a county department
+
+   REGIONAL | DISTRICT | LIBRARY
+   =============================
+
+   SCAQMD.DISTRICT.CA.US                     <====  a regional district
+   Bunker-Hill-Improvement.DISTRICT.LA.CA.US <====  a local district
+
+   Huntington.LIB.LA.US                    <====  a private library
+   Venice.LA-City.LIB.CA.US                <====  a city library
+   MDR.LA-County.LIB.CA.US                 <====  a county library
+
+   K12 | CC | STATE UNIV | PRIVATE SCHOOLS
+   =======================================
+
+   Los-Angeles.UC.STATE.CA.US      <====  UCLA
+   Berkeley.UC.STATE.CA.US         <====  "CAL"
+   Irvine.UC.STATE.CA.US           <====  University of Calif. Irvine
+   Santa-Cruz.UC.STATE.CA.US       <====  University of Calif. Santa Cruz
+   Northridge.CSU.STATE.CA.US      <====  Calif. State. Univ. Northridge
+   Fullerton.CSU.STATE.CA.US       <====  Calif. State. Univ. Fullerton
+   Sonoma.CSU.STATE.CA.US          <====  Calif. State. Univ. Sonoma
+
+   SMCC.Santa-Monica.CC.CA.US      <====  a public community college
+   Trade-Tech.Los-Angeles.CC.CA.US <====  a public community college
+
+   Hamilton.High.LA-Unified.K12.CA.US      <====   a public K12 school
+   Sherman-Oaks.Elem.LA-Unified.K12.CA.US  <====   a public K12 school
+   John-Muir.Middle.Santa-Monica.K12.CA.US <====   a public K12 school
+
+   St-Monica.High.Santa-Monica.CA.US       <====  a private high school
+   St-Monica.Elem.Santa-Monica.CA.US       <====  a private elem. school
+   Crossroads-School.Santa-Monica.CA.US    <====  a private school
+   Mary-Ellens.Montessori-School.LA.CA.US  <====  a private school
+   Leland-Stanford-Jr-Univ.Stanford.CA.US  <====  a private school
+   Loyola-Marymount-Univ.Los-Angeles.CA.US <====  a private school
+
+
+
+
+
+
+
+
+
+
+Cooper & Postel                                                 [Page 7]
+
+RFC 1386                     The US Domain                 December 1992
+
+
+   When appropriate, subdomains are delegated and partioned in various
+   categories, such as:
+
+                   K12.<state>.US   =   kindegarten thru 12th grade
+                    CC.<state>.US   =   community colleges
+                   LIB.<state>.US   =   libraries
+                 STATE.<state>.US   =   state government agencies
+                <org-name>.FED.US   =   federal government agencies
+
+   The Appendix-I contains the current US Domain Names BNF, but in
+   actuality, the names under these subdomains may vary according to the
+   decision of the administrators of these subdomains.
+
+   Some users would like names associated with a greater metropolitan
+   area or region like the "Bay Area" or "Tri-Cities".  One problem with
+   this is that these names are not necessarily unique within a state.
+   The best thing to do in this case is to use the larger metropolitan
+   city in your host name.  Cities and in some cases counties are used.
+
+3. REGISTRATION
+
+   3.1  Requirements
+
+   Anyone requesting to register a host in the US Domain is sent a copy
+   of the US Domain policy and procedure, and must fill out a US Domain
+   questionnaire.
+
+   The US Domain template, is similar to the NIC Domain template
+   however, it is not the same.  To request a copy of the US Domain
+   questionnaire, send a message to the US Domain registrar (us-
+   domain@isi.edu).
+
+      Note:  If you are registering a name in a delegated zone
+             (see Section 3.3.6).  Please register with the
+             contact for that zone.
+
+   The key people must have electronic mailboxes (that work).  Please
+   provide all the information indicated in the "Administrator" and
+   "Technical Contact" slot.  This person will be the point of contact
+   for any administrative and policy questions about the domain.
+
+   The administrator is usually the person who manages the organization
+   being registered. The technical contact can also be administrator, or
+   the systems person, or someone who is familiar with the technical
+   details of the Internet. The technical contact should have a valid
+   working e-mail address. This is necessary in case something goes
+   wrong.
+
+
+
+
+Cooper & Postel                                                 [Page 8]
+
+RFC 1386                     The US Domain                 December 1992
+
+
+   It is important that your "Return-Path" and "From" field indicate an
+   Internet style address.  UUCP style addresses such as "host1!user"
+   will not work. This is fine within the UUCP world, but not the
+   Internet.  If you want people on the Internet to be able to send mail
+   to you, your return path needs to be an Internet style address: such
+   as host1!user@internet.gateway.host or user@internet.gateway.host.
+
+   It is also possible to register through one of the Internet service
+   providers that have established working relationships with the US
+   domain administrator.
+
+   If everything checks out, turn around time for registering a host is
+   usually a day or two.  The nameservers are updated anywhere from 12
+   to 24 hours later.
+
+   There are two ways to be registered in the US Domain, directly, or by
+   delegation.
+
+   3.2  Direct Entries
+
+   Direct entry in the database of the US Domain appeals most to
+   individuals and small companies.  Fill out the application and send
+   it directly to the US Domain administrator.  If you are in an area
+   where the zone is delegated to someone else your request will be
+   forwarded to the zone administrator for your registration.
+
+   3.2.1 UUCP Hosts
+
+   Many applicants have hosts in the UUCP world.  Some are one hop away,
+   some two and three hops away from their "Internet Forwarder", this is
+   ok.  What is important is getting an Internet host to be your
+   forwarder.  If you do not already have an Internet forwarder, there
+   are several businesses that provide this service for a fee, such as
+   UUNET.UU.NET (postmaster@uunet.uu.net), PSI (postmaster@UU2.PSI.COM)
+   and CERFNET (help@cerf.net).  Sometimes local colleges in your area
+   are already on the Internet and may be willing to act as an Internet
+   Forwarder.  You would need to work this out with the systems
+   administrator we cannot make these arrangements for you.
+
+   Although we work with UUCP service providers, the Internet US Domain
+   registration is not affiliated with the registration of UUCP Map
+   entries.  The UUCP map entry does not provide us with sufficient
+   information.  If you do not have a copy of the US Domain
+   questionnaire template, please send a message to: us-domain@isi.edu
+   and request one.  See Appendix-II.
+
+
+
+
+
+
+Cooper & Postel                                                 [Page 9]
+
+RFC 1386                     The US Domain                 December 1992
+
+
+   This is not an appropriate registration for the US Domain.
+
+     #N starl
+     #S Amiga 2500; AmigaDOS 2.04; Dillon's AmigaUUCP 1.15D
+     #O Starlight BBS
+     #C Stephen Baker
+     #E starl!sbaker
+     #T +1 305 378 1161
+     #P 1107 SW 200th St #303B Miami, Fl. 33157
+     #L 25 47 N / 88 10 W [city]
+     #R
+     #U mthvax
+     #W starl!sbaker (Stephen Baker); Mon Feb 24 19:58:24 EST 1992
+      starl        mthvax(DAILY)
+
+   If you are registering your host as a central site for a USENET group
+   where other UUCP sites will feed from you, that's fine.  These UUCP
+   sites do not need to register.  If however, the other sites become a
+   subdomain of your hostname, then we will need to register them
+   individually or add a wildcard record.
+
+           For example:          bah.rochester.ny.us
+                           host1.bah.rochester.ny.us
+                           host2.bah.rochester.ny.us
+
+   3.2.2 NON-IP Hosts
+
+   To use US Domain names for non-IP hosts, there must be a forwarder
+   host that is an IP host.  There must be an adminstrative agreement
+   and a technical procedure for relaying mail between the non-IP host
+   and the forwarder host.
+
+   Case 1:
+   -------
+
+   Your host is not an IP host but does talk directly with a host that
+   is an IP host.
+                                                  +-----------------+
+   +----------+            +---------+            |                 |
+   |your-host |---UUCP-----|forwarder|----IP/TCP--|    INTERNET     |
+   +----------+            +---------+            |                 |
+                                                  +-----------------+
+   "Forwarder" must be an IP host on the Internet.
+
+   You must ask "forwarder" if they are willing to be the internet
+   forwarder for "your-host".
+
+   In the US Domain of the DNS data base there must be an entry like
+
+
+
+Cooper & Postel                                                [Page 10]
+
+RFC 1386                     The US Domain                 December 1992
+
+
+   this:
+          "your-host"  MX  10  "forwarder"
+
+   This must be entered by the US Domain administrator.
+
+   In the "forwarder" routing tables there must be information about
+   "your-host" with a rule like: If I see mail for "your-host" I will
+   send it via uucp by calling phone number "123-4567".
+
+   Case 2:
+   -------
+
+   In this case your hosts talks to another host that ... that talks to
+   an IP host.  In other words, there are multiple hops between your host
+   and the Internet.
+                                                  +-----------------+
+   +----------+            +---------+            |                 |
+   |path-host |---UUCP-----|forwarder|----IP/TCP--|    INTERNET     |
+   +----------+            +---------+            |                 |
+       |                                          +-----------------+
+      UUCP
+       |
+   +----------+
+   |your-host |
+   +----------+
+
+   "Forwarder" must be an IP host on the internet.
+
+   You must ask "forwarder" if they are willing to be the Internet
+   Forwarder for "Your-Host".  You must ask "path-host" to relay your
+   mail.
+
+   In the US Domain of the DNS DataBase there must be an entry like this:
+
+          "your-host"  MX  10  "forwarder"
+
+   This must be entered by the US Domain Administrator.
+
+   In the "forwarder" routing tables there must be information about
+   "your-host" with a rule like: If I see mail for "your-host" I will
+   send it via UUCP to "path-host" by calling phone number "123-4567".
+   and "path-host" must also know how to relay the mail to "your-host".
+
+   Note: It is assumed that "path-host" is already MXed to "forwarder".
+   It is not appropriate to ask to MX "your-host" to "path-host" (this
+   is sometimes called double MXing).  The host on the right hand side
+   of an MX entry must be a host on the Internet with an IP address
+   (e.g., 128.9.2.32).
+
+
+
+Cooper & Postel                                                [Page 11]
+
+RFC 1386                     The US Domain                 December 1992
+
+
+   3.3  Delegated Subdomains
+
+   The administrator of the US Domain is responsible for the assignment
+   of all the DNS names that end with ".US".  Of course, one person or
+   even one group can't handle all this in the long run so portions of
+   the name space are delegated to others.
+
+   Delegation of cities, companies within cities, schools (K12),
+   community colleges (CC), libraries (LIB), state government (STATE),
+   and federal government agencies, departments, etc., is acceptable and
+   practical.
+
+   For a delegated portion of the namespace, for example a city, no
+   alterations can be made to that name, no abbreviations added, etc.
+   unless applied for.
+
+   Sometimes there may be two people running name servers in the same
+   city because different portions of the name space has been delegated
+   to them.  For example, someone may be delegated the <city>.<state>.US
+   name space, and someone else from a state government agency may have
+   the .STATE.<state>.US, portion.  For example, Fred may run the name
+   servers for Sacramento.CA.US and Joe may run the name servers for
+   STATE.CA.US in Sacramento.
+
+   If a company would like to have wildcard records added, or run their
+   own name servers in a city that we have delegated name space to, this
+   is ok.
+
+   Delegation of the whole State namespace is not yet implemented.  The
+   delegated part of the name space is in the form of:
+
+                    .STATE.<state>.US.
+                      .K12.<state>.US.
+                       .CC.<state>.US.
+                      .LIB.<state>.US.
+        .<org-name>.<city>.<state>.US.
+         .CITY.<city-name>.<state>.US.
+                   .<org-name>.FED.US.
+
+   3.3.1  Schools
+
+   As schools begin to join the Internet, there ought to be a consistent
+   scheme for naming them.  A "K12" name branch has been established in
+   each state in the US Domain for this purpose.
+
+   Public schools are usually organized by districts which can be larger
+   or smaller than a city or county.
+
+
+
+
+Cooper & Postel                                                [Page 12]
+
+RFC 1386                     The US Domain                 December 1992
+
+
+   It makes sense to name schools within districts.  However districts
+   often have the same name as a city or county so there has to be a way
+   to distinguish a public school district name from some other type of
+   locality name.  The keyword "K12" is used for this.
+
+   In some districts, the same school name is used at different levels,
+   for example, Washington Elementary School and Washington High School.
+   We suggest that when necessary the keywords "Elementary", "Middle",
+   and "High" be used to distinguish these schools.  These keywords
+   would only be used when they are needed, if the school's name is
+   unique without such keywords don't use them.
+
+   Typical K12 school names currently used are like:
+
+              IVY.PRS.K12.NJ.US
+              DMHS.JCPS.K12.KY.US
+              OHS.EUNION.K12.CA.US
+              BOHS.BREA.K12.CA.US
+
+   These names could be long.  Given the large number of schools,
+   organizing by school district and state seems appropriate.  When
+   there are many things to name some of the names must be long.
+
+   In some cases there may be appropriate abbreviations that can be
+   used.  For example Hamilton High School in Los Angeles could be:
+
+              Hami.Hi.LA.K12.CA.US
+
+      Some School Examples:
+      ---------------------
+
+      Hamilton.High.LA-Unified.K12.CA.US        <== a public school
+      Sherman-Oaks.Elem.LA-Unified.K12.CA.US    <== a public school
+      John-Muir.Middle.Santa-Monica.K12.CA.US   <== a public school
+      Crossroads-School.Santa-Monica.CA.US      <== a private school
+      SMCC.CC.CA.US                             <== a community college
+      Northridge.CSU.STATE.CA.US                <== a state university
+
+   If a school has a bunch of PCs, then each PC should have a name.
+   Suppose they are named "alpha", "beta", ... then if they belong to a
+   school named "Lincoln.High.Lakewood.K12.CA.US" their names would be:
+
+                alpha.Lincoln.High.Lakewood.K12.CA.US.
+                beta.Lincoln.High.Lakewood.K12.CA.US
+           ...
+
+
+
+
+
+
+Cooper & Postel                                                [Page 13]
+
+RFC 1386                     The US Domain                 December 1992
+
+
+   3.2.2  State Agencies
+
+   US Domain namespace has been delegated to the state goverment
+   agencies.  For example, in the State of Minnesota, the subdomain is
+   STATE.MN.US
+
+   This means that the person running the namservers for state.mn.us are
+   responsible for naming agencies, of the state govermnent.  For
+   example:
+
+      State Agencies:
+      ---------------
+
+      Senate.STATE.MN.US      <== State Senate
+      MDH.STATE.MN.US         <== Dept. of Health
+      CALTRANS.STATE.CA.US    <== Dept. of Transportation
+      DMV.STATE.CA.US         <== Dept. of Motor Vehicles
+
+   3.3.3  Federal Agencies
+
+   A federal namespace has been delegated to the federal government
+   agencies.  For example the subdomain for the Federal Reserve Bank of
+   Minneapolis is MNPL.FRB.FED.US. Other examples are listed below.
+
+      Federal Government Agencies:
+      ---------------------------
+
+      Senate.FED.US   <====  US Senate
+      DOD.FED.US      <====  US Defense Dept.
+      USPS.FED.US     <====  US Postal Service
+      VA.FED.US       <====  US Veterans Administration
+      IRS.FED.US      <====  US Internal Revenue Service
+      Yosemite.NPS.Interior.FED.US    <====  A Federal agency
+
+   3.3.4  Delegation Requirements
+
+   When a subdomain is delegated, the following requirements must be
+   met:
+
+      1)  There must be a knowledgeable and competent technical contact,
+          familiar with the Internet Domain Name System.  This
+          requirement is easily satisified if the technical contact
+          already runs some other nameservers.
+
+      2)  Organizations requesting delegations must provide at least two
+          independent (robust and reliable) DNS name servers in
+          physically separate locations on the Internet.
+
+
+
+
+Cooper & Postel                                                [Page 14]
+
+RFC 1386                     The US Domain                 December 1992
+
+
+      3)  The subdomain must accept all applicants on an equal basis.
+
+      4)  The subdomain must provide timely processing of requests.  To
+          do this it is helpful to have several individuals
+          knowledgeable about the procedures so that the operations are
+          not delayed due to one persons unavailability (for example by
+          being on vacation).
+
+   3.3.5  Delegation Procedures
+
+   The procedure that is followed when a subdomain is delegated includes
+   the following steps:
+
+      1)  Evaluate the technical contact's experience with DNS.  Make
+          sure there is a need for the proposed delegation.  Make sure
+          the technical contact has the information about the US Domain
+          and the suggested naming structure.
+
+      2)  Note: In the past there was the concept of a "coordinator" for
+          a group or a club or "Domain Park". They would arrange to
+          coordinate the registration of all the computers used by
+          members of the club and forward all the information for the
+          group to the US Domain Administrator.  Most coordinators have
+          moved into the position of administrator of that now delegated
+          subdomain.
+
+      3)  Add the new technical contact to the "us-dom-adm" mailing list
+          for distributing updates to the US Domain policies and
+          procedures, or other pertinent information.
+
+      4)  Delete any hosts from our zone file that belongs in the newly
+          delegated subdomain and make sure they now have the hosts in
+          their zone file.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cooper & Postel                                                [Page 15]
+
+RFC 1386                     The US Domain                 December 1992
+
+
+      5)  Send them a copy of the zone file so their initial zone file
+          is identical to ours. For example:
+
+            mil.wi.us.   86400   SOA spool.mu.edu. manager.spool.mu.edu. (
+                                    920904  ;serial
+                                    28800   ;refresh
+                                    14400   ;retry
+                                    3600000 ;expire
+                                    86400 ) ;minim
+
+            mil.wi.us.      86400   NS      spool.mu.edu.
+            spool.mu.edu.   50400   A       134.48.1.31
+            mil.wi.us.      86400   NS      sophie.mscs.mu.edu.
+
+            sophie.mscs.mu.edu.     50400   A       134.48.4.6
+            solaria.mil.wi.us.      86400   HINFO   Sun 3/60 SunOs
+            solaria.mil.wi.us.      86400   MX      10 spool.mu.edu.
+            nthomas.mil.wi.us.      86400   HINFO   386 Clone DOS
+            nthomas.mil.wi.us.      86400   MX      10 spool.mu.edu.
+            rwmke.mil.wi.us.        86400   HINFO   UNIX PC UNIX
+            rwmke.mil.wi.us.        86400   MX      10 spool.mu.edu.
+            milestn.mil.wi.us.      86400   HINFO   PC AT ENIX
+            milestn.mil.wi.us.      86400   MX      10 spool.mu.edu.
+            dawley.mil.wi.us.       86400   HINFO   386 Clone DOS
+            dawley.mil.wi.us.       86400   MX      10 spool.mu.edu.
+            ...
+                      -------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cooper & Postel                                                [Page 16]
+
+RFC 1386                     The US Domain                 December 1992
+
+
+      6)  The US Domain zone file must have the following records,
+          showing the name, address, e-mail, and phone number of the
+          technical contact for the delegated subdomain and the name of
+          the delegated name space and the names of the nameservers.
+
+            ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
+            ;
+            ;Delegated zone: .mil.wi.us
+            ;Contact:  Steven Goodman
+            ;          manager@spool.mu.edu
+            ;          Marquette University
+            ;          (414) 288-6734
+
+            mil.wi.us.      604800  NS      SPOOL.MU.EDU.
+                            604800  NS      SOPHIE.MSCS.MU.EDU.
+
+            ; A glue record is not needed this time. Glue records are
+            ; needed when the name of the server is a subdomain of the
+            ; delegated domain.
+            ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
+
+      7)  Check to see that delegated subdomain name servers are up and
+          running, and make sure the delegated hosts are installed in
+          their zone file.  Now delete any hosts from the US Domain zone
+          file that belongs in the newly delegated subdomain.
+
+      8)  Inform the technical contact of the newly delegated subdomain
+          that wildcard records are allowed in the zone file under the
+          organizational subdomain but no wildcard records are allowed
+          under the "city" or "state" domain.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cooper & Postel                                                [Page 17]
+
+RFC 1386                     The US Domain                 December 1992
+
+
+   3.3.6   Subdomain Contacts
+
+   Approximately 680 individual hosts are registered, but we have
+   delegated the following portions of the namespace.  We do not know
+   how many hosts are registered under each of these subsdomains.
+
+           DELEGATED ZONE             CONTACT
+           ==============             =======
+
+           TUCSON.AZ.US               leonard@arizona.edu
+           SF.CA.US                   sf-hostmaster@apple.com
+           PREMENOS.SF.CA.US          jenkins@premenos.sf.ca.us
+           SCVL.CA.US                 sinster@scintilla.capitola.ca.us
+           SANTA-CRUZ.CA.US           sinster@scintilla.capitola.ca.us
+           APTOS.CA.US                sinster@scintilla.capitola.ca.us
+           CAMPBELL.CA.US             sinster@scintilla.capitola.ca.us
+           CAPITOLA.CA.US             sinster@scintilla.capitola.ca.us
+           FELTON.CA.US               sinster@scintilla.capitola.ca.us
+           ZAYANTE.CA.US              sinster@scintilla.capitola.ca.us
+           BOULDER-CREEK.CA.US        sinster@scintilla.capitola.ca.us
+           DARWIN.PTVY.CA.US          brian@angband.stanford.edu
+           LOGAN-HS.UNIONCITY.CA.US   cjw@marmot.nersc.gov
+           BOULDER.CO.US              trent@XOR.COM
+           COLOSPGS.CO.US             trent@XOR.COM
+           DENVER.CO.US               trent@XOR.COM
+           DVR.CO.US                  trent@XOR.COM
+           CHI.IL.US                  matt@oddjob.uchicago.edu
+           EUGENE.OR.US               meyer@oregon.uoregon.edu
+           SPRINGFIELD.OR.US          meyer@oregon.uoregon.edu
+           MULTNOMAH.LIB.OR.US        brianw@polaris.admin.ogi.edu
+           PGH.PA.US                  ecd@CERT.ORG
+           SPK.WA.US                  root@dogear.spk.wa.us
+           MIL.WI.US                  manager@spool.mu.edu
+           ATL.GA.US                  charvey@gatech.gatech.edu
+           Mt-PARK.GA.US              charvey@gatech.gatech.edu
+           CLARKSTON.GA.US            charvey@gatech.gatech.edu
+           STATE.MN.US                dfazio@mr.net
+           MNPL.FRB.FED.US            dfazio@mr.net
+
+           K12.CA.US                  mdm@NIC.CSU.NET
+           CC.CA.US                   mdm@NIC.CSU.NET
+           K12.MI.US                  sandra.s.waite@um.cc.umich.edu
+           K12.TX.US                  bmanning@is.rice.edu
+           K12.NJ.US                  becker@nisc.jvnc.net
+           K12.MS.US                  fwp@msstate.edu
+           dmhs.jcps.K12.KY.US        lentner@sura.net
+           TIES.K12.MN.US             dfazio@mr.net
+
+
+
+
+Cooper & Postel                                                [Page 18]
+
+RFC 1386                     The US Domain                 December 1992
+
+
+        The following MD.US counties have been delegated to
+        (butler@brl.mil).
+
+           AL.MD.US.       Allegany
+           AA.MD.US.       Anne Arundel
+           BA.MD.US.       Baltimore
+           CAL.MD.US.      Calvert
+           CAR.MD.US.      Caroline
+           CE.MD.US.       Cecil
+           CH.MD.US.       Charles
+           DO.MD.US.       Dorchester
+           FR.MD.US.       Frederick
+           GA.MD.US.       Garrett
+           HA.MD.US.       Harford
+           HO.MD.US.       Howard
+           KE.MD.US.       Kent
+           MO.MD.US.       Montgomery
+           PG.MD.US.       Prince George"s
+           QA.MD.US.       Queen Anne's
+           SM.MD.US.       St. Mary's
+           SO.MD.US.       Somerset
+           TA.MD.US.       Talbot
+           WA.MD.US.       Washington
+           WI.MD.US.       Wicomico
+           WO.MD.US.       Worcester
+
+4. DATABASE INFORMATION
+
+   4.1. Name Servers
+
+   Name servers are the repositories of information that make up the
+   domain database.  The database is divided up into sections called
+   zones, which are distributed among the name servers.  While name
+   servers can have several optional functions and sources of data, the
+   essential task of a name server is to answer queries using data in
+   its zones.  The response to a query can always be generated using
+   only local data, and either contains the answer to the question or a
+   referral to other name servers "closer" to the desired information.
+
+   A given zone will be available from several name servers to insure
+   its availability in spite of host or communication link failure.
+   Every zone is required to be available on at least two servers, and
+   many zones have more redundancy than that.
+
+
+
+
+
+
+
+
+Cooper & Postel                                                [Page 19]
+
+RFC 1386                     The US Domain                 December 1992
+
+
+   The US Domain is currently supported by six name servers.
+
+           venera.isi.edu
+           ns.isi.edu
+           ns.hercules.csl.sri.com
+           nnsc.nsf.net
+           ns.uu.net
+           adm.brl.mil
+
+   4.2 Zone Files
+
+   A "zone" is a registry of domains kept by a particular organization.
+   A zone registry is "authoritative", that is, the master copy of the
+   registry is kept by the zone organization, and this copy is, by
+   definition, always up-to-date.  Copies of this registry may be
+   distributed to other places and kept in caches, but these caches are
+   not authoritative, and may be out-of-date.
+
+   Every zone has at least one node, and hence domain name, for which it
+   is authoritative, and all of the nodes in a particular zone are
+   connected.  Given the tree structure, every zone has a highest node
+   which is closer to the root than any other node in the zone.  The
+   name of this node is often used to identify the zone.  The data that
+   describes a zone has four major parts:
+
+        1) Authoritative data for all nodes within the zone.
+
+        2) Data that defines the top node of the zone
+           (can be thought of as part of the authoritative data).
+
+        3) Data that describes delegated subzones, i.e., cuts
+           around the bottom of the zone,
+
+        4) Data that allows access to name servers for subzones
+           (sometimes called "glue" data).
+
+   The zone administrator has to maintain the zones at all the
+   namservers which are authoritative for the zone.  When the changes
+   are made they must be distributed to all of the name servers.
+
+   Copies of the zone files are not available unless you are on the
+   Internet.  To look at the zone files use the "dig" program of the DNS
+   domain name system.
+
+        dig   @nshost  host-your-checking  axfr
+
+
+
+
+
+
+Cooper & Postel                                                [Page 20]
+
+RFC 1386                     The US Domain                 December 1992
+
+
+   4.3 Resource Records
+
+   Records in the zone data files are called resource records (RRs).
+   The standard Resource records (RR) are specified in STD 13, RFC 1034
+   and STD 13, RFC 1035 (3,4).  An RR has a standard format as shown.
+
+                  <name> [<ttl>] [<class>] <type> <data>
+
+   The first field is always the name of the domain record.  The second
+   field is an optional time to live field.  This specifies how long
+   this data will be stored in the data base.  The third field is the
+   address class; the class field specifies the protocol group most
+   often this is the Internet class "IN".  The fourth field states the
+   type of the resource record.  The fields after that are dependent on
+   the Type of RR. The fifth field is the data field which is defined
+   differently for each type and class of data.  Here is a list of the
+   current commonly used types.
+
+           SOA     Start of Authority
+           NS      Name Server
+           A       Internet Address
+           CNAME   Canonical Name (nickname pointer)
+           HINFO   Host Information
+           WKS     Well Known Services
+           MX      Mail Exchanger
+           PTR     Pointer
+
+   What do the fields mean?
+
+           foo.LA.CA.US.    604800    MX   10     Venera.ISI.EDU.
+           (1)              (2)       (3)  (4)    (5)
+
+           1)  domain name
+           2)  time to live information
+           3)  mail exchanger record
+           4)  preference value to determine (if more than one
+               forwarder) which mailer to use first, lower number
+               higher preference
+           5)  the Internet forwarding host.
+
+
+
+
+
+
+
+
+
+
+
+
+Cooper & Postel                                                [Page 21]
+
+RFC 1386                     The US Domain                 December 1992
+
+
+   4.3.1  A Records
+
+   Internet (IP) Address.  The data for an "A" record is an Internet
+   address in a dotted decimal form.  A sample "A" record might look
+   like:
+
+           venera.isi.edu.          A      128.9.0.32
+              (name)               (A)     (address)
+
+   The name field is the machine name, and the address is the network
+   address. There should be only one "A" record for each address of a
+   host.
+
+   4.3.2  CNAME Records
+
+   Canonical Name resource record, CNAME, specifies an alias for a
+   canonical name. This is essentially a pointer to the official name
+   for the requested name.  All other RRs appear under this official
+   name.  A machine named FERNWOOD.MPK.CA.US may want to have the
+   nickname ANTERIOR.MPK.CA.US.  In that case, the following RR would be
+   used:
+
+           anterior.mpk.ca.us.     CNAME      fernwood.mpk.ca.us.
+            (alias nickname)                   (canonical name)
+
+   Nicknames (the name associated with the RR is the nickname) may be
+   added for awhile when a host changes its name, usually because it
+   moves to another state.  It helps to have this CNAME pointer so if
+   any mail comes to the old address it will get forwarded to the new
+   one.  There cannot be any other RRs associated with a nickname of the
+   same class.
+
+   4.3.3  MX Records
+
+   Mail Exchanger records, MX, are used to specify a machine that knows
+   how to deliver mail to a machine that is not directly connected to
+   the Internet.  For example, venera.isi.edu is the mail gateway that
+   knows how to deliver mail to foo.la.ca.us, but other machines on the
+   network cannot deliver mail directly to foo.la.ca.us.  These two
+   machines may have a private connection or use a different transport
+   medium (such as uucp).  The preference value (10) is the order that a
+   mailer should follow when there is more than one way to deliver mail
+   to a single machine.  The lower the number the higher the preference.
+
+           foo.LA.CA.US.  604800  MX  10  Venera.ISI.EDU.
+           foo.LA.CA.US.  604800  MX  20  relay1.uu.net.
+
+
+
+
+
+Cooper & Postel                                                [Page 22]
+
+RFC 1386                     The US Domain                 December 1992
+
+
+   4.3.4   HINFO Records
+
+   Host information resource records, HINFO is for host specific data.
+   This lists the hardware and operating system that are running at the
+   listed host.  It should be noted that a space separates the hardware
+   information and the operating system information.  If you want to
+   include a space in the machine name you must quote the name.  Host
+   information is not specific to any class, so ANY may be used for the
+   address class.  There should be one HINFO record for each host.
+
+   acb.la.ca.us.       HINFO       VAX-11/780      UNIX
+                                   (Hardware)      (Operating System)
+
+   The official HINFO types can be found in the latest Assigned Numbers
+   RFC, the most recent edition being RFC 1340.  The hardware type is
+   called the Machine Name, and the software type is called the System
+   Name.
+
+   The information users supply about this is often inconsistent or
+   incomplete.  Please follow the terms in the current "Assigned
+   Numbers".
+
+   4.3.5  PTR Records
+
+   A Domain Name Pointer record, PTR, allows special names to point to
+   some other location in the domain data base.  These are typically
+   used in setting up reverse pointers for the special IN-ADDR.ARPA
+   domain.  PTR names should be unique to the zone.
+
+         0.0.9.128.in-addr.arpa     PTR    isi-net.isi.edu.
+             (special name)                  (real name)
+
+   A PTR record is to be added to the IN-ADDR.ARPA domain for every A
+   record registered in the US Domain.  These PTR records need to be
+   added by the administrator of the network where the host is
+   connected.  The US Domain administration does not administer the
+   network and cannot make these entries in the DNS database.
+
+   4.4  Wildcards
+
+   The wildcard records are of the form "*.<anydomain>", where
+   <anydomain> is any domain name.  The wildcards potentially apply to
+   descendents of <anydomain>, but not to <anydomain> itself.
+
+   For example, suppose a large company located in California with a
+   large, non-IP/TCP, network wanted to create a mail gateway.  If the
+   company was called DWP.LA.CA.US, and the IP/TCP capable gateway
+   machine (Internet forwarder) was called ELROY.JPL.NASA.GOV, the
+
+
+
+Cooper & Postel                                                [Page 23]
+
+RFC 1386                     The US Domain                 December 1992
+
+
+   following RRs might be entered into the .US zone.
+
+           dwp.la.ca.us    MX      10       ELROY.JPL.NASA.GOV
+         *.dwp.la.ca.us    MX      10       ELROY.JPL.NASA.GOV
+
+   The wildcard record *.DWP.LA.CA.US would cause an MX query for any
+   domain name ending in DWP.LA.CA.US to return an MX RR pointing at
+   ELROY.JPL.NASA.GOV. The entry without the "*" is needed so the host
+   dwp can be found.
+
+   In the US Domain, wildcard records are allowed in our zone files
+   under the organizational subdomain (and where noted otherwise) but no
+   wildcard records are allowed under the "City" or "State" domain.
+
+       The authors strongly believe that it is in everyone's
+       interest and good for the Internet to have each host
+       explicitly registered (that is, we believe that wildcards
+       should not be used), we also realize that not everyone
+       agrees with this belief.  Thus, we will allow wildcard
+       records in the US Domain under groups or organizations.
+       For example, *.DWP.LA.CA.US.
+
+       The reason we feel single entries are the best is by the mere
+       fact that if anyone wanted to find one of the hosts in the
+       domain name system it would be there, and problems can be
+       detected more easily.  When using wildcards records all the
+       hosts under a subdomain are hidden.
+
+5. REFERENCES
+
+   [1]  Stahl, M., "Domain Administrators Guide", RFC 1032, SRI
+        International, November 1987.
+
+   [2]  Lottor, M., "Domain Administrators Operations Guide" RFC 1033,
+        SRI International, November 1987.
+
+   [3]  Mockapetris, P., "Domain Names - Concepts and Facilities",
+        STD 13, RFC 1034, ISI, November 1987.
+
+   [4]  Mockapetris, P., "Domain Names - Implementation and
+        Specification", STD 13, RFC 1035, ISI, November 1987.
+
+   [5]  Dunlap, K., "Name Server Operations Guide for Bind,
+        Release 4.3", UC Berkeley, SMM:11-3.
+
+   [6]  Partridge, C., "Mail Routing and the Domain Name System",
+        STD 14, RFC 974, BBN, January 1986.
+
+
+
+
+Cooper & Postel                                                [Page 24]
+
+RFC 1386                     The US Domain                 December 1992
+
+
+6. SECURITY CONSIDERATIONS
+
+   Security issues are not discussed in this memo.
+
+7. AUTHORS' ADDRESSES
+
+   Ann Cooper
+   USC/Information Sciences Institute
+   4676 Admiralty Way
+   Marina del Rey, CA  90292
+
+   Phone:  1-310-822-1511
+   Email:  cooper@isi.edu
+
+
+   Jon Postel
+   USC/Information Sciences Institute
+   4676 Admiralty Way
+   Marina del Rey, CA  90292
+
+   Phone:  1-310-822-1511
+   Email:  postel@isi.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cooper & Postel                                                [Page 25]
+
+RFC 1386                     The US Domain                 December 1992
+
+
+                     APPENDIX-I:  US DOMAIN NAMES BNF
+                     ================================
+
+   <us-domain-name>    ::= <us-name><dot><us>
+
+   <us-name>           ::= <state-name><dot><state-code> |
+                           <fed-name><dot><fed>
+
+   <state-code>        ::= <the two-letter code of a state from the
+                            zip code directory>
+
+   <state-name>        ::= <local-name><dot><locality> |
+                           <state-agency-name><dot><state> |
+                           <regional-agency-name><dot><agency>
+
+   <fed-name>          ::= <the dotted hierarchical name of a US
+                            federal government agency>
+
+   <locality>          ::= <the full name of a city from the
+                             zip code directory> |
+                           <a short code name for a city> |
+                           <the full name of a county, township,
+                            or parish> |
+                           <other well known and commonly used
+                            locality name>
+
+   <local-name>        ::= <entity-name> |
+                           <city-name><dot><city> |
+                           <county-name><dot><county> |
+                           <local-agency-name><dot><agency>
+
+   <state-agency-name> ::= <the dotted hierarchical name of a state
+                            government agency>
+
+   <regional-agency-name> ::= <the dotted hierarchical name of a special
+                            agency or district not an element of the
+                            state government and typically larger than
+                            a single city or county, for example, the
+                            Southern California Air Quality Management
+                            District>
+
+   <entity-name>       ::= <the dotted hierarchical name of an entity
+                            within a city, for example: a company,
+                            business, private school, club, organization,
+                            or individual>
+
+   <city-name>         ::= <the dotted hierarchical name of a city
+                            government agency>
+
+
+
+Cooper & Postel                                                [Page 26]
+
+RFC 1386                     The US Domain                 December 1992
+
+
+   <county-name>       ::= <the dotted hierarchical name of a county,
+                             township, or parish government agency>
+
+   <local-agency-name> ::= <the dotted hierarchical name of a special
+                            agency or district not an element of a
+                            city or county government and typically
+                            equal or smaller than a single city or
+                            county, for example, the Bunker Hill
+                            Improvement District>
+
+
+   <city> ::= "CITY"
+
+   <county> ::= "COUNTY" | "TOWNSHIP" | "PARISH"
+
+   <dot> ::= "."
+
+   <fed> ::= "FED"
+
+   <agency> ::= "AGENCY" | "DISTRICT" | "K12" | "CC" | "LIB"
+
+   <state> ::= "STATE" | "COMMONWEALTH"
+
+   <us> ::= "US"
+
+
+   Note:  "K12" may be used for public school districts, only.
+          and "CC" may be used only for public community colleges,
+          and "LIB" can only be used by libraries.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cooper & Postel                                                [Page 27]
+
+RFC 1386                     The US Domain                 December 1992
+
+
+            APPENDIX-II: US DOMAIN QUESTIONNAIRE FOR HOST ENTRY
+
+
+To register a host in the US domain, the following information must be
+sent to the US Domain Registrar (Us-Domain@ISI.EDU).  Questions may be
+sent by electronic mail to the above address, or by phone to
+Ann Cooper (310-822-1511).
+
+
+(1)  The name of the top-level domain to join.
+
+           For example:  US
+
+
+(2)  The name of the administrative head of the organization, including
+     title, mailing address, phone number, organization, and network
+     mailbox.  This is the contact point for administrative and policy
+     questions about the domain.  In the case of a research project,
+     this should be the principal investigator.
+
+           For example:
+
+              Administrator
+
+                 Organization  The NetWorthy Corporation
+                 Name          Penelope Q. Sassafrass
+                 Title         President
+                 Mail Address  The NetWorthy Corporation
+                               4676 Andrews Way, Suite 100
+                               Santa Clara, CA 94302-1212
+                 Phone Number  (415) 123-4567
+                 Net Mailbox   Sassafrass@ECHO.TNC.COM
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cooper & Postel                                                [Page 28]
+
+RFC 1386                     The US Domain                 December 1992
+
+
+(3)  The name of the technical contact for the entry, including title,
+     mailing address, phone number, organization, and network mailbox.
+     This is the contact point for problems concerning the domain or
+     zone, as well as for updating information about the domain or zone.
+
+           For example:
+
+              Technical Contact
+
+                 Organization  The NetWorthy Corporation
+                 Name          Ansel A. Aardvark
+                 Title         Executive Director
+                 Mail Address  The NetWorthy Corporation
+                               4676 Andrews Way, Suite 100
+                               Santa Clara, CA. 94302-1212
+                 Phone Number  (415) 123-6789
+                 Net Mailbox   Aardvark@ECHO.TNC.COM
+
+
+(4)  The name of the host.  This is the name that will be used in tables
+     and lists associating the domain with the domain server addresses.
+     [While, from a technical standpoint, domain names can be quite long
+     (programmers beware), shorter names are easier for people to cope
+     with.]
+
+           For example:  NetWorthy.Santa-Clara.CA.US
+
+           Or:  Alpha.NetWorthy.Santa-Clara.CA.US
+                Beta.NetWorthy.Santa-Clara.CA.US
+
+
+(5)  If this machine is not directly on the internet, how does it
+     communicate with the Internet.  Through UUCP, CREN, etc?  Which
+     forwarding host?
+
+          For example:  The host "Networthy.Santa-Clara.CA.US" uses UUCP
+          to connect to "RELAY.ISI.EDU" which is an Internet host.
+
+          The administrator of RELAY.ISI.EDU must agree to be the
+          forwarding host for Networthy.Santa-Clara.CA.US, and the
+          forwarding host must know a delivery method and route to it.
+          No double MXing.
+
+
+
+
+
+
+
+
+
+Cooper & Postel                                                [Page 29]
+
+RFC 1386                     The US Domain                 December 1992
+
+
+          If you are requesting an indirect connection, that is, a Mail
+          Exchanger (MX) record, what is the name and mailbox of the
+          administrator of the forwarding host.
+
+          For example:John Smith
+               js@RELAY.ISI.EDU
+
+
+(6)  Please describe your organization briefly.
+
+     For example: The NetWorthy Corporation is a consulting
+     organization of people working with UNIX and the C language in an
+     electronic networking environment.  It sponsors two technical
+     conferences annually and distributes a bimonthly newsletter.
+
+
+(7)  What Domain Name System (DNS) Resource Records (RR) and values are
+     to be entered.
+
+     a.  A       Internet Address (internet hosts only)
+     b.  HINFO   Host Information, Machine System
+     c.  WKS     Well Known Services, Protocols, Ports (internet hosts only)
+     d.  MX      Mail Exchanger (required for UUCP, and CREN hosts)
+
+     An example of RRs for an internet host.
+
+     NetWorthy.Santa-Clara.CA.US   IN   A       128.9.3.123
+                              IN   HINFO   SUN-3/11OC UNIX
+                              IN   MX      10  ISI.EDU
+                              IN   WKS     128.9.3.123. UDP (echo
+                                                             tftp)
+                              IN   WKS     128.9.3.133. TCP (telnet
+                                                             ftp
+                                                             tftp
+                                                             finger)
+
+     An example of RRs for a non-internet host.
+
+     Beta.NetWorthy.Santa-Clara.CA.US   MX      10   RELAY.ISI.EDU
+                                        HINFO   SUN-3/11OC UNIX
+
+
+
+
+
+
+
+
+
+
+
+Cooper & Postel                                                [Page 30]
+
+RFC 1386                     The US Domain                 December 1992
+
+
+(8)  Where is the IN-ADDR pointer record to be entered. (For internet
+     hosts only.)  It is your responsibility to see that this is done.
+     Contact the administrator of the IP network your host is on.  The
+     US Domain administration does not administer the network and cannot
+     make these entries in the DNS database.
+
+        For example:
+
+           123.3.9.128.IN-ADDR.ARPA.    PTR  NetWorthy.Santa-Clara.CA.US
+
+     Who is the contact for the zone of the IN-ADDR.ARPA data, where
+     this record will be entered?
+
+
+(9)  What Time to Live (TTL)?  TTL is the time (in seconds) that a
+     resolver will use the data it got from the domain server before it
+     asks it again for the data.  A typical TTL is One Week 604800.
+     (NOTE:  TTL is not applicable to non-Internet hosts.)
+
+        For example:
+
+           One Week   604800
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cooper & Postel                                                [Page 31]
+
\ No newline at end of file