path: root/doc/rfc/rfc1386.txt

Network Working Group                                          A. Cooper
Request for Comments: 1386                                     J. Postel
                                                           December 1992
                             The US Domain

Status of this Memo

   This memo provides information for the Internet community. It does
   not specify an Internet standard. Distribution of this memo is
   unlimited.

Table of Contents

   1.  Introduction ................................................  2
       1.1  The Internet Domain Name System.........................  2
       1.2  Top Level Domains.......................................  3
       1.3  The US Domain ..........................................  4
   2.  Naming Structure ............................................  4
       2.1  State Codes ............................................  5
       2.2  City Codes or Locality Names............................  5
       2.3  Examples of Names.......................................  5
   3.  Registration ................................................  8
       3.1  Requirements ...........................................  8
       3.2  Direct Entries .........................................  9
       3.2.1   UUCP Hosts ..........................................  9
       3.2.2   Non-IP Hosts ........................................ 10
       3.3  Delegated Subdomains ................................... 12
       3.3.1   Schools ............................................. 12
       3.3.2   State Agencies ...................................... 14
       3.3.3   Federal Agencies .................................... 14
       3.3.4   Delegation Requirement............................... 14
       3.3.5   Delegation Procedures ............................... 15
       3.3.6   Subdomain Contacts................................... 18
   4.  Database Information......................................... 19
       4.1  Name Servers ........................................... 19
       4.2  Zone files ............................................. 20
       4.3  Resource Records ....................................... 21
       4.3.1   A Records ........................................... 22
       4.3.2   CNAME Records ....................................... 22
       4.3.3   MX Records .......................................... 22
       4.3.4   HINFO Records ....................................... 23
       4.3.5   PTR Records ......................................... 23
       4.4  Wildcards .............................................. 23
   5.  References .................................................. 24
   6.  Security Considerations ..................................... 25
   7.  Author's Address ............................................ 25
   Appendix-I:  US Domain Names BNF................................. 26
   Appendix-II: US Domain Questionnaire for Host Entry.............. 28



Cooper & Postel                                                 [Page 1]
^L
RFC 1386                     The US Domain                 December 1992


1. INTRODUCTION

   1.1 The Internet Domain Name System

   The Domain Name System (DNS) provides for the translation between
   host names and addresses.  Within the Internet, this means
   translating from a name such as "venera.isi.edu", to an IP address
   such as "128.9.0.32".  The DNS is a set of protocols and databases.
   The protocols define the syntax and semantics for a query language to
   ask questions about information located by DNS-style names.  The
   databases are distributed and replicated.  There is no dependence on
   a single central server, and each part of the database is provided in
   at least two servers.

   The assignment of the 32-bit IP addresses is a separate activity.  IP
   addresses are assigned by the Network Information Center
   (Hostmaster@NIC.DDN.MIL).

   In addition to translating names to addresses for hosts that are on
   the Internet, the DNS provides for registering DNS-style names for
   other hosts reachable (via electronic mail) through gateways or mail
   relays.  The records for such name registration point to an Internet
   host (one with an IP address) that acts as a mail forwarder for the
   registered host.  For example, the host "bah.rochester.ny.us" is
   registered in the DNS with a pointer to the mail relay
   "relay1.uu.net".  This type of pointer is called an MX record.

   This gives electronic mail users a uniform mail addressing syntax and
   avoids making users aware of the underlying network boundaries.

   The reason for the development of the domain system was growth in the
   Internet.  The host name to address mappings were maintained by the
   Network Information Center (NIC) in a single file, called HOSTS.TXT,
   which was FTPed by all the hosts on the Internet.  The network
   population was changing in character.  The timeshared hosts that made
   up the original ARPANET were being replaced with local networks of
   workstations.  Local organizations were administering their own names
   and addresses, but had to wait for the NIC to make changes in
   HOSTS.TXT to make the changes visible to the Internet at large.
   Organizations also wanted some local structure on the name space.
   The applications on the Internet were getting more sophisticated and
   creating a need for general purpose name service.  The idea of a
   hierarchical name space, with the hierarchy roughly corresponding to
   organizational structure, and names using "." as the character to
   mark the boundary between hierarcy levels.  A design using a
   distributed database and generalized resources was implemented.

   The domain system provides standard formats for resource data,



Cooper & Postel                                                 [Page 2]
^L
RFC 1386                     The US Domain                 December 1992


   standard methods for querying the database, and standard methods for
   name servers to refresh local data from other name servers.

   1.2  Top-Level Domains

   The top-level domains in the DNS are EDU, COM, GOV, MIL, ORG, INT,
   and NET, and all the 2-letter country codes from the list of
   countries in ISO-3166.

   Even though the intention was that any educational institution any
   where in the world could be registered under the EDU domain, in
   practice it has turned out with few exceptions only those in the
   United States have registered under EDU, similiary with COM (for
   commercial). In other countries, everything is registered under the
   2-letter country code, often with some subdivision.  For example, in
   Korea (KR) the second level names are AC for academic community, CO
   for commercial, GO for government, and RE for research.  However each
   country may go it's own way about organizing its domain, and many
   have.

   Their are no plans of putting all of the organizational domains .EDU
    .GOV .COM etc., under .US.

   However, there are some states registered in the .GOV domain (11 by 2
   letter code), and 3 by full names)

           ca.gov          la.gov          ohio.gov        va.gov
           co.gov          md.gov          or.gov          wa.gov
           hawaii.gov      nc.gov          sc.gov
           ia.gov          ny.gov          texas.gov

   Other names sometimes appear as top-level domain names.  Some people
   have made up names in the DNS style without coordinating or
   registering  with the DNS management.  Some names that typically
   appear are ".BITNET", ".UUCP", and two-letter codes for continents,
   such as ".NA" for North America (this conflicts with the official
   Internet code for Namibia).

   For example, the DNS style name "KA7EEJ.CO.USA.NA" is used in the
   amateur radio network.  These addresses are never supposed to show up
   on the Internet but they do occasionally.  The amateur radio network
   people created their own naming scheme, and it interferes sometimes
   with Internet addresses.








