rfc1386.txt

RFC 的详细文档！

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

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








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


   The US Domain is currently supported by six name servers.

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

   4.2 Zone Files

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

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

        1) Authoritative data for all nodes within the zone.

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

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

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

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

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

        dig   @nshost  host-your-checking  axfr






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


   4.3 Resource Records

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

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

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

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

   What do the fields mean?

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

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












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


   4.3.1  A Records

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

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

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

   4.3.2  CNAME Records

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

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

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

   4.3.3  MX Records

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

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





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


   4.3.4   HINFO Records

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

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

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

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

   4.3.5  PTR Records

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

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

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

   4.4  Wildcards

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

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



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


   following RRs might be entered into the .US zone.

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

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

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

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

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

5. REFERENCES

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

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

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

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

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

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




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


6. SECURITY CONSIDERATIONS

   Security issues are not discussed in this memo.

7. AUTHORS' ADDRESSES

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

   Phone:  [phone]
   Email:  [e-mail]


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

   Phone:  [phone]
   Email:  [e-mail]