file.lst

早期freebsd实现

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


         relative path names.  There can be only one  _d_i_r_e_c_-
         _t_o_r_y  directive  and  it should be given before any
         other directives that specify file names.

             _d_i_r_e_c_t_o_r_y        _/_v_a_r_/_n_a_m_e_d

         If you have more than a couple of named files to be
         maintained,  you  may wish to place the named files
         in a directory such as /var/named  and  adjust  the
         directory  command  properly.  The main purposes of
         this command are to  make  sure  named  is  in  the
         proper  directory  when  trying to include files by
         relative path names  with  $Include  and  to  allow
         named  to  run  in a location that is reasonable to
         dump core if it feels the urge.

      66..11..33..  PPrriimmaarryy SSeerrvviiccee

              The line in the boot file that designates  the
         server as a primary server for a zone looks as fol-
         lows:

             _p_r_i_m_a_r_y          _B_e_r_k_e_l_e_y.._E_d_u   _u_c_b_h_o_s_t_s

         The first field specifies that the server is a pri-
         mary  one  for the zone stated in the second field.
         The third field is the name of the file from  which
         the data is read.

      66..11..44..  SSeeccoonnddaarryy SSeerrvviiccee

              The  line for a secondary server is similar to
         the primary except that it lists addresses of other
         servers  (usually  primary  servers) from which the
         zone data will be obtained.

             _s_e_c_o_n_d_a_r_y        _B_e_r_k_e_l_e_y.._E_d_u   _1_2_8.._3_2.._0.._1_0  _1_2_8.._3_2.._0.._4 _u_c_b_h_o_s_t_s_._b_a_k

         The first field specifies that the server is a sec-
         ondary  master  server  for  the zone stated in the
         second field.  The two  network  addresses  specify
         the  name  servers  which  have  data for the zone.
         Note that at least one of these will be a  _p_r_i_m_a_r_y,
         and,  unless you are using some protocol other than
         IP/DNS for your zone transfer mechanism, the others
         will  all  be other _s_e_c_o_n_d_a_r_y servers.  Having your
         secondary server pull  data  from  other  secondary
         servers  is usually unwise, since you can add delay
         to the propagation of zone  updates  if  your  net-
         work's connectivity varies in pathological but com-
         mon ways.  The intended use for multiple  addresses
         on  a  _s_e_c_o_n_d_a_r_y  declaration  is  when the _p_r_i_m_a_r_y
         server  has   multiple   network   interfaces   and










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


         therefore  multiple  host addresses.  The secondary
         server gets its data across the network from one of
         the listed servers.  The server addresses are tried
         in the order listed.   If  a  filename  is  present
         after  the  list  of  primary servers, data for the
         zone will be dumped into that  file  as  a  backup.
         When  the  server  is  first  started,  the data is
         loaded from the backup file if possible, and a pri-
         mary  server  is  then  consulted to check that the
         zone is still up-to-date.  Note that  listing  your
         server  as a _s_e_c_o_n_d_a_r_y server does not neccessarily
         make it  one  --  the  parent  zone  must  _d_e_l_e_g_a_t_e
         authority to your server as well as the primary and
         the other secondaries, or you will be  transferring
         a  zone  over  for  no reason; no other server will
         have a reason to query you for that zone unless the
         parent zone lists you as a server for the zone.

      66..11..55..  CCaacchhiinngg SSeerrvveerr

              You  do  not  need a special line to designate
         that a server is a caching server.  What denotes  a
         ``caching only'' server is the absence of authority
         lines, such as _s_e_c_o_n_d_a_r_y or  _p_r_i_m_a_r_y  in  the  boot
         file.

              All   servers,   including   ``caching  only''
         servers, should have a line as follows in the  boot
         file to prime the name servers cache:

             _c_a_c_h_e                           ..            _r_o_o_t.._c_a_c_h_e

         All  cache  files  listed  will be read in at named
         boot time and any values still valid will be  rein-
         stated  in the cache and the root nameserver infor-
         mation in the cache files will be used until a root
         query  is  actually  answered  by  one  of the name
         servers in your cache  file,  at  which  time  that
         answer  will  be  used  until it times out and your
         cache file will be ignored.

              Do not put  anything  into  your  _c_a_c_h_e  files
         other than root server information.

      66..11..66..  FFoorrwwaarrddeerrss

              Any server can make use of _f_o_r_w_a_r_d_e_r_s.  A _f_o_r_-
         _w_a_r_d_e_r is  another  server  capable  of  processing
         recursive  queries that is willing to try resolving
         queries on behalf of other systems.  The _f_o_r_w_a_r_d_e_r_s
         command specifies forwarders by internet address as
         follows:











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


             _f_o_r_w_a_r_d_e_r_s                      _1_2_8.._3_2.._0.._1_0  _1_2_8.._3_2.._0.._4

         There are two main reasons for wanting  to  do  so.
         First,  some  systems  may  not  have  full network
         access and may be prevented  from  sending  any  IP
         packets into the rest of the Internet and therefore
         must rely on a forwarder which does have access  to
         the  full  net.  The second reason is that the for-
         warder sees a union of all  queries  as  they  pass
         through  his  server  and  therefore it builds up a
         very rich cache of data compared to the cache in  a
         typical  workstation  nameserver.   In  effect, the
         _f_o_r_w_a_r_d_e_r becomes a meta-cache that all  hosts  can
         benefit  from, thereby reducing the total number of
         queries from that site to the rest of the net.

              The effect of  ``forwarders''  is  to  prepend
         some fixed addresses to the list of name servers to
         be tried for every query.  Normally  that  list  is
         made up only of higher-authority servers discovered
         via _N_S record lookups for the relevant domain.   If
         the forwarders do not answer, then unless the _s_l_a_v_e
         directive was given, the  appropriate  servers  for
         the domains will be queried directly.

      66..11..77..  SSllaavvee SSeerrvveerrss

              Slave mode is used if the use of forwarders is
         the only possible way to  resolve  queries  due  to
         lack  of  full net access or if you wish to prevent
         the nameserver from using  other  than  the  listed
         forwarders.  Slave mode is activated by placing the
         simple command

             _s_l_a_v_e

         in the bootfile.  If _s_l_a_v_e is used, then  you  must
         specify forwarders.  When in slave mode, the server
         will forward each query to each  of  the  the  for-
         warders  until  an  answer  is found or the list of
         forwarders is exhausted.  The server will  not  try
         to  contact any remote name server other than those
         named in the _f_o_r_w_a_r_d_e_r_s list.

              So while _f_o_r_w_a_r_d_e_r_s adds to  the  end  of  the
         ``server  list''  for  each query, _s_l_a_v_e causes the
         ``server list'' to  contain  _o_n_l_y  those  addresses
         listed  in  the  _f_o_r_w_a_r_d_e_r_s declarations.  Careless
         use of the _s_l_a_v_e directive can cause really  horri-
         ble  forwarding  loops, since you could end up for-
         warding queries only to some set of hosts which are
         also  slaves,  and  one or several of them could be
         forwarding queries back to you.










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


              Use of the _s_l_a_v_e directive should  be  consid-
         ered very carefully.

      66..11..88..  ZZoonnee TTrraannssffeerr RReessttrriiccttiioonnss

              It may be the case that your organization does
         not wish to give complete lists of  your  hosts  to
         anyone  on  the  Internet  who  can reach your name
         servers.  While it is still possible for people  to
         ``iterate'' through your address range, looking for
         _P_T_R records, and build a list  of  your  hosts  the
         ``slow''  way, it is still considered reasonable to
         restrict your export of zones via the zone transfer
         protocol.   To  limit the list of neighbors who can
         transfer zones from your server, use the

             _x_f_r_n_e_t_s

         directive.  This directive has the same  syntax  as
         _f_o_r_w_a_r_d_e_r_s except that you can list network numbers
         in addition to host addresses.   For  example,  you
         could  add  the  directive  _x_f_r_n_e_t_s _1_6_._0_._0_._0 if you
         wanted to permit only hosts on Class A network num-
         ber 16 to transfer zones from your server.  This is
         not nearly granular enough, and a future version of
         BIND  will  permit such access-control to be speci-
         fied on a per-zone basis rather  than  the  current
         ``global'' basis.

              The  _x_f_r_n_e_t_s  directive  may  also be given as
         _t_c_p_l_i_s_t for compatibility with interim releases  of
         BIND 4.9.

              Note  that  _x_f_r_n_e_t_s  support is a compile-time
         option which your vendor may not have enabled  when
         they built your operating system.

      66..11..99..  SSoorrttiinngg AAddddrreesssseess

              If  there are multiple addresses available for
         a name server which BIND  wants  to  contact,  BIND
         will  try  the  ones  it  believes  are ``closest''
         first.  ``Closeness'' is defined in terms of  simi-
         larity-of-address;  that  is,  if one address is on
         the same _s_u_b_n_e_t as  some  interface  of  the  local
         host, then that address will be tried first.  Fail-
         ing that, an address which is on the  same  _n_e_t_w_o_r_k
         will  be  tried  first.  Failing that, they will be
         tried in a more-or-less  random  order  unless  the
         _s_o_r_t_l_i_s_t  directive  was  given  in  the _n_a_m_e_d_._b_o_o_t
         file.  _s_o_r_t_l_i_s_t has a syntax similar to  _f_o_r_w_a_r_d_e_r_s
         and  _x_f_r_n_e_t_s; you give it a list of networks and it
         uses these to ``prefer'' some  remote  name  server










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


         addresses over others.  If you are on a Class C net
         which has a Class B net between you and the rest of
         the  Internet,  you  could  try to improve the name
         server's luck in getting  answers  by  listing  the
         Class  B  network's number in a _s_o_r_t_l_i_s_t directive.
         This should have the effect  of  trying  ``closer''
         servers  before  the  more  ``distant'' ones.  Note
         that this behaviour is new in BIND 4.9.

              The other and older  effect  of  the  _s_o_r_t_l_i_s_t
         directive is to cause BIND to sort the _A records in
         any response it generates, so as to put those which
         appear  on the _s_o_r_t_l_i_s_t earlier than those which do
         not.  This is not as helpful as  you  might  think,
         since  many  clients  will  reorder  the  _A records
         either at random or using LIFO.

              In actual practice, noone uses this  directive
         since   it   hardwires  information  which  changes
         rapidly; a network which is ``close'' today may  be
         ``distant''  next  month.   Since  BIND builds up a
         cache of the remote name servers'  response  times,
         it   will   quickly   converge   on  ``reasonable''
         behaviour, which isn't the same as ``optimal''  but
         it's  close  enough.   Future  directions  for BIND
         include choosing addresses based on local interface
         metrics  (on  hosts  which  have more than one) and
         perhaps on routing table information.   We  do  not
         intend   to  solve  the  generalized  ``multi-homed
         host'' problem, but we should be able to do a  lit-
         tle better than we're doing now.  Likewise, we hope
         to see a higher-level resolver library  that  sorts