Cooper & Postel                                                 [Page 3]
^L
RFC 1386                     The US Domain                 December 1992


   1.3  The US Domain

   The US Domain is an official top-level domain in the DNS of the
   Internet community.  It is registered with the Network Information
   Center.  The domain administrators are Jon Postel and Ann Westine
   Cooper at the Information Sciences Institute of the University of
   Southern California (USC-ISI).

   US is the ISO-3166 2-letter country code for the United States and
   thus the US Domain is established as a top-level domain and
   registered with the NIC the same way other country domains are.

   Because organizations in the United States have registered primarily
   in the EDU and COM domains, little use was initially made of the US
   domain.

   In the past, the computers registered in the US Domain were primarily
   owned by small companies or individuals with computers at home.
   However, the US Domain has grown and currently registers hosts in
   federal government agencies, state government agencies, K12 schools,
   community colleges, private schools, libraries, county agencies, and
   city utilities, to name a few.

   The administration of the US Domain was managed solely by the Domain
   Registrar in the past.  However, due to the increase of hosts,
   administration of subdomains is being delegated to others.

   Any computer in the United States may be registered in the US Domain.

2. NAMING STRUCTURE

   The US Domain hierarchy is based on political geography.  The
   namespace under .US is the state namespace, then the city namespace,
   then organization or computer name and so on.

   For example:

          SPK.WA.US
         VANC.WA.US

   There is of course no problem with running out of names.

   The things that are named are individual computers.

   If you register now in one city and then move, the database can be
   updated with a new name in your new city, and a pointer can be set up
   from your old name to your new name.  This type of pointer is called
   a CNAME record.



Cooper & Postel                                                 [Page 4]
^L
RFC 1386                     The US Domain                 December 1992


   The use of un-registered names is not effective and causes problems
   for other users.  Inventing your own name and using it without
   registering is not a good idea.

   2.1  State Codes

   The state codes are the two letter US Postal abbreviations.

   2.2  City Codes or Locality Names

   Cities may be named (designated) by their full name (spelled out with
   hyphens replacing spaces (e.g., Los-Angeles or New-York)), or by a
   city code.  The first choice is the full city name, the second choice
   is the city codes from Western Union's "City Mnemonics" list, and a
   third choice is a code for your city chosen by the applicant.
   However, it is very desirable that all users in the same city use the
   same designator for the city.

   Abbreviated city names are a good idea, particularly when the city
   name is long, as there is much to type already.  One of the problems
   is that the city codes in the Western Union City Mnemonics list are
   sometimes not very good abbreviations.  Users sometimes tend to
   prefer abbreviations that are commonly used already from that region.
   Such as SF for San Francisco, MPK for Menlo Park.

   Exceptions have been made in the abbreviations, even though this
   causes extra work to keep track of these abbreviations.  One
   abbreviation for one city.  Applicants are told what codes are
   currently in use, however, if a city code is not used yet, and they
   would prefer to use a different code that is more common among the
   natives, then the new code is allowed.  However, once it's
   registered, then everyone else who registers in that city will have
   to use that code or spell out the full city name.

   Some applicants have tried to get a copy of the Western Union City
   Mnemonics code list but it is no longer available from Western Union.
   However, we do have a copy but it is not online. If you are
   requesting an abbreviated city code please let us know and we will
   gladly look it up for you.

   2.3  Examples of Names

   For small entities like individuals or small businesses there is
   usually no problem with selecting locality based names.

         For example:  Zuckys.Santa-Monica.CA.US





Cooper & Postel                                                 [Page 5]
^L
RFC 1386                     The US Domain                 December 1992


   For large entities like large corporations with multiple facilities
   in several cities or states this often seems like a unreasonable
   constraint (especially when compared with the alternative of
   registering directly in the .COM domain).  However, a company does
   have a headquarters office in a particular locality and so could
   register with that name.

         For example:  IBM.Armonk.NY.US


             EXAMPLES OF THE NAMING STRUCTURE IN THE US DOMAIN

   PRIVATE (business or individual)
   ================================

   Camp-Curry.Yosemite.CA.US       <====  a business
   IBM.Armonk.NY.US                <====  a business
   Dogwood.atl.GA.US               <====  a business
   Geo-Petrellis.Culver-City.CA.US <====  a restaurant
   Zuckys-Santa-Monica.CA.US       <====  a restaurant
   Joe-Josts.Long-Beach.CA.US      <====  a bar
   Holodek.Santa-Cruz.CA.US        <====  a personal computer

   FEDERAL
   =======

   Senate.FED.US           <====  US Senate
   DOD.FED.US              <====  US Defense Dept.
   DOT.FED.US              <====  US Transportation Dept.
   USPS.FED.US             <====  US Postal Service
   VA.FED.US               <====  US Veterans Administration
   IRS.FED.US              <====  US Internal Revenue Service
   Yosemite.NPS.Interior.FED.US    <====  a federal agency

   STATE
   =====

   Senate.STATE.MN.US      <====  state Senate
   House.STATE.MN.US       <====  state House of Reps
   MDH.STATE.MN.US         <====  state Health Dept.
   HUD.STATE.CA.US         <====  state House and Urban Dev. Dept.
   DOT.STATE.MN.US         <====  state Transportation Dept.
   Caltrans.STATE.CA.US    <====  state Transportation Dept.
   DMV.STATE.CA.US         <====  state Motor Vehicles Dept.
   Culver-City.DMV.STATE.CA.US  <====  a local office of DMV






Cooper & Postel                                                 [Page 6]
^L
RFC 1386                     The US Domain                 December 1992


   CITY | COUNTY
   ==============

   Police.CITY.Culver-City.CA.US       <====  a city department
   Fire-Dept.CITY.Los-Angeles.CA.US    <====  a city department
   Fire-Dept.COUNTY.Los-Angeles.CA.US  <====  a county department

   REGIONAL | DISTRICT | LIBRARY
   =============================

   SCAQMD.DISTRICT.CA.US                     <====  a regional district
   Bunker-Hill-Improvement.DISTRICT.LA.CA.US <====  a local district

   Huntington.LIB.LA.US                    <====  a private library
   Venice.LA-City.LIB.CA.US                <====  a city library
   MDR.LA-County.LIB.CA.US                 <====  a county library

   K12 | CC | STATE UNIV | PRIVATE SCHOOLS
   =======================================

   Los-Angeles.UC.STATE.CA.US      <====  UCLA
   Berkeley.UC.STATE.CA.US         <====  "CAL"
   Irvine.UC.STATE.CA.US           <====  University of Calif. Irvine
   Santa-Cruz.UC.STATE.CA.US       <====  University of Calif. Santa Cruz
   Northridge.CSU.STATE.CA.US      <====  Calif. State. Univ. Northridge
   Fullerton.CSU.STATE.CA.US       <====  Calif. State. Univ. Fullerton
   Sonoma.CSU.STATE.CA.US          <====  Calif. State. Univ. Sonoma

   SMCC.Santa-Monica.CC.CA.US      <====  a public community college
   Trade-Tech.Los-Angeles.CC.CA.US <====  a public community college

   Hamilton.High.LA-Unified.K12.CA.US      <====   a public K12 school
   Sherman-Oaks.Elem.LA-Unified.K12.CA.US  <====   a public K12 school
   John-Muir.Middle.Santa-Monica.K12.CA.US <====   a public K12 school

   St-Monica.High.Santa-Monica.CA.US       <====  a private high school
   St-Monica.Elem.Santa-Monica.CA.US       <====  a private elem. school
   Crossroads-School.Santa-Monica.CA.US    <====  a private school
   Mary-Ellens.Montessori-School.LA.CA.US  <====  a private school
   Leland-Stanford-Jr-Univ.Stanford.CA.US  <====  a private school
   Loyola-Marymount-Univ.Los-Angeles.CA.US <====  a private school










