file.lst

早期freebsd实现

      ``..''
           A free standing dot in the name field  refers  to
           the current domain.

      ``@''
           A  free  standing @ in the name field denotes the
           current origin.

      ``....''
           Two free standing dots represent the null  domain
           name of the root when used in the name field.

      ``\X''
           Where  X  is  any  character  other  than a digit
           (0-9), quotes that character so that its  special
           meaning  does not apply.  For example, ``\.'' can
           be used to place a dot character in a label.

      ``\DDD''
           Where each D is a digit, is the octet correspond-
           ing  to the decimal number described by DDD.  The
           resulting octet is assumed to be text and is  not
           checked for special meaning.

      ``( )''
           Parentheses are used to group data that crosses a
           line.  In effect, line terminations are not  rec-
           ognized within parentheses.

      ``;''
           Semicolon  starts a comment; the remainder of the
           line is ignored.

      ``*''
           An asterisk  signifies  wildcarding.   Note  that
           this is just another data character whose special
           meaning comes about  only  during  internal  name
           server  search  operations.   Wildcarding is only
           meaningful for some RR types  (notably  _M_X),  and
           then  only  in  the name field -- not in the data
           fields.

           Anywhere a name appears --  either  in  the  name
      field  or  in some data field defined to contain names
      -- the current origin will be  appended  if  the  name
      does not end in a ``..''.  This is useful for appending
      the current domain name to the data, such  as  machine
      names,  but  may  cause problems where you do not want
      this to happen.  A good rule of thumb is that, if  the
      name  is  not in the domain for which you are creating
      the data file, end the name with a ``..''.










