doc: Add RFC documents

1 files changed, 2635 insertions, 0 deletions

diff --git a/doc/rfc/rfc1480.txt b/doc/rfc/rfc1480.txt
new file mode 100644
index 0000000..f8dd440
--- /dev/null
+++ b/doc/rfc/rfc1480.txt
@@ -0,0 +1,2635 @@
+
+
+
+
+
+
+Network Working Group                                          A. Cooper
+Request for Comments: 1480                                     J. Postel
+Obsoletes: 1386                                                June 1993
+
+                             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 ............................................  8
+       2.2  Locality Names..........................................  8
+       2.3  Schools ................................................ 10
+       2.4  State Agencies.......................................... 15
+       2.5  Federal Agencies ....................................... 15
+       2.6  Distributed National Institutes......................... 15
+       2.7  General Independent Entities............................ 16
+       2.8  Examples of Names....................................... 17
+   3.  Registration ................................................ 20
+       3.1  Requirements ........................................... 20
+       3.2  Direct Entries ......................................... 21
+       3.2.1   IP-Hosts............................................. 21
+       3.2.2   Non-IP Hosts ........................................ 21
+       3.3  Delegated Subdomains ................................... 24
+       3.3.1   Delegation Requirement............................... 26
+       3.3.2   Delegation Procedures ............................... 28
+       3.3.3   Subdomain Contacts................................... 29
+   4.  Database Information......................................... 30
+       4.1  Name Servers ........................................... 30
+       4.2  Zone files ............................................. 30
+       4.3  Resource Records ....................................... 31
+       4.3.1   "A" Records ......................................... 32
+       4.3.2   CNAME Records ....................................... 32
+       4.3.3   MX Records .......................................... 33
+       4.3.4   HINFO Records ....................................... 33
+       4.3.5   PTR Records ......................................... 33
+       4.4  Wildcards .............................................. 34
+   5.  References .................................................. 35
+
+
+
+Cooper & Postel                                                 [Page 1]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+   6.  Security Considerations ..................................... 35
+   7.  Authors' Addresses .......................................... 36
+   Appendix-I:  US Domain Names BNF................................. 37
+   Appendix-II: US Domain Questionnaire ............................ 42
+
+1. INTRODUCTION
+
+   1.1 The Internet Domain Name System
+
+   The Domain Name System (DNS) provides for the translation between
+   hostnames 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 delegated by the central Internet Registry to regional
+   authorities (such as the RIPE NCC for Europe) and the network
+   providers.
+
+   To have a network number assigned please contact your network service
+   provider or regional registration authority.  To determine who this
+   is (or as a last resort), you can contact the central Internet
+   Registry at Hostmaster@INTERNIC.NET.
+
+   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 registrations 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 hostname to address mappings were maintained by the
+   InterNIC in a single file, called HOSTS.TXT, which was FTP'd by all
+   the hosts on the Internet.  The network population was changing in
+   character.  The time-share 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
+
+
+
+Cooper & Postel                                                 [Page 2]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+   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
+   hierarchy levels was developed.  A design using a distributed
+   database and generalized resources was implemented.
+
+   The DNS provides standard formats for resource data, 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.  The establishment of new top-level domains is
+   managed by the Internet Assigned Numbers Authority (IANA).  The IANA
+   may be contacted at IANA@ISI.EDU.
+
+   Even though the original intention was that any educational
+   institution anywhere 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, similarly 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 its own way about organizing its domain,
+   and many have.
+
+   There are no current plans of putting all of the organizational
+   domains EDU, GOV, COM, etc., under US.  These name tokens are not
+   used in the US Domain to avoid confusion.
+
+   Currently, only four year colleges and universities are being
+   registered in the EDU domain.  All other schools are being registered
+   in the US Domain.
+
+   There are also concerns about the size of the other top-level domains
+   (especially COM) and ideas are being considered for restructuring.
+
+   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
+
+
+
+Cooper & Postel                                                 [Page 3]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+   "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.
+
+   1.3  The US Domain
+
+   The US Domain is an official top-level domain in the DNS of the
+   Internet community.  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 InterNIC 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, technical/vocational schools, private
+   schools, libraries, city and county government agencies, to name a
+   few.
+
+   Initially, the administration of the US Domain was managed solely by
+   the Domain Registrar.  However, due to the increase in registrations,
+   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 basic
+   name space under US is the state name space, then the "locality" name
+   space, (like a city, or county) then organization or computer name
+   and so on.
+
+   For example:
+
+          BERKELEY.CA.US
+          PORTLAND.WA.US
+
+
+
+
+Cooper & Postel                                                 [Page 4]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+   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.
+
+   The use of unregistered names is not effective and causes problems
+   for other users.  Inventing your own name and using it without
+   registering is not a good idea.
+
+   In addition to strictly geographically names, some special names are
+   used, such as FED, STATE, AGENCY, DISTRICT, K12, LIB, CC, CITY, and
+   COUNTY.  Several new name spaces have been created, DNI, GEN, and
+   TEC, and a minor change under the "locality" name space was made to
+   the existing CITY and COUNTY subdomains by abbreviating them to CI
+   and CO.  A detailed description follows.
+
+   Below US, Parallel to States:
+   -----------------------------
+
+   "FED" - This branch may be used for agencies of the federal
+   government.  For example: <org-name>.<city>.FED.US
+
+   "DNI" - DISTRIBUTED NATIONAL INSTITUTES - The "DNI" branch was
+   created directly under the top-level US.  This branch is to be used
+   for distributed national institutes; organizations that span state,
+   regional, and other organizational boundaries; that are national in
+   scope, and have distributed facilities.  For example:
+   <org-name>.DNI.US.
+
+   Name Space Within States:
+   ------------------------
+
+   "locality" - cities, counties, parishes, and townships.  Subdomains
+   under the "locality" would be like CI.<city>.<state>.US,
+   CO.<county>.<state>.US, or businesses. For example:
+   Petville.Marvista.CA.US.
+
+   "CI" - This branch is used for city government agencies and is a
+   subdomain under the "locality" name (like Los Angeles). For example:
+   Fire-Dept.CI.Los-Angeles.CA.US.
+
+   "CO" - This branch is used for county government agencies and is a
+   subdomain under the "locality" name (like Los Angeles).  For example:
+   Fire-Dept.CO.San-Diego.CA.US.
+
+
+
+Cooper & Postel                                                 [Page 5]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+   "K12" - This branch may be used for public school districts.  A
+   special name "PVT" can be used in the place of a school district name
+   for private schools.  For example: <school-name>.K12.<state>.US and
+   <school-name>.PVT.K12.<state>.US.
+
+   "CC" - COMMUNITY COLLEGES - This branch was established for all state
+   wide community colleges.  For example: <school-name>.CC.<state>.US.
+
+   "TEC" - TECHNICAL AND VOCATIONAL SCHOOLS - The branch "TEC" was
+   established for technical and vocational schools and colleges. For
+   example: <school-name>.TEC.<state>.US.
+
+   "LIB" - LIBRARIES (STATE, REGIONAL, CITY, COUNTY) - This branch may
+   be used for libraries only.  For example:  <lib-name>.LIB.<state>.US.
+
+   "STATE" - This branch may be used for state government agencies.  For
+   example:  <org-name>.STATE.<state>.US.
+
+   "GEN" - GENERAL INDEPENDENT ENTITY - This branch is for the things
+   that don't fit easily into any other structure listed -- things that
+   might fit in to something like ORG at the top-level.  It is best not
+   to use the same keywords (ORG, EDU, COM, etc.) that are used at the
+   top-level to avoid confusion.  GEN would be used for such things as,
+   state-wide organizations, clubs, or domain parks.  For example:
+   <org-name>.GEN.<state-code>.US.
+
+   ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+
+   VIEW OF SECOND LEVEL DOMAINS UNDER US
+
+                            +-------+
+                            |  US   |
+                            +-------+
+                                |
+              +----------------------------------+
+              |        |        |       |        |
+           +-----+  +-----+  +-----+  +-----+  +-----+
+           | FED |  | DNI |  | TX  |  | SD  |  | CA  |
+           +-----+  +-----+  +-----+  +-----+  +-----+
+
+   ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+
+
+
+
+
+
+
+
+
+
+Cooper & Postel                                                 [Page 6]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+   ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+   SCHOOL AND LIBRARY VIEW
+                                +-----+
+                                |  CA |
+                                +-----+
+                                   |
+          +------------------------------------------------+
+          |            |        |            |             |
+        +-----+     +-----+  +-----+  +-------------+   +-----+
+        | K12 |     | CC  |  | TEC |  | LOS ANGELES |   | LIB |
+        +-----+     +-----+  +-----+  +-------------+   +-----+
+          /   \       /|\      /|\          /|\           /|\
+   +--------+ +---+  +---+  +--------+  +----------+    +------+
+   |sch dist| |PVT|  |SJC|  |WM TRADE|  |pvt school|    |MALIBU|
+   +--------+ +---+  +---+  +--------+  +----------+    +------+
+      /|\      /|\
+   +--------+ +--------+
+   |sch name| |sch name|
+   +--------+ +--------+
+   ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+
+   VIEW OF STATE, REGIONAL, and GENERAL AGENCIES
+
+                                +-----+
+                                |  CA |
+                                +-----+
+                                   |
+                      +-------------------------+
+                      |            |            |
+                   +-------+   +--------+    +-----+
+                   | STATE |   |DISTRICT|    | GEN |
+                   +-------+   +--------+    +-----+
+                     /|\          /|\          /|\
+                   +--------+   +------+   +---------+
+                   |CALTRANS|   |SCAQMD|   |domain pk|
+                   ---------+   +------+   +---------+
+                      |
+                   +--------+
+                   |TCEW100E|
+                   +--------+
+   ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+
+
+
+
+
+
+
+
+
+
+Cooper & Postel                                                 [Page 7]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+   ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+
+   VIEW OF LOCALITY
+                                +-----+
+                                |  CA |
+                                +-----+
+                                   |
+                   +-----------------------------------+
+                   |                                   |
+         +-------------------------+           +----------------+
+         |       LOS ANGELES       |           |  SANTA MONICA  |
+         +-------------------------+           +----------------+
+          /  |          |       /|\                |       /|\
+         /   |          |        |                 |        |
+     +---+ +--+        +--+  +-----------+       +--+     +---+
+     |bus| |CI|        |CO|  | pvt school|       |CI|     |bus|
+     +---+ +--+        +--+  +-----------+       +--+     +---+
+            /\          |                          |
+           /  \         |                  +------------+
+          /    \        |                  |HARBOR GUARD|
+         /      \       |                  +------------+
+    +-----+ +-----+   +-----+ +----+
+    |FIRE | |ADMIN|   |PARKS| |FIRE|
+    +-----+ +-----+   +-----+ +----+
+   ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+
+   2.1  State Codes
+
+   The state codes are the two letter US Postal abbreviations. For
+   example: "CA" California.
+
+   2.2  Locality Names
+
+   Within the state name space there are "locality" names, some may be
+   cities, some may be counties, some may be local names, but not
+   incorporated entities.
+
+   Registered names under "locality" could be like:
+
+     <hostname>.CI.<locality>.<state>.US   ==>  city gov't agency
+     <hostname>.CO.<locality>.<state>.US,  ==>  county gov't agency
+     <hostname>.<locality>.<state>.US      ==>  businesses
+
+   In the cases where the locality name is a county, there is a branch
+   under the locality name, called "county" or "CO", that is used by the
+   county government.  Businesses are registered directly under the
+   locality name.
+
+
+
+
+Cooper & Postel                                                 [Page 8]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+   Under the city locality name space there is a "city" or "CI" branch
+   for city government agencies.  As usual, businesses and private
+   schools may register directly under the city name.
+
+   In the case where there is both a county and a city with the same
+   locality name there is no problem, since the names will be unique
+   with the "CO" or "CI" keyword.  In our area the county has a fire
+   department and the city has its own fire department.  They could have
+   names like:
+
+      Fire-Dept.CI.Los-Angeles.CA.US
+      Fire-Dept.CO.Los-Angeles.CA.US
+
+   Cities may be named (designated) by their full name (spelled out with
+   hyphens replacing spaces (e.g., Los-Angeles or Fort-Collins), or by a
+   city code.  The first choice is the full city name.  In some cases it
+   may be appropriate to use the well-known city abbreviation known
+   throughout a locality.  However, it is very desirable that all users
+   in the same city use the same designator for the city.  That is, any
+   particular locality should have just one DNS name.
+
+   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 hostname.  Cities and counties are used.
+
+   Should all the names be obvious?  Trying to do this is desirable and
+   also impossible.  There will come a point when the obviously right
+   name for an organization is already taken.  As the system grows this
+   will happen with increasing frequency.  While ease of use to the end
+   user is desirable, a higher priority must be placed on having a
+   system that operates.  This means that the manageability of the
+   system must have high consideration.
+
+   The reason the DNS was created was to subdivide the problem of
+   maintaining a list of hosts in the Internet into manageable portions.
+
+   The happy result is that this subdivision makes name uniqueness
+   easier and promotes logical grouping.  What is a "logical grouping"
+   though, always depends on the viewer.
+
+   Many levels of delegation are needed to keep the zone files
+   manageable.  Many sections of the name space are needed to allow
+   unique names to be easily added.
+
+
+
+
+
+
+Cooper & Postel                                                 [Page 9]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+   Way back in the olden days, when the Internet was invented, some
+   thought that an 8-bit network number would be more than enough to
+   number all the networks that would ever exist.  Today, there are over
+   10,000 networks operating in the Internet, and arguments are made
+   about the doubling time being 2 years versus 4 years.
+
+   One concern is that things will continue to grow dramatically, and
+   this will require more subdivision of the domain name management.
+   Maybe the plan for the US Domain is overkill on growth planning, but
+   there has never been overplanning for growth yet.
+
+   When things are bigger, names have to be longer.  There is an
+   argument that with only 8-character names, and in each position allow
+   a-z, 0-9, and -, you get 37**8 = 3,512,479,453,921 or 3.5 trillion
+   possible names.  It is a great argument, but how many of us want
+   names like "xs4gp-7q".  It is like license plate numbers, sure some
+   people get the name they want on a vanity plate, but a lot more
+   people who want something specific on a vanity plate can't get it
+   because someone else got it first.  Structure and longer names also
+   let more people get their "obviously right" name.
+
+   2.3  Schools
+
+   K12 schools are connecting to the Internet and registering in the
+   Internet DNS.  A decision has been made by the IANA (after
+   consultation with the new InterNIC Internet Registry and the Federal
+   Networking Council (FNC)) to direct these school registrations to the
+   US domain using the naming structure described here.
+
+   There is a need for competent, experienced, volunteers to come
+   forward to act as third and perhaps fourth level registries and to
+   operate delegated portions of the DNS.
+
+   There are two reasons for registering schools in the US Domain.  (1)
+   uniqueness of names, and (2) management of the database.
+
+     1. Name Uniqueness:
+
+        There are many "Washington" high schools, only one can be
+        "Washington.EDU" (actually none can be, since that name is used
+        by a University.  There will be many name conflicts if all
+        schools attempt to register directly under EDU.
+
+        In addition, 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
+
+
+
+Cooper & Postel                                                [Page 10]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+        when they are needed, if the school's name is unique without
+        such keywords, don't use them.
+
+     2. Database Management:
+
+        One goal of the DNS is to divide up the management of the name
+        database in to small pieces.  Each piece (or "zone" in DNS
+        terminology) could be managed by a distinct administrator.
+        Adding all the high schools to the EDU domain will make the
+        already large zone file for EDU even larger, possibly to the
+        point of being unmanageable.
+
+   For both these reasons it is necessary to introduce structure into
+   names.  Structure provides a basis for making common names unique in
+   context, and for dividing the management responsibility.
+
+      The US Domain has a framework established and has registered many
+      schools already in this structured scheme.  The general form is:
+
+         <school>.<district>.K12.<state>.US.
+
+            For example: Hamilton.LA-Unified.K12.CA.US
+
+   Public schools are usually organized by districts which can be larger
+   or smaller than a city or county.  For example, the Portland school
+   district in Oregon, is in three or four counties.  Each of those
+   counties also has non-Portland districts.
+
+   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.
+
+   For example, typical K12 school names currently used are:
+
+              IVY.PRS.K12.NJ.US
+              DMHS.JCPS.K12.KY.US
+              OHS.EUNION.K12.CA.US
+              BOHS.BREA.K12.CA.US
+
+   These names are generally longer than the old alternative of shorter
+   names in the EDU domain, but that would not have lasted long without
+   a significant number of schools finding that their "obviously
+   correct" name has already been used by some other school.
+
+
+
+
+
+
+
+Cooper & Postel                                                [Page 11]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+   When there are many things to name some of the names will 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
+
+   If a school has a number 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
+                ...
+
+   The K12 subdomain provides two points at which to delegate a branch
+   of the database to distinct administrators -- the K12 Administrator
+   for each state, and the district administrator for each district
+   within a state.
+
+   The US Domain Administrator will delegate a branch of the US domain
+   to an appropriate party.  In some cases, this may be a particular
+   school, a school district, or ever all of K12 for a state.
+
+   The responsibility for managing a K12 branch or sub-branch may be
+   delegated to an appropriate volunteer.  We envision that such
+   delegations of the schools' DNS service may eventually migrate to
+   someone else "more appropriate" from an administrative organizational
+   point of view.  The "obvious" state agency to manage the schools' DNS
+   branch may take some time to get up to speed on Internetting.  In the
+   meantime, we can have the more advanced schools up and running.
+
+   Special Schools and Service Units
+
+   In many states, there are special schools that are not in districts
+   that are run directly by the state or by consortiums.  There are also
+   service units that provide "educational services" ranging from books
+   and computers to janitorial supplies and building maintenance.  Often
+   these service units do not have a one-to-one relationship with
+   districts.
+
+   There is some concern about naming these schools and service units
+   within the naming structure for schools established in this memo.
+   There are several possibilities.  For a state with many service units
+   creating a "pseudo district" ESU (or whatever, the common terminology
+   is in that state) is a possibility.  For example, the Johnson service
+   unit could be JOHNSON.ESU.K12.CA.US.  For a state with a few such
+   service units (and avoiding conflicts with district names) the
+   service units could be directly under K12.  For example,
+
+
+
+Cooper & Postel                                                [Page 12]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+   TIES.K12.MN.US.
+
+   The special public funded schools can be handled in a similar
+   fashion.  If there are many special schools in a state, a "pseudo
+   district" should be established and all the special schools listed
+   under it.  For example, suppose there is a "pseudo district" in
+   Massachusetts called SPCL, and there is a special school called the
+   Progressive Computer Institute, then that school could have the name
+   PCI.SPCL.K12.MA.US.  If there are only a few special schools, they
+   can be listed directly under K12 (avoiding name conflicts with
+   district names).  For example, the California Academy of Math and
+   Science is CAMS.K12.CA.US.  CAMS is sponsored by seven schools, the
+   California Department of Education, and a University.
+
+   "PVT" Private Schools
+
+   Private schools may be thought of as businesses.  Public schools are
+   in districts, and districts provide a natural organizational
+   structure for naming and delegation.  For private schools there are
+   no districts and they really do operate like businesses.  But, many
+   people are upset to think about their children in a private school
+   being in a business category and not in K12 with the rest of the
+   children.  To accommodate both public and private schools, in each
+   state's K12 branch, we've added an artificial district called private
+   or "PVT".  This gives a private school the option of registering like
+   a business under "locality" or in the PVT.K12.<state-code>.US branch.
+
+   For example:
+
+      Crossroads.PVT.K12.CA.US
+      Crossroads-Santa-Monica.CA.US
+
+   A public school "Oak High" in the "Woodward" school district in
+   California would have a name like "Oak-High.Woodward.K12.CA.US".
+
+   A private school "Old Trail" in Pasadena, California could have the
+   <locality> based name "Old-Trail.Pasadena.CA.US" or the private
+   school base name "Old-Trail.PVT.K12.CA.US".
+
+   Some suggest that for private schools instead of a special pseudo
+   district PVT to use a locality name.  One reason to use district
+   names is that, in time, it seems likely that school district
+   administrators will take over the operation of the DNS for their
+   district.  One needs to be able to delegate at that branch point.
+   One implication of delegation is that the delegatee is now in charge
+   of a chunk of the name space and will be registering new names. To
+   keep names unique one can't have two different people registering new
+   things below identically named branches.
+
+
+
+Cooper & Postel                                                [Page 13]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+   For example, if there is a school district named Pasadena and a city
+   named Pasadena, the branch of the name space PASADENA.K12.CA.US might
+   be delegated to the administrator of that public school district.  If
+   a private school in Pasadena wanted to be registered in the DNS, it
+   would have to get the public school district administrator to do it
+   (perhaps unlikely) or not be in the K12 branch at all (unless there
+   is the PVT pseudo district).
+
+   So, if private schools are registered by
+   <school>.<locality>.K12.<state-code>.US and public schools are
+   registered by <school>.<district>.K12.<state-code>.US, there can't be
+   any locality names that are the same as district names or the
+   delegation of these will get very tricky later.
+
+   If it is all done by locality names rather than district names, and
+   public and private schools are mixed together, then finding an
+   appropriate party to delegate the locality to may be difficult.
+
+   Another suggestion was that private schools be registered directly
+   under K12, while public schools must be under a district under K12.
+   This would require the operator of the K12 branch to register all
+   districts and private schools himself (checking for name uniqueness),
+   he couldn't easily delegate the registration of the private schools
+   to anyone else.
+
+   Community Colleges and Technical Schools
+
+   To distinguish Community Colleges and Technical/Vocational schools,
+   the keywords "CC" and "TEC" have been created.
+
+   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
+   TECMCC.CC.CA.US                           <== a community college
+   Brick-and-Basket-Institute.TEC.CA.US      <== a technical college
+   Northridge.CSU.STATE.CA.US                <== a state university
+
+
+
+
+
+
+
+
+
+
+
+Cooper & Postel                                                [Page 14]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+   2.4  State Agencies
+
+   Several states are setting up networks to interconnect the offices of
+   state government agencies.  The hosts in such networks should be
+   registered under the STATE.<state-code>.US branch.
+
+   A US Domain name space has been established for the state government
+   agencies.  For example, in the State of Minnesota, the subdomain is
+   STATE.MN.US.
+
+      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
+
+   2.5  Federal Agencies
+
+   A federal name space has been established for 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
+
+   2.6  Distributed National Institutes
+
+   The "DNI" branch was created directly under the top-level US.  This
+   is to be used for organizations that span state, regional, and other
+   organizational boundaries; are national in scope, and have
+   distributed facilities.  An example would be:
+
+      Distributed National Institutes:
+      --------------------------------
+
+      MetaCenter.DNI.US   <====  The MetaCenter Supercomputer Centers
+
+
+
+
+
+
+Cooper & Postel                                                [Page 15]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+   The MetaCenter domain encompasses the four NSF sponsored
+   supercomputer centers. These are:
+
+       San Diego Supercomputer Center (SDSC)
+       National Center for Supercomputing Applications (NCSA)
+       Pittsburgh Supercomputing Center (PSC)
+       Cornell Theory Center (CTC)
+
+   The MetaCenter Network will enable applications and services like
+   file systems and archival storage to be operated in a distributed
+   fashion; thus, allowing the resources at the four centers to appear
+   integrated and "seamless" to users of the centers.
+
+   2.7  General Independent Entities
+
+   This name space was created for organizations that don't really fit
+   anywhere else, such as state-wide associations, clubs, and "domain
+   parks".  Think of this as the miscellaneous category.
+
+   The examples are state-wide clubs.  For example, the Garden Club of
+   Arizona, might want to be "GARDEN.GEN.AZ.US".  Such a club has
+   membership from all over the state and is not associated with any one
+   city (or locality).  Another example is "domain parks" that have been
+   established up-to-now as entities in ORG.  For example, there is
+   "LONESTAR.ORG", which is a kind of computer club in Texas that has
+   lots of dial-in computers registered.  In the US Domain such an
+   entity might have a name like "LONESTAR.GEN.TX.US".
+
+   The organizations registered in GEN may typically be non-profit
+   entities.  These organizations don't fit in a <locality> and are not
+   a school, library, or state agency.  Ordinary businesses are not
+   registered in GEN.
+
+   Some suggest that these kinds of organizations are just like all the
+   other things and ought to be registered under some <locality>.  This
+   may be true, but sometimes one just can't find any way to convince
+   the applicant that it is the right thing to do.  One can argue that
+   any organization has to have a headquarters, or an office, or
+   something about it that is in a fixed place, and thus the
+   organization could be registered in that place.
+
+   Some suggest that no token is needed, these entities could be
+   directly under the <state-code>.  The problem with not having a
+   token, is that you can't delegate the responsibility for registering
+   these entities to someone separate from whoever is responsible for
+   the <state-code>.  You want to be able to delegate for both name-
+   uniqueness reasons, and operational management reasons.  Having a
+   token there makes both easy.
+
+
+
+Cooper & Postel                                                [Page 16]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+      General Independent Entities:
+      -----------------------------
+
+      CAL-Comp-Club.GEN.CA.US   <====  The Computer Club of California
+
+      2.8  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
+
+      For large entities like large corporations with multiple
+      facilities in several cities or states this often seems like an
+      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. Example: IBM.Armonk.NY.US
+
+      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
+      MNPL.FRB.FED.US.     <====  US Fed. Reserve Bank of Minneapolis
+
+
+
+
+
+
+
+
+
+
+Cooper & Postel                                                [Page 17]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+      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
+
+      DNI  (distributed national Institutes)
+      ======================================
+
+      METACENTER.DNI.US       <==== a distributed nat'l Inst.
+
+
+      GEN (General Independent Entities)
+      ==================================
+
+      GARDEN.GEN.AZ.US        <==== a garden club of Arizona
+
+
+      CITY | CI | COUNTY | CO (locality)
+      ==================================
+
+      Parks.CI.Culver-City.CA.US          <====  a city department
+      Fire-Dept.CI.Los-Angeles.CA.US      <====  a city department
+      Fire-Dept.CO.Los-Angeles.CA.US      <====  a county department
+      Planning.CO.Fulton.GA.US.           <====  a county department
+      Main.Library.CI.Los-Angeles.CA.US   <====  a city department
+      MDR.Library.CO.Los-Angeles.CA.US    <====  a county department
+
+
+      TOWNSHIP | PARISH (locality)
+      ============================
+
+      Police.TOWNSHIP.Green.OH.US           <====  a township department
+      Administration.PARISH.Lafayette.LA.US <====  a parish department
+
+
+
+
+
+
+
+
+
+
+
+Cooper & Postel                                                [Page 18]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+      DISTRICT | LIBRARY  (agency)
+      ============================
+
+      SCAQMD.DISTRICT.CA.US                 <====  a regional district
+      Bunker-Hill-Improvement.DISTRICT.LA.CA.US <====  a local district
+
+      Huntington.LIB.CA.US                  <====  a private library
+      Venice.LA-City.LIB.CA.US              <====  a city library
+      MDR.LA-County.LIB.CA.US               <====  a county library
+
+      K12 | PRIVATE SCHOOLS (PVT) | CC | TEC
+      ======================================
+
+      Hamilton.High.LA-Unified.K12.CA.US      <====  a public 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
+      Culver-High.CCSD.K12.CA.US              <====  a public K12 school
+
+      St-Monica.High.Santa-Monica.CA.US       <====  a private school
+      Crossroads-School.Santa-Monica.CA.US    <====  a private school
+      Mary-Ellens.Montessori-School.LA.CA.US  <====  a private school
+      Progress-Learning-Center.PVT.K12.CA.US  <====  a private school
+
+      SMCC.Santa-Monica.CC.CA.US      <====  a public community college
+      Trade-Tech.Los-Angeles.CC.CA.US <====  a public community college
+      Valley.Los-Angeles.CC.CA.US     <====  a public community college
+
+      Brick-and-Basket-Institute.TEC.CA.US    <== a technical college
+
+
+      When appropriate, subdomains are delegated and partioned in
+      various categories, such as:
+
+       <locality>.<state>.US   =   city/locality based names
+              K12.<state>.US   =   kindergarten thru 12th grade
+           PVT.K12.<state.US   =   private kindergarten thru 12th grade
+               CC.<state>.US   =   community colleges
+              TEC.<state>.US   =   technical or vocational schools
+              LIB.<state>.US   =   libraries
+            STATE.<state>.US   =   state government agencies
+           <org-name>.FED.US   =   federal government agencies
+           <org-name>.DNI.US   =   distributed national institutes
+      <org-name>.GEN.<state>.US. = statewide assoc,clubs,domain parks
+
+      The Appendix-I contains the current US Domain Names BNF.
+
+
+
+
+
+
+Cooper & Postel                                                [Page 19]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+3. REGISTRATION
+
+   There are two types of registrations (1) Delegation, where a branch
+   of the US Domain is delegated to an organization running name servers
+   to support that branch; or (2) Direct Registration, in which the
+   information is put directly into the main database.
+
+   In Direct Registration there are two cases: (a) an IP-host (with an
+   IP address), and (b) non-IP host (for example, a UUCP host).  Any
+   particular registration will involve any one of these three
+   situations.
+
+   3.1  Requirements
+
+   Anyone requesting to register a host in the US Domain is sent a copy
+   of the "Instructions for the US Domain Template", and must fill out a
+   US Domain template.
+
+   The US Domain template, is similar to the InterNIC Domain template,
+   but it is not the same.  To request a copy of the US Domain template,
+   send a message to the US Domain registrar (us-domain@isi.edu).
+
+   If you are registering a name in a delegated zone, please register
+   with the contact for that zone.  You can FTP the file "in-notes/us-
+   domain-delegated.txt" from venera.isi.edu, via anonymous FTP.  This
+   information is also available via email from RFC-INFO@ISI.EDU
+   (include as the only text in the message
+   "Help: us_domain_delegated_domains").
+
+   The key people must have electronic mailboxes (that work).  Please
+   provide all the information indicated in the "Administrator" and
+   "Technical Contact" slots.
+
+   The administrator 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 email
+   address.  This is necessary in case something goes wrong.
+
+   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.
+
+
+
+Cooper & Postel                                                [Page 20]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+   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, the turn around time for registering a host
+   is usually a few days.  The name servers 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.  You may 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.  Or,
+   you may send the form directly to the manager of a delegated zone
+   (see Section 3.1).
+
+   3.2.1 IP-Hosts
+
+   These are hosts with IP addresses which correspond to "A" records in
+   the DNS database.
+
+   3.2.2 Non-IP 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
+   acceptable.  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 as 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 21]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+   The example below 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. (See Section 4.4. Wildcards).
+
+           For example:          bah.rochester.ny.us
+                           host1.bah.rochester.ny.us
+                           host2.bah.rochester.ny.us
+
+   To use US Domain names for non-IP hosts, there must be a forwarder
+   host that is an IP host.  There must be an administrative 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
+   this:
+          "your-host"  MX  10  "forwarder"
+
+
+
+Cooper & Postel                                                [Page 22]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+   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 23]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+   3.3  Delegated Subdomains
+
+   Many branches of the US Domain are delegated. There must be a
+   knowledgeable and competent technical contact, familiar with the
+   Internet DNS.  This requirement is easily satisified if the technical
+   contact already runs some other name servers.
+
+   Examples of delegations are K12.TX.US for the Kindergarten through
+   12th Grade public schools in Texas, the locality "berkeley.ca.us", or
+   the LIB.MN.US branch for the libraries in Minnesota.
+
+   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.
+
+   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 an equitable, just, honest, and competent job.
+
+   The key requirement is that for each domain there be a designated
+   manager for supervising that domain's name space.
+
+   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 domain for the domain
+   itself 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.
+
+   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 nondiscriminatory 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 beyond the requirements on
+   higher-level domains themselves.  That is, the requirements are
+   applied recursively.  In particular, all subdomains shall be allowed
+
+
+
+Cooper & Postel                                                [Page 24]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+   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).
+
+   Significantly interested parties in the domain should agree that the
+   designated manager is the appropriate party.
+
+   The US Domain Administrator 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 neglected their
+   responsibilities would the US Domain Administrator step in.
+
+   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 name servers must be done with
+   technical competence.  This includes keeping the US Domain
+   Administrator or other higher-level domain managers 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 name server that have IP
+   connectivity to the Internet and can be easily checked for
+   operational status and database accuracy by the US Domain
+   Administrator.
+
+   One of the aspects of having two name servers for each domain (or
+   zone), is for robustness.  One concern under this heading is that the
+   name service not go out entirely if there is a local power failure
+   (earthquake, tornado, or other disaster).
+
+   Name Servers should be in distinctly separate physical locations.  It
+   is appropriate to have more than two name servers, but there must be
+   at least two.
+
+   For any transfer of the designated manager trusteeship from one
+   organization to another, the higher-level domain manager must receive
+   communications from both the old organization and the new
+   organization that assures the US Domain Administrator that the
+   transfer in mutually agreed, and that the new organization
+   understands its responsibilities.
+
+   It is also very helpful for the US Domain Administrator to receive
+   communications from other parties that may be concerned or affected
+   by the transfer.
+
+
+
+
+Cooper & Postel                                                [Page 25]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+   Delegation of cities, companies within cities, schools (K12),
+   community colleges (CC), libraries (LIB), state government (STATE),
+   and federal government agencies (FED), etc., is acceptable and
+   practical.
+
+   For a delegated portion of the name space, 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 acceptable.
+
+   Delegation of the whole State name space is not yet implemented.  The
+   delegated part of the name space is in the form of:
+
+               .<locality>.<state>.US.
+            .CI.<locality>.<state>.US.
+            .CO.<locality>.<state>.US.
+                    .STATE.<state>.US.
+                      .K12.<state>.US.
+                   PVT.K12.<state>.US.
+                       .CC.<state>.US.
+                      .TEC.<state>.US.
+                      .LIB.<state>.US.
+                      .GEN.<state>.US.
+                              .DNI.US.
+                              .FED.US.
+
+   3.3.1.  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 DNS.  This requirement is easily
+          satisified if the technical contact already runs some other
+          name servers.
+
+
+
+
+
+Cooper & Postel                                                [Page 26]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+      2)  Organizations requesting delegations must provide at least two
+          independent (robust and reliable) DNS name servers in
+          physically separate locations on the Internet.
+
+      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).
+
+      5)  The subdomain manager must tell the US Domain Administrator
+          when there are changes in the name servers that should be
+          reflected in the US Domain zone files, or changes in the
+          contact information.
+
+   K12 Administrators
+
+      In the long term, registering schools will be a big job.  So you
+      need to have in mind delegating parts of the work to various
+      school districts.  If you can delegate every school district in
+      the state then you are finished, except for checking that they are
+      all operating correctly.  However, initially you will have quite a
+      bit to do with educating people, helping them choose names and
+      getting name servers arranged.  You are responsible for seeing
+      that the naming of schools follow the guidelines suggested in this
+      memo.
+
+      All K12 Administrators will initially be responsible for managing
+      the "pseudo district" PVT for private schools.  Private schools
+      have the option of registering as <school-name>.PVT.K12.<state>.US
+      or as a business under the city based names.
+
+   Locality Administrators
+
+      If you have been delegated a locality subdomain, you will be
+      responsible for registering not only businesses directly under the
+      locality, but city and county agencies under the "CI" and "CO"
+      branches.  When appropriate these branches should be delegated.
+
+      If you want, you may spell out "CITY" instead of "CI" or "COUNTY"
+      instead of "CO", but you must be consistent and use only one or
+      the other in a given locality.  The whole city government should
+      be under one branch.
+
+
+
+
+
+
+Cooper & Postel                                                [Page 27]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+   WHOIS Database
+
+      Only the second and third level delegated name spaces will be
+      entered in the WHOIS database.  For example, K12.CA.US would have
+      an entry in WHOIS.  Anything under K12.CA.US will not be listed.
+      The US Domain Administrator will send the information that you
+      supplied on your US Domain template to the InterNIC.  It is the
+      hope that in the future, each delegated subdomain will provide
+      their own WHOIS directory database for their branch.
+
+   3.3.2  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.  Two contacts with email
+          addresses are necessary in case something goes wrong.
+
+      2)  Add the new technical contact to the "us-dom-adm" mailing list
+          for distributing updates concerning the US Domain policies and
+          procedures.
+
+      3)  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.
+
+      4)  Send them a copy of the zone file so their initial zone file
+          is identical to ours. For example:
+
+          mil.wi.us.      69582   SOA     spool.mu.edu.
+                                          manager.spool.mu.edu. (
+                                  930119  ;serial
+                                  28800   ;refresh
+                                  14400   ;retry
+                                  3600000 ;expire
+                                  86400 ) ;minim
+
+          mil.wi.us.      69582   NS      spool.mu.edu.
+          spool.mu.edu.   85483   A       134.48.1.31
+          mil.wi.us.      69582   NS      sophie.mscs.mu.edu.
+          sophie.mscs.mu.edu.     85483   A       134.48.4.6
+          solaria.mil.wi.us.      69582   HINFO   Sun 3/60 SunOs
+          solaria.mil.wi.us.      69582   MX      10 spool.mu.edu.
+          nthomas.mil.wi.us.      69582   HINFO   386 Clone DOS
+          nthomas.mil.wi.us.      69582   MX      10 spool.mu.edu.
+
+
+
+Cooper & Postel                                                [Page 28]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+          rwmke.mil.wi.us.        69582   HINFO   UNIX PC UNIX
+          rwmke.mil.wi.us.        69582   MX      10 spool.mu.edu.
+          milestn.mil.wi.us.      69582   MX      10 spool.mu.edu.
+          nrunner.mil.wi.us.      69582   HINFO   MacIntosh System 7
+          nrunner.mil.wi.us.      69582   MX      10 spool.mu.edu.
+          dawley.mil.wi.us.       69582   HINFO   386 Clone DOS
+          dawley.mil.wi.us.       69582   MX      10 spool.mu.edu.
+            ...
+
+      5)  The US Domain zone file must have the following records,
+          showing the name, address, email, and phone number of the
+          technical contact for the delegated subdomain and the name of
+          the delegated name space and the names of the name servers.
+
+            ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
+            ;
+            ;Contact:  Joseph Klein (tjk@spool.mu.edu)
+            ;          Marquette University
+            ;          (414) 288-6734
+            ;
+            ;Delegate mil.wi.us zone
+
+            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.
+            ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
+
+      6)  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.
+
+      7)  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.
+
+      8)  Make sure each administrator has a copy of this RFC and
+          follows the guidelines set forth.
+
+   3.3.3   Subdomain Contacts
+
+   The number of hosts registered under each subdomain is unknown. See
+   Section 3.1 for information on the delegated domains and the
+   contacts.
+
+
+
+Cooper & Postel                                                [Page 29]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+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.
+
+   The US Domain is currently supported by seven name servers:
+
+           venera.isi.edu
+           ns.isi.edu
+           rs.internic.net
+           ns.csl.sri.com
+           ns.uu.net
+           adm.brl.mil
+           excalibur.usc.edu
+
+   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).
+
+
+
+Cooper & Postel                                                [Page 30]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+        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 name
+   servers 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
+
+   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
+
+
+
+
+
+
+
+
+
+Cooper & Postel                                                [Page 31]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+Cooper & Postel                                                [Page 32]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+   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.
+
+   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 STD 2, RFC 1340 [9].  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)
+
+
+
+
+
+Cooper & Postel                                                [Page 33]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+   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
+   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.
+
+
+
+
+
+
+
+
+Cooper & Postel                                                [Page 34]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+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.
+
+   [7]  Albitz, P., C. Liu, "DNS and Bind" Help for UNIX System
+        Administrators, O'Reilly and Associates, Inc., October 1992.
+
+   [8]  ACM SIGUCCS Networking Taskforce, "Connecting to the Internet -
+        What Connecting Institutions Should Anticipate", FYI 16,
+        RFC 1359, August 1992.
+
+   [9]  Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
+        RFC 1340, ISI, July 1992.
+
+6. Security Considerations
+
+   Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cooper & Postel                                                [Page 35]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+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 36]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+                     APPENDIX-I:  US DOMAIN NAMES BNF
+                     ================================
+
+   <us-domain-name>    ::= <us-name><dot><us>
+
+   <us-name>           ::= <state-name><dot><state-code> |
+                           <fed-name><dot><fed>
+                           <dni-name><dot><dni>
+
+   <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>
+
+   <dni-name>          ::= <the dotted hierarchical name of a
+                            distributed national institution>
+
+   <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><local-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>
+
+
+
+
+
+
+
+Cooper & Postel                                                [Page 37]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+   <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>
+
+   <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> ::= "CI" | "CITY"
+
+   <county> ::= "CO" | "COUNTY" | "TOWNSHIP" | "PARISH"
+
+   <dot> ::= "."
+
+   <fed> ::= "FED"
+
+   <dni> ::= "DNI"
+
+   <state> ::= "STATE" | "COMMONWEALTH"
+
+   <agency> ::= "AGENCY" | "DISTRICT" | "K12" | "CC" | "LIB" |
+                "GEN"    | "TEC"
+
+   <local-agency> ::= "AGENCY" | "DISTRICT"
+
+   <us> ::= "US"
+
+
+   Notes:
+
+   Within States:
+
+   "K12" may be used for public school districts.  A special name
+   "PVT" can be used in the place of a school district name for
+   private schools.
+
+   "CC" may be used only for public community colleges.
+
+
+
+
+Cooper & Postel                                                [Page 38]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+   "LIB" may be only used by libraries.
+
+   "TEC" is used only for technical and vocational schools and colleges.
+
+   "GEN" is for general independent entities, that is, organizations
+   that don't really fit anywhere else (such as statewide associations,
+   clubs, and "domain parks").
+
+   "STATE" may be used only for state government entities.
+
+   Below US, parallel to States:
+
+   "FED" is for agencies of the federal government.
+
+   "DNI" is for distributed national institutes; organizations that
+   span state, regional, and other organizational boundaries; that
+   are national in scope, and have distributed facilities.
+
+   Examples:
+   =========
+
+   Geo-Petrellis.Culver-City.CA.US         <== resturant
+
+   Joe-Josts.Long-Beach.CA.US              <== bar
+
+   IBM.Armonk.NY.US                        <== business
+
+   Camp-Curry.Yosemite.CA.US               <== business
+
+   Yosemite.NPS.Interior.FED.US            <== federal agency
+
+   Senate.FED.US                           <== US Senate
+
+   DOD.FED.US                              <== US Defense Dept.
+
+   DOT.FED.US                              <== US Transportation Dept.
+
+   MNPL.FRB.FED.US                         <== the Minneapolis branch of
+                                               the Federal Reserve Bank
+
+   MetaCenter.DNI.US                       <== distributed Nat'l Inst
+
+   Senate.STATE.MN.US                      <== state Senate
+
+   House.STATE.MN.US                       <== state House of Reps
+
+   Assembly.STATE.CA.US                    <== state Assembly
+
+
+
+
+Cooper & Postel                                                [Page 39]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+   MDH.STATE.MN.US                         <== state Health 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             <== local office of DMV
+
+   Police.CI.Culver-City.CA.US             <== city department
+
+   Fire-Dept.CI.Los-Angeles.CA.US          <== city department
+
+   Fire-Dept.CO.Los-Angeles.CA.US          <== county department
+
+   Main.Library.CI.Los-Angeles.CA.US       <== city department
+
+   MDR.Library.CO.Los-Angeles.CA.US        <== county department
+
+   Huntington.LIB.CA.US                    <== private library
+
+   SMCC.Santa-Monica.CC.CA.US              <== public community college
+
+   Trade-Tech.Los-Angeles.CC.CA.US         <== public community college
+
+   Valley.Los-Angeles.CC.CA.US             <== public community college
+
+   Hamilton.High.LA-Unified.K12.CA.US      <== public school
+
+   Sherman-Oaks.Elem.LA-Unified.K12.CA.US  <== public school
+
+   John-Muir.Middle.Santa-Monica.K12.CA.US <== public school
+
+   St-Monicas.High.Santa-Monica.CA.US      <== private school
+
+   Crossroads-School.Santa-Monica.CA.US    <== private school
+
+   Mary-Ellens-Montessori-School.LA.CA.US  <== private school
+
+   Progress-Learning-Center.PVT.K12.CA.US  <== private school
+
+   Brick-and-Basket-Institute.TEC.CA.US    <== technical college
+
+   Bunker-Hill.DISTRICT.Los-Angeles.CA.US  <== local district
+
+   SCAQMD.DISTRICT.CA.US                   <== regional district
+
+
+
+
+Cooper & Postel                                                [Page 40]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+   Berkeley.UC.STATE.CA.US                 <== "CAL"
+
+   Los-Angeles.UC.STATE.CA.US              <== UCLA
+
+   Irvine.UC.STATE.CA.US                   <== UC Irvine
+
+   Northridge.CSU.STATE.CA.US              <== CSUN
+
+   Los-Angeles.CSU.STATE.CA.US             <== Cal State LA
+
+   Leland-Stanford-Jr-University.Stanford.CA.US    <== private school
+
+   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cooper & Postel                                                [Page 41]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+            APPENDIX-II: US DOMAIN QUESTIONNAIRE FOR HOST ENTRY
+
+
+To register a host in the US domain, the US Domain Template must be
+sent to the US Domain Registrar (US-Domain@ISI.EDU).  The first few
+pages explain each question on the attached template.  FILL OUT THE
+TWO PAGE TEMPLATE AT THE END.  Questions may be sent by electronic
+mail to the above address, or by phone to Ann Cooper, USC/Information
+Sciences Institute, (310) 822-1511.
+
+(1)  Please specify whether this is a new application, modification to
+     an existing registration, or deletion.
+
+
+(2)  The name of the domain.  This is the name that will be used in
+     tables and lists associating the domain with the domain server
+     addresses. See RFC 1480 - The US Domain for more details.
+
+ <host>.<city/locality>.<state>.US. =  city/locality based names
+<school>.<district>.K12.<state>.US. =  kindergarten thru 12th grade
+       <school>.PVT.K12.<state>.US. =  private K thru 12th grade
+    <school>.<locality>.<state>.US. =  PVT sch opt: locality names
+            <school>.CC.<state>.US. =  community colleges
+           <school>.TEC.<state>.US. =  technical or vocational schools
+         <lib-name>.LIB.<state>.US. =  libraries
+       <org-name>.STATE.<state>.US. =  state government agencies
+                 <org-name>.FED.US. =  federal government agencies
+                 <org-name>.DNI.US. =  distributed national institutes
+            <org>.GEN.<state>.US. =  statewide assoc,clubs,domain parks
+
+     For example:  networthy.santa-clara.ca.us.
+
+
+(3)  The name of the entity represented, that is, the organization
+     being named.  For example: The Networthy Corporation. Not the
+     name of the organization submitting the request.
+
+
+(4)  Please describe the domain 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.
+
+
+(5)  The date you expect the domain to be fully operational.
+
+
+
+Cooper & Postel                                                [Page 42]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+For every registration, we need both the Administrative and the
+Technical contacts of a domain (questions 6 & 7) and we MUST have a
+network mailbox for each.  If you have a NIC handle (a unique NIC
+database identifier) please enter it.  (If you don't know what a NIC
+handle is leave it blank).  Also the title, mailing address, phone
+number, organization, and network mailbox.
+
+(6)  The name of the administrative head of the "organization".  The
+     administrator is the contact point for administrative and policy
+     questions about the domain.  The Domain administrator should work
+     closely with the personnel he has designated as the "technical
+     contact" for his domain. In this example the Domain Administrator
+     would be the Administrator of the Networthy Corporation, not the
+     Administrator of the organization running the name server
+     (unless it is the same person).
+
+(7)  The name of the technical and zone contact.  The technical and
+     zone contact handles the technical aspects of maintaining the
+     domain's name server and resolver software, and database files.
+     He keeps the name server running. More than likely, this person
+     would be the technical contact running the primary name server.
+
+***********************************************************************
+
+PLEASE READ:  There are several types of registrations.
+
+   (a)  Delegation (i.e., a portion of the US Domain name space is
+        given to an organization running name servers to support that
+        branch; For example, K12.TX.US, for all K12 schools in Texas).
+        For (a) answer questions 8 and 9.
+
+   (b)  Direct Registration of an IP Host.
+        For (b) answer question 10.
+
+   (c)  Direct Registration of a non-IP Host.
+        For (c) answer question 11 and 12.
+
+***********************************************************************
+
+QUESTIONS FOR DELEGATIONS
+
+(8)  PRIMARY SERVER Information.  It is required to supply both the
+     Contact information as well as hardware/software information of
+     the primary name server.
+
+(9)* SECONDARY SERVER Information. It is required to supply the
+     hardware and software information of all secondary name servers.
+
+
+
+
+Cooper & Postel                                                [Page 43]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+Domains must provide at least two independent servers that provide the
+domain service for translating names to addresses for hosts in this
+domain. If you are applying for a domain and a network number
+assignment simultaneously and a host on your proposed network will be
+used as a server for the domain, you must wait until you receive your
+network number assignment and have given the server(s) a net- address
+before sending in the domain application. Establishing the servers in
+physically separate locations and on different PSNs and/or networks is
+strongly recommended.
+
+NOTE: For those applicants not able to run name servers, or for non-IP
+hosts the Name Server information is not applicable. (See #10 and #11).
+=======================================================================
+QUESTION FOR DIRECT IP HOSTS (If you answered 8 & 9 do not answer
+10, 11, or 12).
+
+(10) What Domain Name System (DNS) Resource Records (RR) and values are
+     to be entered for your IP host (must have an "A" record).
+
+     ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+     Example: RRs for an INTERNET hosts.
+
+     (a)  DOMAIN NAME (required)...:  Networthy.Santa-Clara.CA.US.
+     (b)  IP ADDRESS (required)....:  A  128.9.3.123  (required)
+     (c)  HARDWARE (opt)...........:  SUN-3/11O
+     (d)  OPERATING SYS (opt)......:  UNIX
+     (e)  WKS (opt)........:  128.9.3.123. UDP (echo tftp) TCP (ftp)
+     (f)  MX (opt).................:  10  RELAY.ISI.EDU.
+
+It is your responsibility to see that an IN-ADDR pointer record is
+entered in the DNS database.  (For Internet hosts only).  Contact the
+administrator of the IP network your host is on to have this done.
+The US Domain administration does not administer the network and
+cannot make these entries in the DNS database.
+
+=======================================================================
+QUESTIONS FOR NON-IP HOSTS (such as UUCP).
+
+   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, (see
+   RFC 1359 - Connecting to the Internet What Connecting Institutions
+   Should Anticipate, ACM SIGUCCS, August 1992). 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.
+
+
+
+Cooper & Postel                                                [Page 44]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+(11) Internet Forwarding Host Information
+
+     (11a) What is the name of your Internet forwarding host?
+           For example: The host Yacht-Club.MDR.CA.US uses
+           UUCP to connect to RELAY.ISI.EDU which is an Internet
+           host. (i.e., RELAY.ISI.EDU is the forwarding host).
+
+     (11b) What is the name of your contact person at forwarding host?
+           The Administrator of RELAY.ISI.EDU must agree to be the
+           forwarding host for Yacht-Club.MDR.CA.US, and the
+           forwarding host must know a delivery method and route to
+           Networthy.  No double MXing.
+
+     (11c) What is the mailbox of your contact?
+           What is the mailbox of the administrator of the forwarding
+           host.
+
+              Example:  Contact Name......:  John Smith
+                        Contact Email.....:  js@RELAY.ISI.EDU
+
+(12) What Domain Name System (DNS) Resource Records (RR) and values
+     are to be entered for your NON-IP host.
+
+     ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+     Example: RRs for a NON-IP host (uucp).
+
+     (a)  DOMAIN NAME (required).....:   Yacht-Club.MDR.CA.US.
+     (b)  HARDWARE (opt).............:   SUN-3/11O
+     (c)  OPERATING SYS (opt)........:   UNIX
+     (d)  MX (required)..............:   10  RELAY.ISI.EDU.
+     ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+
+
+
+PLEASE ALLOW AT LEAST 8 WORKING DAYS FOR PROCESSING THIS APPLICATION
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cooper & Postel                                                [Page 45]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+                          US DOMAIN TEMPLATE                    [6/93]
+
+PLEASE SUBMIT THE FOLLOWING TWO PAGE TEMPLATE TO (Us-Domain@isi.edu).
+Sections or fields of this form marked with an asterisk (*) may be
+copied as many times as necessary. (For example: If you had two phone
+numbers for the Administrative Contact, you would use the same number
+"6h" twice.  PLEASE DO NOT ALTER THIS APPLICATION IN ANY WAY.
+=====================================================================
+      1.   REGISTRATION TYPE
+           (N)ew (M)odify (D)elete..:
+
+      2.*  FULLY-QUALIFIED DOMAIN NAME:
+
+      3.   ORGANIZATION INFORMATION
+      3a.  Organization Name.....:
+      3b.  Address Line 1........:
+      3b.  Address Line 2........:
+      3c.  City..................:
+      3d.  State.................:
+      3e.  Zip/Code..............:
+
+      4.   DESCRIPTION OF ORG/DOMAIN:
+
+      5.   Date Operational......:
+
+      6.   ADMINISTRATIVE CONTACT OF ORG/DOMAIN
+      6a.  NIChandle (if known)..:
+      6b.  Whole Name............:
+      6c.  Organization Name.....:
+      6d.  Address Line 1........:
+      6d.  Address Line 2........:
+      6e.  City..................:
+      6f.  State.................:
+      6g.  Zip/Code..............:
+      6h.* Voice Phone...........:
+      6i.* Electronic Mailbox....:
+
+      7.   TECHNICAL AND ZONE CONTACT
+      7a.  NIChandle (if known)..:
+      7b.  Whole Name............:
+      7c.  Organization Name.....:
+      7d.  Address Line 1........:
+      7d.  Address Line 2........:
+      7e.  City..................:
+      7f.  State.................:
+      7g.  Zip/Code..............:
+      7h.* Voice Phone...........:
+      7i.* Electronic Mailbox....:
+
+
+
+Cooper & Postel                                                [Page 46]
+
+RFC 1480                     The US Domain                     June 1993
+
+
+FILL OUT QUESTIONS 8 AND 9 FOR DELEGATIONS ONLY (i.e., those
+organizations running name servers for a branch of the US Domain
+name space, for example:  k12.<state>.us).
+
+      8.   PRIMARY SERVER: CONTACT INFO, HOSTNAME, NETADDRESS
+      8a.  NIChandle (if known)..:
+      8b.  Whole Name............:
+      8c.  Organization Name.....:
+      8d.  Address Line 1........:
+      8d.  Address Line 2........:
+      8e.  City..................:
+      8f.  State.................:
+      8g.  Zip/Code..............:
+      8h.* Voice Phone...........:
+      8i.* Electronic Mailbox....:
+      8j.  Hostname..............:
+      8k.* IP Address............:
+      8l.* HARDWARE..............:
+      8m.* OPERATING SYS.........:
+
+      9. * SECONDARY SERVER: HOSTNAME, NETADDRESS
+      9a.* Hostname..............:
+      9b.* IP Address............:
+      9c.* HARDWARE..............:
+      9d.* OPERATING SYS.........:
+
+FILL OUT QUESTION 10 FOR DIRECT REGISTRATIONS IP HOSTS
+
+     10.   RESOURCE RECORDS (RRs) FOR IP INTERNET HOSTS
+     10a.  DOMAIN NAME...........:
+     10b.* IP ADDRESS (required).:
+     10c.  HARDWARE..............:
+     10d.  OPERATING SYS.........:
+     10e.  WKS ..................:
+     10f.* MX....................:
+
+FILL OUT QUESTIONS 11 AND 12 FOR NON-IP HOSTS (such as UUCP)
+
+     11.   FORWARDING HOST INFORMATION
+     11a.  Forwarding Host......:
+     11b.  Contact Name.........:
+     11c.  Contact Email........:
+
+     12.   RESOURCE RECORDS (RRs) FOR NON-IP HOSTS (UUCP)
+     12a.  DOMAIN NAME...........:
+     12b.  HARDWARE..............:
+     12c.  OPERATING SYS.........:
+     12d.* MX (required).........:
+
+
+
+Cooper & Postel                                                [Page 47]
+
\ No newline at end of file