Cooper & Postel                                                 [Page 7]
^L
RFC 1386                     The US Domain                 December 1992


   When appropriate, subdomains are delegated and partioned in various
   categories, such as:

                   K12.<state>.US   =   kindegarten thru 12th grade
                    CC.<state>.US   =   community colleges
                   LIB.<state>.US   =   libraries
                 STATE.<state>.US   =   state government agencies
                <org-name>.FED.US   =   federal government agencies

   The Appendix-I contains the current US Domain Names BNF, but in
   actuality, the names under these subdomains may vary according to the
   decision of the administrators of these subdomains.

   Some users would like names associated with a greater metropolitan
   area or region like the "Bay Area" or "Tri-Cities".  One problem with
   this is that these names are not necessarily unique within a state.
   The best thing to do in this case is to use the larger metropolitan
   city in your host name.  Cities and in some cases counties are used.

3. REGISTRATION

   3.1  Requirements

   Anyone requesting to register a host in the US Domain is sent a copy
   of the US Domain policy and procedure, and must fill out a US Domain
   questionnaire.

   The US Domain template, is similar to the NIC Domain template
   however, it is not the same.  To request a copy of the US Domain
   questionnaire, send a message to the US Domain registrar (us-
   domain@isi.edu).

      Note:  If you are registering a name in a delegated zone
             (see Section 3.3.6).  Please register with the
             contact for that zone.

   The key people must have electronic mailboxes (that work).  Please
   provide all the information indicated in the "Administrator" and
   "Technical Contact" slot.  This person will be the point of contact
   for any administrative and policy questions about the domain.

   The administrator is usually the person who manages the organization
   being registered. The technical contact can also be administrator, or
   the systems person, or someone who is familiar with the technical
   details of the Internet. The technical contact should have a valid
   working e-mail address. This is necessary in case something goes
   wrong.




Cooper & Postel                                                 [Page 8]
^L
RFC 1386                     The US Domain                 December 1992


   It is important that your "Return-Path" and "From" field indicate an
   Internet style address.  UUCP style addresses such as "host1!user"
   will not work. This is fine within the UUCP world, but not the
   Internet.  If you want people on the Internet to be able to send mail
   to you, your return path needs to be an Internet style address: such
   as host1!user@internet.gateway.host or user@internet.gateway.host.

   It is also possible to register through one of the Internet service
   providers that have established working relationships with the US
   domain administrator.

   If everything checks out, turn around time for registering a host is
   usually a day or two.  The nameservers are updated anywhere from 12
   to 24 hours later.

   There are two ways to be registered in the US Domain, directly, or by
   delegation.

   3.2  Direct Entries

   Direct entry in the database of the US Domain appeals most to
   individuals and small companies.  Fill out the application and send
   it directly to the US Domain administrator.  If you are in an area
   where the zone is delegated to someone else your request will be
   forwarded to the zone administrator for your registration.

   3.2.1 UUCP Hosts

   Many applicants have hosts in the UUCP world.  Some are one hop away,
   some two and three hops away from their "Internet Forwarder", this is
   ok.  What is important is getting an Internet host to be your
   forwarder.  If you do not already have an Internet forwarder, there
   are several businesses that provide this service for a fee, such as
   UUNET.UU.NET (postmaster@uunet.uu.net), PSI (postmaster@UU2.PSI.COM)
   and CERFNET (help@cerf.net).  Sometimes local colleges in your area
   are already on the Internet and may be willing to act as an Internet
   Forwarder.  You would need to work this out with the systems
   administrator we cannot make these arrangements for you.

   Although we work with UUCP service providers, the Internet US Domain
   registration is not affiliated with the registration of UUCP Map
   entries.  The UUCP map entry does not provide us with sufficient
   information.  If you do not have a copy of the US Domain
   questionnaire template, please send a message to: us-domain@isi.edu
   and request one.  See Appendix-II.






Cooper & Postel                                                 [Page 9]
^L
RFC 1386                     The US Domain                 December 1992


   This is not an appropriate registration for the US Domain.

     #N starl
     #S Amiga 2500; AmigaDOS 2.04; Dillon's AmigaUUCP 1.15D
     #O Starlight BBS
     #C Stephen Baker
     #E starl!sbaker
     #T +1 305 378 1161
     #P 1107 SW 200th St #303B Miami, Fl. 33157
     #L 25 47 N / 88 10 W [city]
     #R
     #U mthvax
     #W starl!sbaker (Stephen Baker); Mon Feb 24 19:58:24 EST 1992
      starl        mthvax(DAILY)

   If you are registering your host as a central site for a USENET group
   where other UUCP sites will feed from you, that's fine.  These UUCP
   sites do not need to register.  If however, the other sites become a
   subdomain of your hostname, then we will need to register them
   individually or add a wildcard record.

           For example:          bah.rochester.ny.us
                           host1.bah.rochester.ny.us
                           host2.bah.rochester.ny.us

   3.2.2 NON-IP Hosts

   To use US Domain names for non-IP hosts, there must be a forwarder
   host that is an IP host.  There must be an adminstrative agreement
   and a technical procedure for relaying mail between the non-IP host
   and the forwarder host.

   Case 1:
   -------

   Your host is not an IP host but does talk directly with a host that
   is an IP host.
                                                  +-----------------+
   +----------+            +---------+            |                 |
   |your-host |---UUCP-----|forwarder|----IP/TCP--|    INTERNET     |
   +----------+            +---------+            |                 |
                                                  +-----------------+
   "Forwarder" must be an IP host on the Internet.

   You must ask "forwarder" if they are willing to be the internet
   forwarder for "your-host".

   In the US Domain of the DNS data base there must be an entry like