SSMMMM::1100--2200              NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD


      66..55..11..  $$IINNCCLLUUDDEE

              An include line begins with $INCLUDE, starting
         in  column  1, and is followed by a file name, and,
         optionally, by a new temporary $ORIGIN to  be  used
         while  reading this file.  This feature is particu-
         larly useful for separating different types of data
         into multiple files.  An example would be:

             $INCLUDE /usr/local/adm/named/data/mail-exchangers

         The  line would be interpreted as a request to load
         the  file   _/_u_s_r_/_n_a_m_e_d_/_d_a_t_a_/_m_a_i_l_-_e_x_c_h_a_n_g_e_r_s.    The
         $INCLUDE  command  does not cause data to be loaded
         into a different zone or tree. This is simply a way
         to  allow data for a given primary zone to be orga-
         nized in separate files.  Not even the  ``temporary
         $ORIGIN''  feature described above is sufficient to
         cause your data to branch out into some other  zone
         --  zone  boundaries  can only be introduced in the
         boot file.

      66..55..22..  ````$$OORRIIGGIINN''''

              The origin is a way of changing the origin  in
         a  data  file.  The line starts in column 1, and is
         followed by a domain origin.  This  seems  like  it
         could be useful for putting more then one zone into
         a data file, but that's not how it works.  The name
         server fundamentally requires that a given zone map
         entirely to some specific file.  You should  there-
         fore  be  very  careful to use $ORIGIN only once at
         the top of a file, or, within a file, to change  to
         a  ``lower''  domain  in the zone  -- never to some
         other zone altogether.

      66..55..33..  SSOOAA -- SSttaarrtt OOff AAuutthhoorriittyy


         _n_a_m_e   _{_t_t_l_}   _a_d_d_r_-_c_l_a_s_s   _S_O_A          _O_r_i_g_i_n                 _P_e_r_s_o_n _i_n _c_h_a_r_g_e
         @              IN           SOA          ucbvax..Berkeley..Edu..   kjd..ucbvax..Berkeley..Edu.. (
                                     1993041403   ; Serial
                                     10800        ; Refresh
                                     1800         ; Retry
                                     3600000      ; Expire
                                     259200 )     ; Minimum


         The _S_t_a_r_t _o_f _A_u_t_h_o_r_i_t_y_, _S_O_A_, record designates  the
         start of a zone.  The name is the name of the zone.
         Origin is the name of the host on which  this  data
         file  resides.   Person  in  charge  is the mailing











NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD              SSMMMM::1100--2211


         address for the person  responsible  for  the  name
         server.  The serial number is the version number of
         this data file; this number should  be  incremented
         whenever  a  change  is  made  to  the data.  Older
         servers permitted the use of  a  phantom  ``.''  in
         this  and other numbers in a zone file; the meaning
         of n.m was ``n000m'' rather than the more intuitive
         ``n*1000+m'' (such that 1.234 translated to 1000234
         rather than to 1234).  This feature has been depre-
         cated  due  to its obscurity, unpredictability, and
         lack of neccessity.  Note  that  using  a  ``YYYYM-
         MDDNN'' notation you can still make 100 changes per
         day until the year 4294.  You should choose a nota-
         tion  that  works for you.  If you're a clever _p_e_r_l
         programmer you could even use _R_C_S  version  numbers
         to  help  generate  your  zone serial numbers.  The
         refresh indicates how often, in seconds,  the  sec-
         ondary  name  servers are to check with the primary
         name server to see if an  update  is  needed.   The
         retry  indicates  how long, in seconds, a secondary
         server should wait before retrying  a  failed  zone
         transfer.   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.
         Minimum is the default number of seconds to be used
         for  the  Time  To  Live  field on resource records
         which do not specify one in the zone file.   It  is
         also  an  enforced minimum on Time To Live if it is
         specified on an RR.  There should only be  one  _S_O_A
         record per zone.

      66..55..44..  NNSS -- NNaammee SSeerrvveerr

         _{_n_a_m_e_}   _{_t_t_l_}   _a_d_d_r_-_c_l_a_s_s   _N_S   _N_a_m_e _s_e_r_v_e_r_s _n_a_m_e
                          IN           NS   ucbarpa..Berkeley..Edu..

         The  _N_a_m_e  _S_e_r_v_e_r  record,  _N_S, lists a name server
         responsible for a given  domain.   The  first  name
         field  lists  the  domain  that  is serviced by the
         listed name server.  There should be one _N_S  record
         for  each  name  server  for  the domain, and every
         domain should have at least two nameservers.

      66..55..55..  AA -- AAddddrreessss

         _{_n_a_m_e_}    _{_t_t_l_}   _a_d_d_r_-_c_l_a_s_s   _A   _a_d_d_r_e_s_s
         ucbarpa           IN           A   128..32..0..4
                           IN           A   10..0..0..78

         The _A_d_d_r_e_s_s record, _A,  lists  the  address  for  a
         given  machine.  The name field is the machine name
         and the address  is  the  network  address.   There











SSMMMM::1100--2222              NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD


         should  be  one  _A  record  for each address of the
         machine.

      66..55..66..  HHIINNFFOO -- HHoosstt IInnffoorrmmaattiioonn

         _{_n_a_m_e_}   _{_t_t_l_}   _a_d_d_r_-_c_l_a_s_s   _H_I_N_F_O   _H_a_r_d_w_a_r_e     _O_S
                          IN           HINFO   VAX-11/780   UNIX

         _H_o_s_t _I_n_f_o_r_m_a_t_i_o_n resource  record,  _H_I_N_F_O,  is  for
         host  specific  data.   This lists the hardware and
         operating system that are  running  at  the  listed
         host.   If  you  want  to  include  a  space in the
         machine name you must quote the name.  There  could
         be one _H_I_N_F_O record for each host, though for secu-
         rity reasons most  domains  don't  have  any  _H_I_N_F_O
         records at all.  No application depends on them.


      66..55..77..  WWKKSS -- WWeellll KKnnoowwnn SSeerrvviicceess

         _{_n_a_m_e_}   _{_t_t_l_}   _a_d_d_r_-_c_l_a_s_s   _W_K_S   _a_d_d_r_e_s_s       _p_r_o_t_o_c_o_l   _l_i_s_t _o_f _s_e_r_v_i_c_e_s
                          IN           WKS   128..32..0..10   UDP        who route timed domain
                          IN           WKS   128..32..0..10   TCP        ( echo telnet
                                                                      discard sunrpc sftp
                                                                      uucp-path systat daytime
                                                                      netstat qotd nntp
                                                                      link chargen ftp
                                                                      auth time whois mtp
                                                                      pop rje finger smtp
                                                                      supdup hostnames
                                                                      domain
                                                                      nameserver )

         The  _W_e_l_l _K_n_o_w_n _S_e_r_v_i_c_e_s record, _W_K_S, describes the
         well known services supported by a particular  pro-
         tocol at a specified address.  The list of services
         and port numbers come from  the  list  of  services
         specified  in  _/_e_t_c_/_s_e_r_v_i_c_e_s_.  There should be only
         one _W_K_S record per protocol per address.  Note that
         RFC 1123 says of _W_K_S records:


            2.2  Using Domain Name Service
            ...
               An application SHOULD NOT rely on the ability to locate a WKS
               record containing an accurate listing of all services at a
               particular host address, since the WKS RR type is not often used
               by Internet sites.  To confirm that a service is present, simply
               attempt to use it.
            ...
               5.2.12  WKS Use in MX Processing: RFC-974, p. 5












NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD              SSMMMM::1100--2233


                  RFC-974 [SMTP:3] recommended that the domain system be queried
                  for WKS ("Well-Known Service") records, to verify that each
                  proposed mail target does support SMTP.  Later experience has
                  shown that WKS is not widely supported, so the WKS step in MX
                  processing SHOULD NOT be used.
            ...
                  6.1.3.6  Status of RR Types
            ...
                          The TXT and WKS RR types have not been widely used by
                          Internet sites; as a result, an application cannot rely
                          on the the existence of a TXT or WKS RR in most
                          domains.


      66..55..88..  CCNNAAMMEE -- CCaannoonniiccaall NNaammee

         _a_l_i_a_s_e_s    _{_t_t_l_}   _a_d_d_r_-_c_l_a_s_s   _C_N_A_M_E   _C_a_n_o_n_i_c_a_l _n_a_m_e
         ucbmonet           IN           CNAME   monet

         The  _C_a_n_o_n_i_c_a_l  _N_a_m_e resource record, _C_N_A_M_E, speci-
         fies an alias or  nickname  for  the  official,  or
         canonical,  host  name.   This record should be the
         only one associated with the alias name.  All other
         resource  records  should  be  associated  with the
         canonical  name,  not  with  the   nickname.    Any
         resource  records  that  include  a  domain name as
         their value (e.g., NS or MX) _m_u_s_t list the  canoni-
         cal name, not the nickname.

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

      66..55..99..  PPTTRR -- DDoommaaiinn NNaammee PPooiinn