file.lst

早期freebsd实现

                NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee
                          ffoorr BBIINNDD
                        _R_e_l_e_a_s_e _4_._9

                     _R_e_l_e_a_s_e_s _f_r_o_m _4_._9
                         Paul Vixie
                     <[e-mail]>
                       <[e-mail]>

               Digital Equipment Corporation
                 Network Systems Laboratory
                   250 University Avenue
                    Palo Alto  CA  94301


                   _R_e_l_e_a_s_e_s _t_h_r_o_u_g_h _4_._8_._3
                      Kevin J. Dunlap*
                     Michael J. Karels

              Computer Systems Research Group
                 Computer Science Division
 Department of Electrical Engineering and Computer Sciences
                  University of California
                    Berkeley  CA  94720





11..  IInnttrroodduuccttiioonn

        The Berkeley Internet Name Domain (BIND)  implements
   an  Internet  name  server for the UNIX operating system.
   The BIND consists of  a  server  (or  ``daemon'')  and  a
   _r_e_s_o_l_v_e_r  library.   A  name  server is a network service
   that enables clients to name  resources  or  objects  and
   share this information with other objects in the network.
   This in effect is a  distributed  data  base  system  for
   objects  in a computer network.  BIND is fully integrated
   into BSD (4.3 and later releases)  network  programs  for
   use  in  storing  and  retrieving host names and address.
____________________
   *  The author was an employee of Digital Equipment Corpo-
ration's Ultrix Engineering Advanced Development  Group  and
was  on  loan  to CSRG when this work was done.  Ultrix is a
trademark of Digital Equipment Corporation.
   UNIX is a Trademark of AT&T Bell Laboratories












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


   The system administrator can configure the system to  use
   BIND  as  a replacement to the older host table lookup of
   information in the network hosts  file  _/_e_t_c_/_h_o_s_t_s.   The
   default configuration for BSD uses BIND.


22..  BBuuiillddiinngg AA SSyysstteemm wwiitthh aa NNaammee SSeerrvveerr

        BIND  is  composed  of  two  parts.  One is the user
   interface called the _r_e_s_o_l_v_e_r which consists of  a  group
   of  routines  that  reside  in the C library _/_l_i_b_/_l_i_b_c_._a.
   Second is the actual server called _n_a_m_e_d.  This is a dae-
   mon that runs in the background and services queries on a
   given network port. The standard port for UDP and TCP  is
   specified in _/_e_t_c_/_s_e_r_v_i_c_e_s.

   22..11..  RReessoollvveerr RRoouuttiinneess iinn lliibbcc

           When  building  your 4.3BSD system you may either
      build the C library to use the  name  server  resolver
      routines  or  use the host table lookup routines to do
      host  name  and  address  resolution.    The   default
      resolver  for  4.3BSD uses the name server.  Newer BSD
      systems include both name server and host table  func-
      tionality  with preference given to the name server if
      there is one or if there is a _/_e_t_c_/_r_e_s_o_l_v_._c_o_n_f file.

           Building the C library to  use  the  name  server
      changes  the way _g_e_t_h_o_s_t_b_y_n_a_m_e(3N), _g_e_t_h_o_s_t_b_y_a_d_d_r(3N),
      and  _s_e_t_h_o_s_t_e_n_t(3N)  do  their  functions.   The  name
      server  renders  _g_e_t_h_o_s_t_e_n_t(3N) obsolete, since it has
      no concept of a next  line  in  the  database.   These
      library  calls  are  built  with the resolver routines
      needed to query the name server.

           The _r_e_s_o_l_v_e_r contains functions that build  query
      packets and exchange them with name servers.

           Before  building  the  4.3BSD  C library, set the
      variable    _H_O_S_T_L_O_O_K_U_P    equal    to     _n_a_m_e_d     in
      _/_u_s_r_/_s_r_c_/_l_i_b_/_l_i_b_c_/_M_a_k_e_f_i_l_e.  You then make and install
      the C library and compiler and then compile  the  rest
      of  the  4.3BSD system.  For more information see sec-
      tion 6.6 of ``Installing and Operating 4.3BSD  on  the
      VAX''.

           If  your operating system isn't VAX 4.3BSD, it is
      probably  the  case  that  your  vendor  has  included
      _r_e_s_o_l_v_e_r  support  in  the  supplied  C  Library.  You