Cooper & Postel                                                [Page 10]
^L
RFC 1386                     The US Domain                 December 1992


   this:
          "your-host"  MX  10  "forwarder"

   This must be entered by the US Domain administrator.

   In the "forwarder" routing tables there must be information about
   "your-host" with a rule like: If I see mail for "your-host" I will
   send it via uucp by calling phone number "123-4567".

   Case 2:
   -------

   In this case your hosts talks to another host that ... that talks to
   an IP host.  In other words, there are multiple hops between your host
   and the Internet.
                                                  +-----------------+
   +----------+            +---------+            |                 |
   |path-host |---UUCP-----|forwarder|----IP/TCP--|    INTERNET     |
   +----------+            +---------+            |                 |
       |                                          +-----------------+
      UUCP
       |
   +----------+
   |your-host |
   +----------+

   "Forwarder" must be an IP host on the internet.

   You must ask "forwarder" if they are willing to be the Internet
   Forwarder for "Your-Host".  You must ask "path-host" to relay your
   mail.

   In the US Domain of the DNS DataBase there must be an entry like this:

          "your-host"  MX  10  "forwarder"

   This must be entered by the US Domain Administrator.

   In the "forwarder" routing tables there must be information about
   "your-host" with a rule like: If I see mail for "your-host" I will
   send it via UUCP to "path-host" by calling phone number "123-4567".
   and "path-host" must also know how to relay the mail to "your-host".

   Note: It is assumed that "path-host" is already MXed to "forwarder".
   It is not appropriate to ask to MX "your-host" to "path-host" (this
   is sometimes called double MXing).  The host on the right hand side
   of an MX entry must be a host on the Internet with an IP address
   (e.g., 128.9.2.32).



Cooper & Postel                                                [Page 11]
^L
RFC 1386                     The US Domain                 December 1992


   3.3  Delegated Subdomains

   The administrator of the US Domain is responsible for the assignment
   of all the DNS names that end with ".US".  Of course, one person or
   even one group can't handle all this in the long run so portions of
   the name space are delegated to others.

   Delegation of cities, companies within cities, schools (K12),
   community colleges (CC), libraries (LIB), state government (STATE),
   and federal government agencies, departments, etc., is acceptable and
   practical.

   For a delegated portion of the namespace, for example a city, no
   alterations can be made to that name, no abbreviations added, etc.
   unless applied for.

   Sometimes there may be two people running name servers in the same
   city because different portions of the name space has been delegated
   to them.  For example, someone may be delegated the <city>.<state>.US
   name space, and someone else from a state government agency may have
   the .STATE.<state>.US, portion.  For example, Fred may run the name
   servers for Sacramento.CA.US and Joe may run the name servers for
   STATE.CA.US in Sacramento.

   If a company would like to have wildcard records added, or run their
   own name servers in a city that we have delegated name space to, this
   is ok.

   Delegation of the whole State namespace is not yet implemented.  The
   delegated part of the name space is in the form of:

                    .STATE.<state>.US.
                      .K12.<state>.US.
                       .CC.<state>.US.
                      .LIB.<state>.US.
        .<org-name>.<city>.<state>.US.
         .CITY.<city-name>.<state>.US.
                   .<org-name>.FED.US.

   3.3.1  Schools

   As schools begin to join the Internet, there ought to be a consistent
   scheme for naming them.  A "K12" name branch has been established in
   each state in the US Domain for this purpose.

   Public schools are usually organized by districts which can be larger
   or smaller than a city or county.




Cooper & Postel                                                [Page 12]
^L
RFC 1386                     The US Domain                 December 1992


   It makes sense to name schools within districts.  However districts
   often have the same name as a city or county so there has to be a way
   to distinguish a public school district name from some other type of
   locality name.  The keyword "K12" is used for this.

   In some districts, the same school name is used at different levels,
   for example, Washington Elementary School and Washington High School.
   We suggest that when necessary the keywords "Elementary", "Middle",
   and "High" be used to distinguish these schools.  These keywords
   would only be used when they are needed, if the school's name is
   unique without such keywords don't use them.

   Typical K12 school names currently used are like:

              IVY.PRS.K12.NJ.US
              DMHS.JCPS.K12.KY.US
              OHS.EUNION.K12.CA.US
              BOHS.BREA.K12.CA.US

   These names could be long.  Given the large number of schools,
   organizing by school district and state seems appropriate.  When
   there are many things to name some of the names must be long.

   In some cases there may be appropriate abbreviations that can be
   used.  For example Hamilton High School in Los Angeles could be:

              Hami.Hi.LA.K12.CA.US

      Some School Examples:
      ---------------------

      Hamilton.High.LA-Unified.K12.CA.US        <== a public school
      Sherman-Oaks.Elem.LA-Unified.K12.CA.US    <== a public school
      John-Muir.Middle.Santa-Monica.K12.CA.US   <== a public school
      Crossroads-School.Santa-Monica.CA.US      <== a private school
      SMCC.CC.CA.US                             <== a community college
      Northridge.CSU.STATE.CA.US                <== a state university

   If a school has a bunch of PCs, then each PC should have a name.
   Suppose they are named "alpha", "beta", ... then if they belong to a
   school named "Lincoln.High.Lakewood.K12.CA.US" their names would be:

                alpha.Lincoln.High.Lakewood.K12.CA.US.
                beta.Lincoln.High.Lakewood.K12.CA.US
           ...






Cooper & Postel                                                [Page 13]
^L
RFC 1386                     The US Domain                 December 1992


   3.2.2  State Agencies

   US Domain namespace has been delegated to the state goverment
   agencies.  For example, in the State of Minnesota, the subdomain is
   STATE.MN.US

   This means that the person running the namservers for state.mn.us are
   responsible for naming agencies, of the state govermnent.  For
   example:

      State Agencies:
      ---------------

      Senate.STATE.MN.US      <== State Senate
      MDH.STATE.MN.US         <== Dept. of Health
      CALTRANS.STATE.CA.US    <== Dept. of Transportation
      DMV.STATE.CA.US         <== Dept. of Motor Vehicles

   3.3.3  Federal Agencies

   A federal namespace has been delegated to the federal government
   agencies.  For example the subdomain for the Federal Reserve Bank of
   Minneapolis is MNPL.FRB.FED.US. Other examples are listed below.

      Federal Government Agencies:
      ---------------------------

      Senate.FED.US   <====  US Senate
      DOD.FED.US      <====  US Defense Dept.
      USPS.FED.US     <====  US Postal Service
      VA.FED.US       <====  US Veterans Administration
      IRS.FED.US      <====  US Internal Revenue Service
      Yosemite.NPS.Interior.FED.US    <====  A Federal agency

   3.3.4  Delegation Requirements

   When a subdomain is delegated, the following requirements must be
   met:

      1)  There must be a knowledgeable and competent technical contact,
          familiar with the Internet Domain Name System.  This
          requirement is easily satisified if the technical contact
          already runs some other nameservers.

      2)  Organizations requesting delegations must provide at least two
          independent (robust and reliable) DNS name servers in
          physically separate locations on the Internet.




