rfc1033.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,230 行 · 第 1/3 页

Network Working Group                                         M. Lottor
Request For Comments:  1033                           SRI International
                                                          November 1987


                 DOMAIN ADMINISTRATORS OPERATIONS GUIDE



STATUS OF THIS MEMO

   This RFC provides guidelines for domain administrators in operating a
   domain server and maintaining their portion of the hierarchical
   database.  Familiarity with the domain system is assumed.
   Distribution of this memo is unlimited.

ACKNOWLEDGMENTS

   This memo is a formatted collection of notes and excerpts from the
   references listed at the end of this document.  Of particular mention
   are Paul Mockapetris and Kevin Dunlap.

INTRODUCTION

   A domain server requires a few files to get started.  It will
   normally have some number of boot/startup files (also known as the
   "safety belt" files).  One section will contain a list of possible
   root servers that the server will use to find the up-to-date list of
   root servers.  Another section will list the zone files to be loaded
   into the server for your local domain information.  A zone file
   typically contains all the data for a particular domain.  This guide
   describes the data formats that can be used in zone files and
   suggested parameters to use for certain fields.  If you are
   attempting to do anything advanced or tricky, consult the appropriate
   domain RFC's for more details.

   Note:  Each implementation of domain software may require different
   files.  Zone files are standardized but some servers may require
   other startup files.  See the appropriate documentation that comes
   with your software.  See the appendix for some specific examples.

ZONES

   A zone defines the contents of a contiguous section of the domain
   space, usually bounded by administrative boundaries.  There will
   typically be a separate data file for each zone.  The data contained
   in a zone file is composed of entries called Resource Records (RRs).




Lottor                                                          [Page 1]

RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987


   You may only put data in your domain server that you are
   authoritative for.  You must not add entries for domains other than
   your own (except for the special case of "glue records").

   A domain server will probably read a file on start-up that lists the
   zones it should load into its database.  The format of this file is
   not standardized and is different for most domain server
   implementations.  For each zone it will normally contain the domain
   name of the zone and the file name that contains the data to load for
   the zone.

ROOT SERVERS

   A resolver will need to find the root servers when it first starts.
   When the resolver boots, it will typically read a list of possible
   root servers from a file.

   The resolver will cycle through the list trying to contact each one.
   When it finds a root server, it will ask it for the current list of
   root servers.  It will then discard the list of root servers it read
   from the data file and replace it with the current list it received.

   Root servers will not change very often.  You can get the names of
   current root servers from the NIC.

   FTP the file NETINFO:ROOT-SERVERS.TXT or send a mail request to
   [e-mail].

   As of this date (June 1987) they are:

           SRI-NIC.ARPA       10.0.0.51    26.0.0.73
           C.ISI.EDU          10.0.0.52
           BRL-AOS.ARPA       192.5.25.82  192.5.22.82   128.20.1.2
           A.ISI.EDU          26.3.0.103

RESOURCE RECORDS

   Records in the zone data files are called resource records (RRs).
   They are specified in RFC-883 and RFC-973.  An RR has a standard
   format as shown:

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

   The record is divided into fields which are separated by white space.

      <name>

         The name field defines what domain name applies to the given



Lottor                                                          [Page 2]

RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987


         RR.  In some cases the name field can be left blank and it will
         default to the name field of the previous RR.

      <ttl>

         TTL stands for Time To Live.  It specifies how long a domain
         resolver should cache the RR before it throws it out and asks a
         domain server again.  See the section on TTL's.  If you leave
         the TTL field blank it will default to the minimum time
         specified in the SOA record (described later).

      <class>

         The class field specifies the protocol group.  If left blank it
         will default to the last class specified.

      <type>

         The type field specifies what type of data is in the RR.  See
         the section on types.

      <data>

         The data field is defined differently for each type and class
         of data.  Popular RR data formats are described later.

   The domain system does not guarantee to preserve the order of
   resource records.  Listing RRs (such as multiple address records) in
   a certain order does not guarantee they will be used in that order.

   Case is preserved in names and data fields when loaded into the name
   server.  All comparisons and lookups in the name server are case
   insensitive.

   Parenthesis ("(",")") are used to group data that crosses a line
   boundary.

   A semicolon (";") starts a comment; the remainder of the line is
   ignored.

   The asterisk ("*") is used for wildcarding.

   The at-sign ("@") denotes the current default domain name.








Lottor                                                          [Page 3]

RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987


NAMES

   A domain name is a sequence of labels separated by dots.

   Domain names in the zone files can be one of two types, either
   absolute or relative.  An absolute name is the fully qualified domain
   name and is terminated with a period.  A relative name does not
   terminate with a period, and the current default domain is appended
   to it.  The default domain is usually the name of the domain that was
   specified in the boot file that loads each zone.

   The domain system allows a label to contain any 8-bit character.
   Although the domain system has no restrictions, other protocols such
   as SMTP do have name restrictions.  Because of other protocol
   restrictions, only the following characters are recommended for use
   in a host name (besides the dot separator):

           "A-Z", "a-z", "0-9", dash and underscore

TTL's  (Time To Live)

   It is important that TTLs are set to appropriate values.  The TTL is
   the time (in seconds) that a resolver will use the data it got from
   your server before it asks your server again.  If you set the value
   too low, your server will get loaded down with lots of repeat
   requests.  If you set it too high, then information you change will
   not get distributed in a reasonable amount of time.  If you leave the
   TTL field blank, it will default to what is specified in the SOA
   record for the zone.

   Most host information does not change much over long time periods.  A
   good way to set up your TTLs would be to set them at a high value,
   and then lower the value if you know a change will be coming soon.
   You might set most TTLs to anywhere between a day (86400) and a week
   (604800).  Then, if you know some data will be changing in the near
   future, set the TTL for that RR down to a lower value (an hour to a
   day) until the change takes place, and then put it back up to its
   previous value.

   Also, all RRs with the same name, class, and type should have the
   same TTL value.