____________________
   VAX is a Trademark of Digital Equipment Corporation












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


      should consult your vendor's documentation to find out
      what  has to be done to enable _r_e_s_o_l_v_e_r support.  Note
      that your vendor's _r_e_s_o_l_v_e_r may be out  of  date  with
      respect  to  the  one  shipped with BIND, and that you
      might  want  to  build  BIND's  resolver  library  and
      install  it, and its include files, into your system's
      compile/link path so that your  own  network  applica-
      tions will be able to use the newer features.


   22..22..  TThhee NNaammee SSeerrvviiccee

           The  basic function of the name server is to pro-
      vide information about network  objects  by  answering
      queries.   The specifications for this name server are
      defined in RFC1034, RFC1035 and RFC974.   These  docu-
      ments can be found in _/_u_s_r_/_s_r_c_/_e_t_c_/_n_a_m_e_d_/_d_o_c in 4.3BSD
      or _f_t_ped from ffttpp..rrss..iinntteerrnniicc..nneett.  It is also  recom-
      mended   that  you  read  the  related  manual  pages,
      _n_a_m_e_d(8), _r_e_s_o_l_v_e_r(3), and _r_e_s_o_l_v_e_r(5).

           The advantage of using a  name  server  over  the
      host table lookup for host name resolution is to avoid
      the need for a single  centralized  clearinghouse  for
      all  names.  The authority for this information can be
      delegated to the different organizations on  the  net-
      work responsible for it.

           The  host  table lookup routines require that the
      master file for the entire network be maintained at  a
      central location by a few people.  This works fine for
      small networks where there are only a few machines and
      the different organizations responsible for them coop-
      erate.  But this does not work well for large networks
      where machines cross organizational boundaries.

           With  the  name server, the network can be broken
      into a hierarchy of domains.  The name space is  orga-
      nized  as a tree according to organizational or admin-
      istrative boundaries.  Each node, called a _d_o_m_a_i_n,  is
      given  a label, and the name of the domain is the con-
      catenation of all the labels of the domains  from  the
      root  to the current domain, listed from right to left
      separated by dots.  A label need only be unique within
      its  domain.  The whole space is partitioned into sev-
      eral areas called _z_o_n_e_s, each starting at a domain and
      extending down to the leaf domains or to domains where
      other zones start.  Zones usually  represent  adminis-
      trative  boundaries.  An example of a host address for
      a host at the University of California, Berkeley would
      look as follows:

          _m_o_n_e_t.._B_e_r_k_e_l_e_y.._E_D_U










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


      The  top level domain for educational organizations is
      EDU; Berkeley is a subdomain of EDU and monet  is  the
      name of the host.


   22..33..  AAbboouutt HHeessiioodd,, aanndd HHSS--ccllaassss RReessoouurrccee RReeccoorrddss

           Hesiod,  developed  by  MIT Project Athena, is an
      information service built upon BIND.   Its  intent  is
      similar  to  that of Sun's NIS: to furnish information
      about users, groups, network-accessible file  systems,
      printcaps,  and  mail  service throughout an installa-
      tion.  Aside from its use of BIND rather than separate
      server  code another important difference between Hes-
      iod and NIS is that Hesiod is  not  intended  to  deal
      with  passwords and authentication, but only with data
      that are not security sensitive.  Hesiod  servers  can
      be  implemented  by  adding  resource  records to BIND
      servers;  or  they  can  be  implemented  as  separate
      servers separately administered.

           To  learn  about and obtain Hesiod make an anony-
      mous FTP connection to  host  ATHENA-DIST.MIT.EDU  and
      retrieve  the  compressed  tar  file ppuubb//hheessiioodd..ttaarr..ZZ.
      You will not need the named and resolver library  por-
      tions  of the distribution because their functionality
      has already been integrated into BIND 4.9.   To  learn
      how  Hesiod  functions as part of the Athena computing
      environment  obtain   the   paper   ppuubb//uusseenniixx//aatthheennaa--
      cchhaannggeess..PPSS  from  the above FTP server host.  There is
      also a tar file of sample Hesiod resource files.

           Whether one should use Hesiod class  is  open  to
      question, since the same services can probably be pro-
      vided with class IN, type TXT and type CNAME  records.
      In either case, the code and documents for Hesiod will
      suggest how to set up and use the service.

           Note that while BIND  includes  support  for  _H_S-
      class  queries,  the  zone  transfer logic for non-_I_N-
      class zones is still experimental.


   22..44..  AAbboouutt ````sseeccuurree zzoonneess''''

           Secure zones implement named security on  a  zone
      by  zone  basis.   It  is designed to use a permission
      list of networks or hosts which may obtain  particular
      information from the zone.

           In order to use zone security, named must be com-
      piled with SECURE_ZONES defined and you must  have  at
      least  one  secure_zone  TXT RR.  Unless a secure_zone










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


      record exists for a given zone, no  restrictions  will
      be  applied  to  the data in that zone.  The format of
      the secure_zone TXT RR is:

      secure_zone     addr-class     TXT     string

           The addr-class may be either HS or IN.  The  syn-
      tax   for   the   TXT   string   is   either  "network
      address:netmask" or "host IP address:H".

           "network address:netmask" allows queries from  an
      entire network.  If the netmask is omitted, named will
      use the default netmask for the network address speci-
      fied.

           "host  IP  address:H" allows queries from a host.
      The "H" after the ":"  is  required  to  differentiate
      the  host  address  from  a network address.  Multiple
      secure_zone TXT RRs are allowed in the same zone file.

           For example, you can set up a zone to only answer
      hesiod  requests  from  the  masked  class  B  network
      130.215.0.0  and  from host 128.23.10.56 by adding the
      following two TXT RR's:

      secure_zone     HS     TXT     "130.215.0.0:255.255.0.0"
      secure_zone     HS     TXT     "128.23.10.56:H"