Cooper & Postel                                                [Page 14]
^L
RFC 1386                     The US Domain                 December 1992


      3)  The subdomain must accept all applicants on an equal basis.

      4)  The subdomain must provide timely processing of requests.  To
          do this it is helpful to have several individuals
          knowledgeable about the procedures so that the operations are
          not delayed due to one persons unavailability (for example by
          being on vacation).

   3.3.5  Delegation Procedures

   The procedure that is followed when a subdomain is delegated includes
   the following steps:

      1)  Evaluate the technical contact's experience with DNS.  Make
          sure there is a need for the proposed delegation.  Make sure
          the technical contact has the information about the US Domain
          and the suggested naming structure.

      2)  Note: In the past there was the concept of a "coordinator" for
          a group or a club or "Domain Park". They would arrange to
          coordinate the registration of all the computers used by
          members of the club and forward all the information for the
          group to the US Domain Administrator.  Most coordinators have
          moved into the position of administrator of that now delegated
          subdomain.

      3)  Add the new technical contact to the "us-dom-adm" mailing list
          for distributing updates to the US Domain policies and
          procedures, or other pertinent information.

      4)  Delete any hosts from our zone file that belongs in the newly
          delegated subdomain and make sure they now have the hosts in
          their zone file.


















Cooper & Postel                                                [Page 15]
^L
RFC 1386                     The US Domain                 December 1992


      5)  Send them a copy of the zone file so their initial zone file
          is identical to ours. For example:

            mil.wi.us.   86400   SOA spool.mu.edu. manager.spool.mu.edu. (
                                    920904  ;serial
                                    28800   ;refresh
                                    14400   ;retry
                                    3600000 ;expire
                                    86400 ) ;minim

            mil.wi.us.      86400   NS      spool.mu.edu.
            spool.mu.edu.   50400   A       134.48.1.31
            mil.wi.us.      86400   NS      sophie.mscs.mu.edu.

            sophie.mscs.mu.edu.     50400   A       134.48.4.6
            solaria.mil.wi.us.      86400   HINFO   Sun 3/60 SunOs
            solaria.mil.wi.us.      86400   MX      10 spool.mu.edu.
            nthomas.mil.wi.us.      86400   HINFO   386 Clone DOS
            nthomas.mil.wi.us.      86400   MX      10 spool.mu.edu.
            rwmke.mil.wi.us.        86400   HINFO   UNIX PC UNIX
            rwmke.mil.wi.us.        86400   MX      10 spool.mu.edu.
            milestn.mil.wi.us.      86400   HINFO   PC AT ENIX
            milestn.mil.wi.us.      86400   MX      10 spool.mu.edu.
            dawley.mil.wi.us.       86400   HINFO   386 Clone DOS
            dawley.mil.wi.us.       86400   MX      10 spool.mu.edu.
            ...
                      -------------------------------------
























Cooper & Postel                                                [Page 16]
^L
RFC 1386                     The US Domain                 December 1992


      6)  The US Domain zone file must have the following records,
          showing the name, address, e-mail, and phone number of the
          technical contact for the delegated subdomain and the name of
          the delegated name space and the names of the nameservers.

            ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
            ;
            ;Delegated zone: .mil.wi.us
            ;Contact:  Steven Goodman
            ;          manager@spool.mu.edu
            ;          Marquette University
            ;          (414) 288-6734

            mil.wi.us.      604800  NS      SPOOL.MU.EDU.
                            604800  NS      SOPHIE.MSCS.MU.EDU.

            ; A glue record is not needed this time. Glue records are
            ; needed when the name of the server is a subdomain of the
            ; delegated domain.
            ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

      7)  Check to see that delegated subdomain name servers are up and
          running, and make sure the delegated hosts are installed in
          their zone file.  Now delete any hosts from the US Domain zone
          file that belongs in the newly delegated subdomain.

      8)  Inform the technical contact of the newly delegated subdomain
          that wildcard records are allowed in the zone file under the
          organizational subdomain but no wildcard records are allowed
          under the "city" or "state" domain.





















Cooper & Postel                                                [Page 17]
^L
RFC 1386                     The US Domain                 December 1992


   3.3.6   Subdomain Contacts

   Approximately 680 individual hosts are registered, but we have
   delegated the following portions of the namespace.  We do not know
   how many hosts are registered under each of these subsdomains.

           DELEGATED ZONE             CONTACT
           ==============             =======

           TUCSON.AZ.US               leonard@arizona.edu
           SF.CA.US                   sf-hostmaster@apple.com
           PREMENOS.SF.CA.US          jenkins@premenos.sf.ca.us
           SCVL.CA.US                 sinster@scintilla.capitola.ca.us
           SANTA-CRUZ.CA.US           sinster@scintilla.capitola.ca.us
           APTOS.CA.US                sinster@scintilla.capitola.ca.us
           CAMPBELL.CA.US             sinster@scintilla.capitola.ca.us
           CAPITOLA.CA.US             sinster@scintilla.capitola.ca.us
           FELTON.CA.US               sinster@scintilla.capitola.ca.us
           ZAYANTE.CA.US              sinster@scintilla.capitola.ca.us
           BOULDER-CREEK.CA.US        sinster@scintilla.capitola.ca.us
           DARWIN.PTVY.CA.US          brian@angband.stanford.edu
           LOGAN-HS.UNIONCITY.CA.US   cjw@marmot.nersc.gov
           BOULDER.CO.US              trent@XOR.COM
           COLOSPGS.CO.US             trent@XOR.COM
           DENVER.CO.US               trent@XOR.COM
           DVR.CO.US                  trent@XOR.COM
           CHI.IL.US                  matt@oddjob.uchicago.edu
           EUGENE.OR.US               meyer@oregon.uoregon.edu
           SPRINGFIELD.OR.US          meyer@oregon.uoregon.edu
           MULTNOMAH.LIB.OR.US        brianw@polaris.admin.ogi.edu
           PGH.PA.US                  ecd@CERT.ORG
           SPK.WA.US                  root@dogear.spk.wa.us
           MIL.WI.US                  manager@spool.mu.edu
           ATL.GA.US                  charvey@gatech.gatech.edu
           Mt-PARK.GA.US              charvey@gatech.gatech.edu
           CLARKSTON.GA.US            charvey@gatech.gatech.edu
           STATE.MN.US                dfazio@mr.net
           MNPL.FRB.FED.US            dfazio@mr.net

           K12.CA.US                  mdm@NIC.CSU.NET
           CC.CA.US                   mdm@NIC.CSU.NET
           K12.MI.US                  sandra.s.waite@um.cc.umich.edu
           K12.TX.US                  bmanning@is.rice.edu
           K12.NJ.US                  becker@nisc.jvnc.net
           K12.MS.US                  fwp@msstate.edu
           dmhs.jcps.K12.KY.US        lentner@sura.net
           TIES.K12.MN.US             dfazio@mr.net