CLASSES

   The domain system was designed to be protocol independent.  The class
   field is used to identify the protocol group that each RR is in.

   The class of interest to people using TCP/IP software is the class



Lottor                                                          [Page 4]

RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987


   "Internet".  Its standard designation is "IN".

   A zone file should only contain RRs of the same class.

TYPES

   There are many defined RR types.  For a complete list, see the domain
   specification RFCs.  Here is a list of current commonly used types.
   The data for each type is described in the data section.

                Designation                Description
              ==========================================
               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

SOA  (Start Of Authority)

           <name>  [<ttl>]  [<class>]  SOA  <origin>  <person>  (
                           <serial>
                           <refresh>
                           <retry>
                           <expire>
                           <minimum> )

   The Start Of Authority record designates the start of a zone.  The
   zone ends at the next SOA record.

   <name> is the name of the zone.

   <origin> is the name of the host on which the master zone file
   resides.

   <person> is a mailbox for the person responsible for the zone.  It is
   formatted like a mailing address but the at-sign that normally
   separates the user from the host name is replaced with a dot.

   <serial> is the version number of the zone file.  It should be
   incremented anytime a change is made to data in the zone.




Lottor                                                          [Page 5]

RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987


   <refresh> is how long, in seconds, a secondary name server is to
   check with the primary name server to see if an update is needed.  A
   good value here would be one hour (3600).

   <retry> is how long, in seconds, a secondary name server is to retry
   after a failure to check for a refresh.  A good value here would be
   10 minutes (600).

   <expire> is the upper limit, in seconds, that a secondary name server
   is to use the data before it expires for lack of getting a refresh.
   You want this to be rather large, and a nice value is 3600000, about
   42 days.

   <minimum> is the minimum number of seconds to be used for TTL values
   in RRs.  A minimum of at least a day is a good value here (86400).

   There should only be one SOA record per zone.  A sample SOA record
   would look something like:

           @   IN   SOA   SRI-NIC.ARPA.   HOSTMASTER.SRI-NIC.ARPA. (
                           45         ;serial
                           3600       ;refresh
                           600        ;retry
                           3600000    ;expire
                           86400 )    ;minimum


NS  (Name Server)

           <domain>   [<ttl>] [<class>]   NS   <server>

   The NS record lists the name of a machine that provides domain
   service for a particular domain.  The name associated with the RR is
   the domain name and the data portion is the name of a host that
   provides the service.  If machines SRI-NIC.ARPA and C.ISI.EDU provide
   name lookup service for the domain COM then the following entries
   would be used:

           COM.    NS      SRI-NIC.ARPA.
                   NS      C.ISI.EDU.

   Note that the machines providing name service do not have to live in
   the named domain.  There should be one NS record for each server for
   a domain.  Also note that the name "COM" defaults for the second NS
   record.

   NS records for a domain exist in both the zone that delegates the
   domain, and in the domain itself.



Lottor                                                          [Page 6]

RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987


GLUE RECORDS

   If the name server host for a particular domain is itself inside the
   domain, then a 'glue' record will be needed.  A glue record is an A
   (address) RR that specifies the address of the server.  Glue records
   are only needed in the server delegating the domain, not in the
   domain itself.  If for example the name server for domain SRI.COM was
   KL.SRI.COM, then the NS record would look like this, but you will
   also need to have the following A record.

           SRI.COM.  NS
           KL.SRI.COM.  KL.SRI.COM.  A 10.1.0.2.


A  (Address)

           <host>   [<ttl>] [<class>]   A   <address>

   The data for an A record is an internet address in dotted decimal
   form.  A sample A record might look like:

           SRI-NIC.ARPA.           A       10.0.0.51

   There should be one A record for each address of a host.

CNAME ( Canonical Name)

           <nickname>   [<ttl>] [<class>]   CNAME   <host>

   The CNAME record is used for nicknames.  The name associated with the
   RR is the nickname.  The data portion is the official name.  For
   example, a machine named SRI-NIC.ARPA may want to have the nickname
   NIC.ARPA.  In that case, the following RR would be used:

           NIC.ARPA.       CNAME   SRI-NIC.ARPA.

   There must not be any other RRs associated with a nickname of the
   same class.

   Nicknames are also useful when a host changes it's name.  In that
   case, it is usually a good idea to have a CNAME pointer so that
   people still using the old name will get to the right place.









Lottor                                                          [Page 7]

RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987


HINFO (Host Info)

           <host>   [<ttl>] [<class>]   HINFO   <hardware>   <software>

   The HINFO record gives information about a particular host.  The data
   is two strings separated by whitespace.  The first string is a
   hardware description and the second is software.  The hardware is
   usually a manufacturer name followed by a dash and model designation.
   The software string is usually the name of the operating system.

   Official HINFO types can be found in the latest Assigned Numbers RFC,
   the latest of which is RFC-1010.  The Hardware type is called the
   Machine name and the Software type is called the System name.

   Some sample HINFO records:

           SRI-NIC.ARPA.           HINFO   DEC-2060 TOPS20
           UCBARPA.Berkeley.EDU.   HINFO   VAX-11/780 UNIX