Cooper & Postel                                                [Page 18]
^L
RFC 1386                     The US Domain                 December 1992


        The following MD.US counties have been delegated to
        (butler@brl.mil).

           AL.MD.US.       Allegany
           AA.MD.US.       Anne Arundel
           BA.MD.US.       Baltimore
           CAL.MD.US.      Calvert
           CAR.MD.US.      Caroline
           CE.MD.US.       Cecil
           CH.MD.US.       Charles
           DO.MD.US.       Dorchester
           FR.MD.US.       Frederick
           GA.MD.US.       Garrett
           HA.MD.US.       Harford
           HO.MD.US.       Howard
           KE.MD.US.       Kent
           MO.MD.US.       Montgomery
           PG.MD.US.       Prince George"s
           QA.MD.US.       Queen Anne's
           SM.MD.US.       St. Mary's
           SO.MD.US.       Somerset
           TA.MD.US.       Talbot
           WA.MD.US.       Washington
           WI.MD.US.       Wicomico
           WO.MD.US.       Worcester

4. DATABASE INFORMATION

   4.1. Name Servers

   Name servers are the repositories of information that make up the
   domain database.  The database is divided up into sections called
   zones, which are distributed among the name servers.  While name
   servers can have several optional functions and sources of data, the
   essential task of a name server is to answer queries using data in
   its zones.  The response to a query can always be generated using
   only local data, and either contains the answer to the question or a
   referral to other name servers "closer" to the desired information.

   A given zone will be available from several name servers to insure
   its availability in spite of host or communication link failure.
   Every zone is required to be available on at least two servers, and
   many zones have more redundancy than that.








Cooper & Postel                                                [Page 19]
^L
RFC 1386                     The US Domain                 December 1992


   The US Domain is currently supported by six name servers.

           venera.isi.edu
           ns.isi.edu
           ns.hercules.csl.sri.com
           nnsc.nsf.net
           ns.uu.net
           adm.brl.mil

   4.2 Zone Files

   A "zone" is a registry of domains kept by a particular organization.
   A zone registry is "authoritative", that is, the master copy of the
   registry is kept by the zone organization, and this copy is, by
   definition, always up-to-date.  Copies of this registry may be
   distributed to other places and kept in caches, but these caches are
   not authoritative, and may be out-of-date.

   Every zone has at least one node, and hence domain name, for which it
   is authoritative, and all of the nodes in a particular zone are
   connected.  Given the tree structure, every zone has a highest node
   which is closer to the root than any other node in the zone.  The
   name of this node is often used to identify the zone.  The data that
   describes a zone has four major parts:

        1) Authoritative data for all nodes within the zone.

        2) Data that defines the top node of the zone
           (can be thought of as part of the authoritative data).

        3) Data that describes delegated subzones, i.e., cuts
           around the bottom of the zone,

        4) Data that allows access to name servers for subzones
           (sometimes called "glue" data).

   The zone administrator has to maintain the zones at all the
   namservers which are authoritative for the zone.  When the changes
   are made they must be distributed to all of the name servers.

   Copies of the zone files are not available unless you are on the
   Internet.  To look at the zone files use the "dig" program of the DNS
   domain name system.

        dig   @nshost  host-your-checking  axfr






Cooper & Postel                                                [Page 20]
^L
RFC 1386                     The US Domain                 December 1992


   4.3 Resource Records

   Records in the zone data files are called resource records (RRs).
   The standard Resource records (RR) are specified in STD 13, RFC 1034
   and STD 13, RFC 1035 (3,4).  An RR has a standard format as shown.

                  <name> [<ttl>] [<class>] <type> <data>

   The first field is always the name of the domain record.  The second
   field is an optional time to live field.  This specifies how long
   this data will be stored in the data base.  The third field is the
   address class; the class field specifies the protocol group most
   often this is the Internet class "IN".  The fourth field states the
   type of the resource record.  The fields after that are dependent on
   the Type of RR. The fifth field is the data field which is defined
   differently for each type and class of data.  Here is a list of the
   current commonly used types.

           SOA     Start of Authority
           NS      Name Server
           A       Internet Address
           CNAME   Canonical Name (nickname pointer)
           HINFO   Host Information
           WKS     Well Known Services
           MX      Mail Exchanger
           PTR     Pointer

   What do the fields mean?

           foo.LA.CA.US.    604800    MX   10     Venera.ISI.EDU.
           (1)              (2)       (3)  (4)    (5)

           1)  domain name
           2)  time to live information
           3)  mail exchanger record
           4)  preference value to determine (if more than one
               forwarder) which mailer to use first, lower number
               higher preference
           5)  the Internet forwarding host.












Cooper & Postel                                                [Page 21]
^L
RFC 1386                     The US Domain                 December 1992


   4.3.1  A Records

   Internet (IP) Address.  The data for an "A" record is an Internet
   address in a dotted decimal form.  A sample "A" record might look
   like:

           venera.isi.edu.          A      128.9.0.32
              (name)               (A)     (address)

   The name field is the machine name, and the address is the network
   address. There should be only one "A" record for each address of a
   host.

   4.3.2  CNAME Records

   Canonical Name resource record, CNAME, specifies an alias for a
   canonical name. This is essentially a pointer to the official name
   for the requested name.  All other RRs appear under this official
   name.  A machine named FERNWOOD.MPK.CA.US may want to have the
   nickname ANTERIOR.MPK.CA.US.  In that case, the following RR would be
   used:

           anterior.mpk.ca.us.     CNAME      fernwood.mpk.ca.us.
            (alias nickname)                   (canonical name)

   Nicknames (the name associated with the RR is the nickname) may be
   added for awhile when a host changes its name, usually because it
   moves to another state.  It helps to have this CNAME pointer so if
   any mail comes to the old address it will get forwarded to the new
   one.  There cannot be any other RRs associated with a nickname of the
   same class.

   4.3.3  MX Records

   Mail Exchanger records, MX, are used to specify a machine that knows
   how to deliver mail to a machine that is not directly connected to
   the Internet.  For example, venera.isi.edu is the mail gateway that
   knows how to deliver mail to foo.la.ca.us, but other machines on the
   network cannot deliver mail directly to foo.la.ca.us.  These two
   machines may have a private connection or use a different transport
   medium (such as uucp).  The preference value (10) is the order that a
   mailer should follow when there is more than one way to deliver mail
   to a single machine.  The lower the number the higher the preference.

           foo.LA.CA.US.  604800  MX  10  Venera.ISI.EDU.
           foo.LA.CA.US.  604800  MX  20  relay1.uu.net.





Cooper & Postel                                                [Page 22]
^L
RFC 1386                     The US Domain                 December 1992


   4.3.4   HINFO Records

   Host information resource records, HINFO is for host specific data.
   This lists the hardware and operating system that are running at the
   listed host.  It should be noted that a space separates the hardware
   information and the operating system information.  If you want to
   include a space in the machine name you must quote the name.  Host
   information is not specific to any class, so ANY may be used for the
   address class.  There should be one HINFO record for each host.

   acb.la.ca.us.       HINFO       VAX-11/780      UNIX
                                   (Hardware)      (Operating System)

   The official HINFO types can be found in the latest Assigned Numbers
   RFC, the most recent edition being RFC 1340.  The hardware type is
   called the Machine Name, and the software type is called the System
   Name.

   The information users supply about this is often inconsistent or
   incomplete.  Please follow the terms in the current "Assigned
   Numbers".

   4.3.5  PTR Records

   A Domain Name Pointer record, PTR, allows special names to point to
   some other location in the domain data base.  These are typically
   used in setting up reverse pointers for the special IN-ADDR.ARPA
   domain.  PTR names should be unique to the zone.

         0.0.9.128.in-addr.arpa     PTR    isi-net.isi.edu.
             (special name)                  (real name)

   A PTR record is to be added to the IN-ADDR.ARPA domain for every A
   record registered in the US Domain.  These PTR records need to be
   added by the administrator of the network where the host is
   connected.  The US Domain administration does not administer the
   network and cannot make these entries in the DNS database.

   4.4  Wildcards

   The wildcard records are of the form "*.<anydomain>", where
   <anydomain> is any domain name.  The wildcards potentially apply to
   descendents of <anydomain>, but not to <anydomain> itself.

   For example, suppose a large company located in California with a
   large, non-IP/TCP, network wanted to create a mail gateway.  If the
   company was called DWP.LA.CA.US, and the IP/TCP capable gateway
   machine (Internet forwarder) was called ELROY.JPL.NASA.GOV, the



Cooper & Postel                                                [Page 23]
^L
RFC 1386                     The US Domain                 December 1992


   following RRs might be entered into the .US zone.

           dwp.la.ca.us    MX      10       ELROY.JPL.NASA.GOV
         *.dwp.la.ca.us    MX      10       ELROY.JPL.NASA.GOV

   The wildcard record *.DWP.LA.CA.US would cause an MX query for any
   domain name ending in DWP.LA.CA.US to return an MX RR pointing at
   ELROY.JPL.NASA.GOV. The entry without the "*" is needed so the host
   dwp can be found.

   In the US Domain, wildcard records are allowed in our zone files
   under the organizational subdomain (and where noted otherwise) but no
   wildcard records are allowed under the "City" or "State" domain.

       The authors strongly believe that it is in everyone's
       interest and good for the Internet to have each host
       explicitly registered (that is, we believe that wildcards
       should not be used), we also realize that not everyone
       agrees with this belief.  Thus, we will allow wildcard
       records in the US Domain under groups or organizations.
       For example, *.DWP.LA.CA.US.

       The reason we feel single entries are the best is by the mere
       fact that if anyone wanted to find one of the hosts in the
       domain name system it would be there, and problems can be
       detected more easily.  When using wildcards records all the
       hosts under a subdomain are hidden.

5. REFERENCES

   [1]  Stahl, M., "Domain Administrators Guide", RFC 1032, SRI
        International, November 1987.

   [2]  Lottor, M., "Domain Administrators Operations Guide" RFC 1033,
        SRI International, November 1987.

   [3]  Mockapetris, P., "Domain Names - Concepts and Facilities",
        STD 13, RFC 1034, ISI, November 1987.

   [4]  Mockapetris, P., "Domain Names - Implementation and
        Specification", STD 13, RFC 1035, ISI, November 1987.

   [5]  Dunlap, K., "Name Server Operations Guide for Bind,
        Release 4.3", UC Berkeley, SMM:11-3.

   [6]  Partridge, C., "Mail Routing and the Domain Name System",
        STD 14, RFC 974, BBN, January 1986.




Cooper & Postel                                                [Page 24]
^L
RFC 1386                     The US Domain                 December 1992


6. SECURITY CONSIDERATIONS

   Security issues are not discussed in this memo.

7. AUTHORS' ADDRESSES

   Ann Cooper
   USC/Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA  90292

   Phone:  1-310-822-1511
   Email:  cooper@isi.edu


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

   Phone:  1-310-822-1511
   Email:  postel@isi.edu





























Cooper & Postel                                                [Page 25]
^L
RFC 1386                     The US Domain                 December 1992


                     APPENDIX-I:  US DOMAIN NAMES BNF
                     ================================

   <us-domain-name>    ::= <us-name><dot><us>

   <us-name>           ::= <state-name><dot><state-code> |
                           <fed-name><dot><fed>

   <state-code>        ::= <the two-letter code of a state from the
                            zip code directory>

   <state-name>        ::= <local-name><dot><locality> |
                           <state-agency-name><dot><state> |
                           <regional-agency-name><dot><agency>

   <fed-name>          ::= <the dotted hierarchical name of a US
                            federal government agency>

   <locality>          ::= <the full name of a city from the
                             zip code directory> |
                           <a short code name for a city> |
                           <the full name of a county, township,
                            or parish> |
                           <other well known and commonly used
                            locality name>

   <local-name>        ::= <entity-name> |
                           <city-name><dot><city> |
                           <county-name><dot><county> |
                           <local-agency-name><dot><agency>

   <state-agency-name> ::= <the dotted hierarchical name of a state
                            government agency>

   <regional-agency-name> ::= <the dotted hierarchical name of a special
                            agency or district not an element of the
                            state government and typically larger than
                            a single city or county, for example, the
                            Southern California Air Quality Management
                            District>

   <entity-name>       ::= <the dotted hierarchical name of an entity
                            within a city, for example: a company,
                            business, private school, club, organization,
                            or individual>

   <city-name>         ::= <the dotted hierarchical name of a city
                            government agency>



Cooper & Postel                                                [Page 26]
^L
RFC 1386                     The US Domain                 December 1992


   <county-name>       ::= <the dotted hierarchical name of a county,
                             township, or parish government agency>

   <local-agency-name> ::= <the dotted hierarchical name of a special
                            agency or district not an element of a
                            city or county government and typically
                            equal or smaller than a single city or
                            county, for example, the Bunker Hill
                            Improvement District>


   <city> ::= "CITY"

   <county> ::= "COUNTY" | "TOWNSHIP" | "PARISH"

   <dot> ::= "."

   <fed> ::= "FED"

   <agency> ::= "AGENCY" | "DISTRICT" | "K12" | "CC" | "LIB"

   <state> ::= "STATE" | "COMMONWEALTH"

   <us> ::= "US"


   Note:  "K12" may be used for public school districts, only.
          and "CC" may be used only for public community colleges,
          and "LIB" can only be used by libraries.






















Cooper & Postel                                                [Page 27]
^L
RFC 1386                     The US Domain                 December 1992


            APPENDIX-II: US DOMAIN QUESTIONNAIRE FOR HOST ENTRY


To register a host in the US domain, the following information must be
sent to the US Domain Registrar (Us-Domain@ISI.EDU).  Questions may be
sent by electronic mail to the above address, or by phone to
Ann Cooper (310-822-1511).


(1)  The name of the top-level domain to join.

           For example:  US


(2)  The name of the administrative head of the organization, including
     title, mailing address, phone number, organization, and network
     mailbox.  This is the contact point for administrative and policy
     questions about the domain.  In the case of a research project,
     this should be the principal investigator.

           For example:

              Administrator

                 Organization  The NetWorthy Corporation
                 Name          Penelope Q. Sassafrass
                 Title         President
                 Mail Address  The NetWorthy Corporation
                               4676 Andrews Way, Suite 100
                               Santa Clara, CA 94302-1212
                 Phone Number  (415) 123-4567
                 Net Mailbox   Sassafrass@ECHO.TNC.COM



















Cooper & Postel                                                [Page 28]
^L
RFC 1386                     The US Domain                 December 1992


(3)  The name of the technical contact for the entry, including title,
     mailing address, phone number, organization, and network mailbox.
     This is the contact point for problems concerning the domain or
     zone, as well as for updating information about the domain or zone.

           For example:

              Technical Contact

                 Organization  The NetWorthy Corporation
                 Name          Ansel A. Aardvark
                 Title         Executive Director
                 Mail Address  The NetWorthy Corporation
                               4676 Andrews Way, Suite 100
                               Santa Clara, CA. 94302-1212
                 Phone Number  (415) 123-6789
                 Net Mailbox   Aardvark@ECHO.TNC.COM


(4)  The name of the host.  This is the name that will be used in tables
     and lists associating the domain with the domain server addresses.
     [While, from a technical standpoint, domain names can be quite long
     (programmers beware), shorter names are easier for people to cope
     with.]

           For example:  NetWorthy.Santa-Clara.CA.US

           Or:  Alpha.NetWorthy.Santa-Clara.CA.US
                Beta.NetWorthy.Santa-Clara.CA.US


(5)  If this machine is not directly on the internet, how does it
     communicate with the Internet.  Through UUCP, CREN, etc?  Which
     forwarding host?

          For example:  The host "Networthy.Santa-Clara.CA.US" uses UUCP
          to connect to "RELAY.ISI.EDU" which is an Internet host.

          The administrator of RELAY.ISI.EDU must agree to be the
          forwarding host for Networthy.Santa-Clara.CA.US, and the
          forwarding host must know a delivery method and route to it.
          No double MXing.









Cooper & Postel                                                [Page 29]
^L
RFC 1386                     The US Domain                 December 1992


          If you are requesting an indirect connection, that is, a Mail
          Exchanger (MX) record, what is the name and mailbox of the
          administrator of the forwarding host.

          For example:John Smith
               js@RELAY.ISI.EDU


(6)  Please describe your organization briefly.

     For example: The NetWorthy Corporation is a consulting
     organization of people working with UNIX and the C language in an
     electronic networking environment.  It sponsors two technical
     conferences annually and distributes a bimonthly newsletter.


(7)  What Domain Name System (DNS) Resource Records (RR) and values are
     to be entered.

     a.  A       Internet Address (internet hosts only)
     b.  HINFO   Host Information, Machine System
     c.  WKS     Well Known Services, Protocols, Ports (internet hosts only)
     d.  MX      Mail Exchanger (required for UUCP, and CREN hosts)

     An example of RRs for an internet host.

     NetWorthy.Santa-Clara.CA.US   IN   A       128.9.3.123
                              IN   HINFO   SUN-3/11OC UNIX
                              IN   MX      10  ISI.EDU
                              IN   WKS     128.9.3.123. UDP (echo
                                                             tftp)
                              IN   WKS     128.9.3.133. TCP (telnet
                                                             ftp
                                                             tftp
                                                             finger)

     An example of RRs for a non-internet host.

     Beta.NetWorthy.Santa-Clara.CA.US   MX      10   RELAY.ISI.EDU
                                        HINFO   SUN-3/11OC UNIX











Cooper & Postel                                                [Page 30]
^L
RFC 1386                     The US Domain                 December 1992


(8)  Where is the IN-ADDR pointer record to be entered. (For internet
     hosts only.)  It is your responsibility to see that this is done.
     Contact the administrator of the IP network your host is on.  The
     US Domain administration does not administer the network and cannot
     make these entries in the DNS database.

        For example:

           123.3.9.128.IN-ADDR.ARPA.    PTR  NetWorthy.Santa-Clara.CA.US

     Who is the contact for the zone of the IN-ADDR.ARPA data, where
     this record will be entered?


(9)  What Time to Live (TTL)?  TTL is the time (in seconds) that a
     resolver will use the data it got from the domain server before it
     asks it again for the data.  A typical TTL is One Week 604800.
     (NOTE:  TTL is not applicable to non-Internet hosts.)

        For example:

           One Week   604800





























Cooper & Postel                                                [Page 31]
^L