










                NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee
                          ffoorr BBIINNDD
                       _R_e_l_e_a_s_e _4_._9_._5

                     _R_e_l_e_a_s_e_s _f_r_o_m _4_._9
                        Paul Vixie1
                       <paul@vix.com>

                Internet Software Consortium
                        La Honda, CA


                   _R_e_l_e_a_s_e_s _t_h_r_o_u_g_h _4_._8_._3
                      Kevin J. Dunlap2
                     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 BSD-derived operating sys-
   tems.  The BIND consists  of  a  server  (or  ``daemon'')
   called  _n_a_m_e_d 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.  The BIND
   server runs in the background,  servicing  queries  on  a
____________________
   1  This author was employed by Digital Equipment Corpora-
tion's Network Systems Laboratory during the development and
release  of  BIND 4.9.  Release 4.9.2 was sponsored by Vixie
Enterprises.  Releases from 4.9.3 were sponsored by the  In-
ternet Software Consortium.
   2 This 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.












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


   well  known  network port.  The standard port for UDP and
   TCP is specified in _/_e_t_c_/_s_e_r_v_i_c_e_s.  The _r_e_s_o_l_v_e_r is a set
   of  routines  residing  in a system library that provides
   the interface that programs can use to access the  domain
   name services.

        BIND  is  fully  integrated  into BSD (4.3 and later
   releases)  network  programs  for  use  in  storing   and
   retrieving  host  names and address.  The system adminis-
   trator can configure the system to use BIND as a replace-
   ment 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..  TThhee NNaammee SSeerrvviiccee

        The  basic function of the name server is to provide
   information about network objects by  answering  queries.
   The  specifications  for  this name server are defined in
   RFC1034, RFC1035 and  RFC974.   These  documents  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  recommended  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 dele-
   gated to  the  different  organizations  on  the  network
   responsible for it.

        The host table lookup routines require that the mas-
   ter file for the entire network be maintained at  a  cen-
   tral location by a few people.  This works fine for small
   networks where there are only a few machines and the dif-
   ferent organizations responsible for them cooperate.  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 organized as a
   tree according to organizational or administrative bound-
   aries.  Each node, called a _d_o_m_a_i_n, is given a label, and
   the  name  of  the domain is the concatenation 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  several 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 administrative boundaries.  An  example










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


   of  a  host address for a host at the University of Cali-
   fornia, Berkeley would look as follows:

       _m_o_n_e_t.._B_e_r_k_e_l_e_y.._E_D_U

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


33..  SSeeccuurriittyy

        This section examines  some  of  the  know  security
   implications  of  various versions of BIND. Some of these
   have been used to attack the nameservers in the past.

   33..11..  UUnnnneecceessssaarryy GGlluuee

           Unnecessary glue can lead  to  incorrect  records
      being  loaded into the server. This can result in con-
      nections going to the wrong machines.

           To prevent unnecessary glue being loaded, all the
      servers  of  zones  being servered by a server and the
      servers of the parent zones need  to  be  upgraded  to
      BIND 4.9.3 or later.

   33..22..   IInnsseerrttiioonn  ooff  ddaattaa  iinnttoo  aa  zzoonnee  tthhaatt  iiss bbeeiinngg
      sseerrvveerreedd

           BIND versions prior to BIND 4.9.2 are subject  to
      the  insertion of resource records into zone that they
      are serving.

   33..33..  DDeenniiaall ooff SSeerrvviiccee:: HHaasshh BBuugg EExxppllooiitt

           September 1996 saw  the  COM  TLD  subject  to  a
      denial  of  service attack by injecting into the DNS a
      record with a final label of  COM,  eight  spaces  and
      COM. This effected BIND 4.9.4 servers. Similar attacks
      are possible on BIND 4.9.3 and BIND 4.9.3-P1.

           It is recommend that you run a BIND  4.9.4-P1  or
      later server to avoid this exploit.

   33..44..  DDeenniiaall ooff SSeerrvviiccee:: TTTTLL IInnccoonnssiisstteennccyy AAttttaacckkss

           If you are still using multiple TTL values within
      a RRset you can be subject  to  a  denial  of  service
      attack.  BIND  4.9.5  onwards uses multiple ttl values
      within a RRset to reject obviously bad RRset.












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


           It is recommend that you upgrade to BIND 4.9.5 or
      later as these server prevent you loading multiple TTL
      values and doesn't merge answers received  across  the
      network.


44..  TTyyppeess ooff ZZoonneess

        A ``zone'' is a point of delegation in the DNS tree.
   It contains all names from a certain  point  ``downward''
   except  those  which  are  delegated  to  other zones.  A
   ``delegation point'' has one or more _N_S  records  in  the
   ``parent zone'', which should be matched by equivalent _N_S
   records at the root of the ``delegated zone'' (i.e.,  the
   ``@'' name in the zone file).

        Understanding  the difference between a ``zone'' and
   a ``domain'' is crucial to the proper operation of a name
   server.   As  an  example,  consider  the DEC.COM _d_o_m_a_i_n,
   which includes names such as POBOX1.PA.DEC.COM and  QUAB-
   BIN.CRL.DEC.COM  even  though  the  DEC.COM _z_o_n_e includes
   only  _d_e_l_e_g_a_t_i_o_n_s  for  the  PA.DEC.COM  and  CRL.DEC.COM
   zones.   A  zone  can map exactly to a single domain, but
   could also include only part of a  domain  (the  rest  of
   which could be delegated to other name servers).  Techni-
   cally  speaking,  every  name  in  the  DNS  tree  is   a
   ``domain'',  even  if it is ``terminal'', that is, has no
   ``subdomains''.  Technically speaking, every subdomain is
   a  domain and every domain except the root is also a sub-
   domain.  The terminology is not intuitive and  you  would
   do well to read RFC's 1033, 1034, and 1035 to gain a com-
   plete understanding of this difficult and subtle topic.

        Though BIND is a _D_o_m_a_i_n Name Server, it  deals  pri-
   marily in terms of _z_o_n_e_s.  The _p_r_i_m_a_r_y and _s_e_c_o_n_d_a_r_y dec-
   larations in  the  _n_a_m_e_d_._b_o_o_t  file  specify  _z_o_n_e_s,  not
   _d_o_m_a_i_n_s.   When you ask someone if they are willing to be
   a secondary server for your ``domain'', you are  actually
   asking  for  secondary  service  for  some  collection of
   _z_o_n_e_s.

        Each zone will have one  ``primary''  server,  which
   loads  the  zone  contents  from some local file which is
   edited by humans or perhaps generated  mechanically  from
   some  other  local  file which is edited by humans.  Then
   there will be some number of ``secondary'' servers, which
   load  the  zone  contents using the IP/DNS protocol (that
   is, the secondary servers will contact  the  primary  and
   fetch  the  zone using IP/TCP).  This set of servers (the
   primary and all of the secondaries) should be  listed  in
   the  _N_S records in the parent zone, which will constitute
   a ``delegation''.  This  set  of  servers  must  also  be
   listed  in  the zone file itself, usually under the ``@''










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


   name which is a magic cookie that means the ``top level''
   or ``root'' of current zone.  You can list servers in the
   zone's top-level ``@'' _N_S records that  are  not  in  the
   parent's  _N_S  delegation,  but you cannot list servers in
   the parent's delegation  that  are  not  present  in  the
   zone's  ``@''.  Any servers listed in the _N_S records must
   be configured as authoritative (either  primary  or  sec-
   ondary)  for the zone.  If a server listed in a _N_S record
   is not authoritative, it will respond with a ``lame dele-
   gation'' when queried.


55..  TTyyppeess ooff SSeerrvveerrss

        Servers  do not really have ``types''.  A server can
   be a primary for some zones and a secondary  for  others,
   or  it  can be only a primary, or only a secondary, or it
   can serve no  zones  and  just  answer  queries  via  its
   ``cache''.   Previous  versions of this document referred
   to servers as ``master'' and ``slave'' but  we  now  feel
   that  those  distinctions  --  and  the  assignment  of a
   ``type'' to a name server -- are not useful.

   55..11..  CCaacchhiinngg OOnnllyy SSeerrvveerr

           All servers are caching servers.  This means that
      the server caches the information that it receives for
      use until the data expires.  A _C_a_c_h_i_n_g _O_n_l_y _S_e_r_v_e_r  is
      a server that is not authoritative for any zone.  This
      server services queries and asks  other  servers,  who
      have  the  authority, for the information needed.  All
      servers keep  data  in  their  cache  until  the  data
      expires, based on a _T_T_L (``Time To Live'') field which
      is maintained for all resource records.

   55..22..  RReemmoottee SSeerrvveerr

           A Remote Server is an option given to people  who
      would like to use a name server from their workstation
      or on a machine that has a limited  amount  of  memory
      and  CPU  cycles.  With this option you can run all of
      the networking programs that use the name server with-
      out the name server running on the local machine.  All
      of the queries are serviced by a name server  that  is
      running  on  another  machine  on the network.  A host
      which has an _/_e_t_c_/_r_e_s_o_l_v_._c_o_n_f file listing only remote
      hosts,  and  which  does  not run a name server of its
      own, is sometimes called a Remote Server (because  the
      actual  server is remote?) but more often it is called
      simply a DNS Client.  This kind of host is technically
      not  a  ``server'', since it has no cache and does not
      answer queries.











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


   55..33..  SSllaavvee SSeerrvveerr

           A Slave Server is a server that  always  forwards
      queries  it  cannot satisfy from its cache, to a fixed
      list of _f_o_r_w_a_r_d_i_n_g servers instead of interacting with
      the  name servers for the root and other domains.  The
      queries  to  the  _f_o_r_w_a_r_d_i_n_g  _s_e_r_v_e_r_s  are   recursive
      queries.  There may be one or more forwarding servers,
      and  they  are  tried  in  turn  until  the  list   is
      exhausted.   A  Slave  and  forwarder configuration is
      typically used when you do not wish all the servers at
      a given site to interact with the rest of the Internet
      servers.  A typical scenario would involve a number of
      workstations  and  a  departmental timesharing machine
      with  Internet  access.   The  workstations  might  be
      administratively   prohibited   from  having  Internet
      access.  To give the workstations  the  appearance  of
      access to the Internet domain system, the workstations
      could be Slave  servers  to  the  timesharing  machine
      which  would  forward  the  queries  and interact with
      other name servers to resolve the query before return-
      ing  the  answer.   An added benefit of using the for-
      warding feature is that the central machine develops a
      much  more  complete cache of information that all the
      workstations can take advantage of.  The use of  Slave
      mode  and  forwarding  is  discussed further under the
      description of the _n_a_m_e_d bootfile commands.

           There  is  no  prohibition  against  declaring  a
      server to be a _s_l_a_v_e even though it has _p_r_i_m_a_r_y and/or
      _s_e_c_o_n_d_a_r_y zones as well; the effect will still be that
      anything  in the local server's cache or zones will be
      answered, and anything else will  be  forwarded  using
      the _f_o_r_w_a_r_d_e_r_s list.


66..  FFiilleess

        The  name server uses several files to load its data
   base.  This section covers the files  and  their  formats
   needed for _n_a_m_e_d.

   66..11..  BBoooott FFiillee

           This  is  the  file that is first read when _n_a_m_e_d
      starts up.  This tells the server what type of  server
      it  is, which zones it has authority over and where to
      get its initial data.  The default location  for  this
      file  is _/_e_t_c_/_n_a_m_e_d_._b_o_o_t.  However this can be changed
      by setting the  _B_O_O_T_F_I_L_E  variable  when  you  compile
      _n_a_m_e_d  or  by  specifying  the location on the command
      line when _n_a_m_e_d is started up.











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


      66..11..11..  DDoommaaiinn

              A default domain may be specified for the name
         server using a line such as

             _d_o_m_a_i_n           _B_e_r_k_e_l_e_y.._E_d_u

         Older  name  servers use this information when they
         receive a query for a name without a ``..'' that  is
         not  known.  Newer designs assume that the resolver
         library will append its own  idea  of  a  ``default
         domain'' to any unqualified names.  Though the name
         server can still be compiled with support  for  the
         _d_o_m_a_i_n  directive  in the boot file, the default is
         to  leave  it  out  and  we  strenuously  recommend
         against  its use.  If you use this feature, clients
         outside your local domain which send  you  requests
         about  unqualified  names  will  have  the implicit
         qualification of your domain  rather  than  theirs.
         The  proper  place  for  this  function  is  on the
         client, in their //eettcc//rreessoollvv..ccoonnff  (or  equivalent)
         file.   Use  of  the  _d_o_m_a_i_n directive in your boot
         file is strongly discouraged.

      66..11..22..  DDiirreeccttoorryy

              The _d_i_r_e_c_t_o_r_y directive specifies  the  direc-
         tory  in which the name server should run, allowing
         the other file names in the boot file to use  rela-
         tive  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 master server for a zone  looks
         as follows:

             _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











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


         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.

              The above assumes that the zone you are speci-
         fying is a class _I_N zone.  If you wish to designate
         a different class you  can  append  _/_c_l_a_s_s  to  the
         first  field,  where  _c_l_a_s_s  is  either the integer
         value or the standard mnemonic for the class.   For
         example  the line for a primary server for a hesiod
         class zone looks as follows:

             _p_r_i_m_a_r_y_/_H_S         _B_e_r_k_e_l_e_y.._E_d_u    _h_e_s_i_o_d_._d_a_t_a

         Note that this support for  specifying  other  than
         class  _I_N zones is a compile-time option which your
         vendor may not have enabled when  they  built  your
         operating system.

      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  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 network's  con-
         nectivity  varies  in pathological but common 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 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 primary server is then consulted to
         check that the zone is still up-to-date.  Note that










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


         listing your server as a _s_e_c_o_n_d_a_r_y server does  not
         necessarily  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.

              As  with  primary  you may specify a secondary
         server for a  class  other  than  _I_N  by  appending
         _/_c_l_a_s_s   to   the  _s_e_c_o_n_d_a_r_y  keyword,  e.g.,  _s_e_c_-
         _o_n_d_a_r_y_/_H_S.

      66..11..55..  SSttuubb SSeerrvviiccee

              The line for a stub server  is  similar  to  a
         secondary.   (This  feature  is  experimental as of
         4.9.3.)

             _s_t_u_b _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 stub
         server for the zone stated in the second field.

              Stub  zones are intended to ensure that a pri-
         mary for a zone always has the correct  _N_S  records
         for  children of that zone. If the primary is not a
         secondary for a child zone it should be  configured
         with  stub  zones  for all its children. Stub zones
         provide a mechanism to allow _N_S records for a  zone
         to be specified in only one place.

             _p_r_i_m_a_r_y        _C_S_I_R_O.._A_U       _c_s_i_r_o_._d_a_t
             _s_t_u_b _d_m_s_._C_S_I_R_O.._A_U             _1_3_0.._1_5_5.._1_6.._1  _d_m_s_._s_t_u_b
             _s_t_u_b _d_a_p_._C_S_I_R_O.._A_U             _1_3_0.._1_5_5.._9_8.._1  _d_a_p_._s_t_u_b


      66..11..66..  CCaacchhee IInniittiiaalliizzaattiioonn

              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

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

              All cache files listed  will  be  read  in  at
         named  boot time and any values still valid will be
         reinstated in the  cache.   The  root  name  server
         information in the cache files will be used until a










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


         root query is actually answered by one of the  name
         servers  in the cache file, after which that answer
         will be used instead of the cache  file  until  the
         answer times out.

              As with _p_r_i_m_a_r_y and _s_e_c_o_n_d_a_r_y, you may specify
         a secondary server for a class  other  than  _I_N  by
         appending   _/_c_l_a_s_s  to  the  _c_a_c_h_e  keyword,  e.g.,
         _c_l_a_s_s_/_H_S.

      66..11..77..  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:

             _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 its server and therefore  it  builds  up  a
         very  rich cache of data compared to the cache in a
         typical workstation name server.   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..88..  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  name  server  from using other than the listed
         forwarders.  Slave mode is activated by placing the
         simple command










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


             _o_p_t_i_o_n_s _f_o_r_w_a_r_d_-_o_n_l_y

         in  the bootfile.  If this option is used, then you
         must specify forwarders.  When in slave  mode,  the
         server  will forward each query to each of 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 prepends addresses to the
         ``server list'' for each  query,  _o_p_t_i_o_n_s  _f_o_r_w_a_r_d_-
         _o_n_l_y  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  declara-
         tions.   Careless  use  of the _o_p_t_i_o_n_s _f_o_r_w_a_r_d_-_o_n_l_y
         directive  can  cause  really  horrible  forwarding
         loops,  since  you  could end up forwarding queries
         only to some set of hosts which  are  also  slaves,
         and  one  or  several  of  them could be forwarding
         queries back to you.

              Use  of  the  _o_p_t_i_o_n_s  _f_o_r_w_a_r_d_-_o_n_l_y  directive
         should  be  considered  very  carefully.  Note that
         this same behaviour can be achieved using the  dep-
         recated directive, _s_l_a_v_e.


      66..11..99..  NNoonnrreeccuurrssiivvee SSeerrvveerrss

              BIND's  separation of authoritative (zone) and
         nonauthoritiative  (cache)  data  has  always  been
         somewhat  weak, and pollution of the former via the
         latter has been known to occur.  One way to prevent
         this, as well as to save memory on servers carrying
         a lot of authoritative data (e.g., root servers) is
         to make such servers ``nonrecursive.''  This can be
         achieved via the directive

             _o_p_t_i_o_n_s _n_o_-_r_e_c_u_r_s_i_o_n

         in the bootfile.  A server with this option enabled
         will  not  attempt  to  fetch  data  to help answer
         queries -- if you ask it for data it does not have,
         it will send you a referral to a more authoritative
         server or, if it is itself  authoritative  for  the
         zone  of  the  query,  it will send you an negative
         answer.

              A nonrecursive server can be named in an NS RR
         but it cannot be listed in the _r_e_s_o_l_v_._c_o_n_f file.













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


      66..11..1100..  QQuueerryy LLooggggiinngg

              If the file system containing your _s_y_s_l_o_g file
         has quite a bit of space, you  can  consider  using
         the

             _o_p_t_i_o_n_s _q_u_e_r_y_-_l_o_g

         directive  in  your bootfile.  This will cause your
         name server to log every query it  receives,  which
         when combined with a Perl or AWK script to postpro-
         cess the logs, can be a useful management tool.


      66..11..1111..  IInnvveerrssee QQuueerryy PPsseeuuddoossuuppppoorrtt

              BIND  by  default  does  not  support  inverse
         queries,  and this has been known to cause problems
         for certain microcomputer operating systems and for
         older  versions  of  BIND's _n_s_l_o_o_k_u_p tool.  You may
         decide that rather than answering with  ``operation
         not  implemented,''  _n_a_m_e_d  should  detect the most
         common inverse queries and answer them  with  bogus
         information.   It is better to upgrade your clients
         to stop depending on inverse queries, but  if  that
         is not possible, you should use the

             _o_p_t_i_o_n_s _f_a_k_e_-_i_q_u_e_r_y

         directive  in  your  bootfile.  _N_O_T_E_: the responses
         are in fact bogus, in  that  they  contain  ISO8859
         square brackets ([[ and ]]), so your clients will not
         be able to do anything useful with these responses.
         It  has  been observed that no client ever did any-
         thing useful with  real  inverse  query  responses,
         either.


      66..11..1122..  SSeettttiinngg NNaammee SSeerrvveerr LLiimmiittss

              Some  name  server  operations  can  be  quite
         resource intensive, and in order to tune your  sys-
         tem  properly  it  is sometimes necessary to change
         BIND's internal quotas.  This is accomplished via

             _l_i_m_i_t _<_n_a_m_e_> _<_v_a_l_u_e_>

         directives in  the  bootfile.   Limits,  and  their
         default values, are as follows:

             _l_i_m_i_t _t_r_a_n_s_f_e_r_s_-_i_n _1_0

         This  is  the  number  of  simultaneous  _n_a_m_e_d_-_x_f_e_r










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


         processes BIND is willing to start.  Higher numbers
         yield faster convergence to primary servers if your
         secondary server has hundreds or thousands of zones
         to  maintain,  but setting this number too high can
         cause thrashing due to starvation of resources such
         as  network  bandwidth  or  swap space.  _N_O_T_E_: this
         limit can also  be  expressed  via  the  deprecated
         directive _m_a_x_-_f_e_t_c_h _N_N.

             _l_i_m_i_t _t_r_a_n_s_f_e_r_s_-_p_e_r_-_n_s _2

         This  is the number of simultaneous _n_a_m_e_d_-_x_f_e_r pro-
         cesses BIND is willing to  initiate  _t_o  _a_n_y  _g_i_v_e_n
         _n_a_m_e _s_e_r_v_e_r.  In most cases, you should not need to
         change it.  If your  secondary  server  is  pulling
         hundreds  or  thousands of zones from a single pri-
         mary server, increasing _t_r_a_n_s_f_e_r_s_-_p_e_r_-_n_s may  speed
         convergence.   It should be kept as small as possi-
         ble, to avoid causing thrashing and resource  star-
         vation on the primary server.

             _l_i_m_i_t _d_a_t_a_s_i_z_e _<_s_y_s_t_e_m_-_d_e_p_e_n_d_e_n_t_>

         Most  systems  have a quota that limits the size of
         the so-called ``data segment,'' which is where BIND
         keeps  all  of  its authority and cache data.  BIND
         will behave suboptimally (perhaps even exiting)  if
         it runs up against this quota.  If your system sup-
         ports a system call to  change  this  quota  for  a
         given  process, you can ask BIND to use that system
         call via the  _l_i_m_i_t  _d_a_t_a_s_i_z_e  _N_N  directive.   The
         value  given here may be scaled by postfixing _k for
         1024X, _m for (1024^2)X, and _g  for  (1024^3)X.   In
         1995,  the root servers all use _l_i_m_i_t _d_a_t_a_s_i_z_e _6_4_m.


      66..11..1133..  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










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


         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 net-
         work number 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  specified  on  a per-host basis rather than the
         current per-net basis.  Note that  while  addresses
         without  explicit  masks are assumed by this direc-
         tive to be networks, you can specify a  mask  which
         is  as  granular as you wish, perhaps including all
         bits of the address such that only a single host is
         given transfer permission.  For example, consider

             _x_f_r_n_e_t_s _1_6_._1_._0_._2_&_2_5_5_._2_5_5_._2_5_5_._2_5_5

         which  would  permit only host _1_6_._1_._0_._2 to transfer
         zones from you.  Note that no  spaces  are  allowed
         surrounding  the  ``_&'' character that introduces a
         netmask.

              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.


      66..11..1144..  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,
         _x_f_r_n_e_t_s, and _b_o_g_u_s_n_s -- you give it a list of  dot-
         ted-quad  networks  and it uses these to ``prefer''
         some remote name server addresses over others.   If
         no explicit mask is provided with each element of a
         _s_o_r_t_l_i_s_t, one will be inferred based  on  the  high
         order address bits.

              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 get-
         ting answers  by  listing  the  Class  B  network's










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


         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 as of 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; also, consider  the
         fact  that  the  server  won't be able to guess the
         client's network topology, and so will not be  able
         to accurately order for ``closeness'' to all possi-
         ble clients.  Doing the ordering in the resolver is
         clearly superior.

              In  actual  practice,  this  directive is used
         only rarely 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 that have more than one) and per-
         haps  on  routing  table  information.   We  do not
         intend to solve the generalized ``multihomed host''
         problem,  but we should be able to do a little bet-
         ter than we're doing now.  Likewise, we hope to see
         a   higher   level   resolver  library  that  sorts
         responses  using  topology  information  that  only
         exists on the client's host.


      66..11..1155..  BBoogguuss NNaammee SSeerrvveerrss

              It  happens occasionally that some remote name
         server goes ``bad''.  You can tell your name server
         to  refuse to listen to or ask questions of certain
         other name servers by listing  them  in  a  _b_o_g_u_s_n_s
         directive  in  your _n_a_m_e_d_._b_o_o_t file.  Its syntax is
         the same as _f_o_r_w_a_r_d_e_r_s, _x_f_r_n_e_t_s,  and  _s_o_r_t_l_i_s_t  --
         you  just  give  it  a list of dotted-quad Internet
         addresses.   Note  that  zones  delegated  to  such
         servers  will not be reachable from clients of your
         servers; thus you should use this  directive  spar-
         ingly or not at all.













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


      66..11..1166..  SSeeggmmeenntteedd BBoooott FFiilleess

              If  you  are secondary for a lot of zones, you
         may find it convenient  to  split  your  _n_a_m_e_d_._b_o_o_t
         file  into  a  static  portion  which  hardly  ever
         changes (directives such  as  _d_i_r_e_c_t_o_r_y,  _s_o_r_t_l_i_s_t,
         _x_f_r_n_e_t_s  and _c_a_c_h_e could go here), and dynamic por-
         tions that change frequently (all of  your  _p_r_i_m_a_r_y
         directives  might  go  in one file, and all of your
         _s_e_c_o_n_d_a_r_y directives might go in  another  file  --
         and  either or both of these might be fetched auto-
         matically from  some  neighbor  so  that  they  can
         change your list of secondary zones without requir-
         ing your active intervention).  You can  accomplish
         this  via the _i_n_c_l_u_d_e directive, which takes just a
         single file name as its argument.   No  quotes  are
         needed around the file name.  The file name will be
         evaluated after the name  server  has  changed  its
         working  directory  to that specified in the _d_i_r_e_c_-
         _t_o_r_y directive, so you can use  relative  pathnames
         if your system supports them.


   66..22..  RReessoollvveerr CCoonnffiigguurraattiioonn

           The      configuration     file's     name     is
      _/_e_t_c_/_r_e_s_o_l_v_._c_o_n_f.   This  file  designates  the   name
      servers  on  the  network that should be sent queries.
      The resolver will try to contact a name server on  the
      localhost  if  it  cannot find its configuration file.
      You should install the  configuration  file  on  every
      host anyway, since this is the only recommended way to
      specify a system-level default  domain,  and  you  can
      still  list the local host's address if it runs a name
      server.  It is considered reasonable  to  create  this
      file  even  if  you run a local server, since its con-
      tents will be cached by each client  of  the  resolver
      library  when  the  client  makes  its first call to a
      resolver routine.

           The _r_e_s_o_l_v_._c_o_n_f file contains directives, one per
      line, of the following forms:

          ; comment
          # another comment
          domain _l_o_c_a_l_-_d_o_m_a_i_n
          search _s_e_a_r_c_h_-_l_i_s_t
          nameserver _s_e_r_v_e_r_-_a_d_d_r_e_s_s
          sortlist _s_o_r_t_-_l_i_s_t
          options _o_p_t_i_o_n_-_l_i_s_t

      Exactly  one of the _d_o_m_a_i_n or _s_e_a_r_c_h directives should
      be given, exactly once.  If the  _s_e_a_r_c_h  directive  is










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


      given,  the  first  item in the given _s_e_a_r_c_h_-_l_i_s_t will
      override any previously-specified  _l_o_c_a_l_-_d_o_m_a_i_n.   The
      _n_a_m_e_s_e_r_v_e_r  directive  may be given up to three times;
      additional  _n_a_m_e_s_e_r_v_e_r  directives  will  be  ignored.
      Comments  may be given by starting a line with a ``;;''
      or ``##''; note that comments  were  not  permitted  in
      versions of the resolver earlier than the one included
      with BIND 4.9 -- so if your vendor's resolver supports
      comments, you know they are really on the ball.

           The  _l_o_c_a_l_-_d_o_m_a_i_n  will be appended to any query-
      name that does not contain a ``..''.  _l_o_c_a_l_-_d_o_m_a_i_n  can
      be  overridden  on  a per-process basis by setting the
      LOCALDOMAIN environment variable.   Note  that  _l_o_c_a_l_-
      _d_o_m_a_i_n processing can be disabled by setting an option
      in the resolver.

           The _s_e_a_r_c_h_-_l_i_s_t is a list of  domains  which  are
      tried, in order, as qualifying domains for query-names
      which do not contain a ``..''.  Note  that  _s_e_a_r_c_h_-_l_i_s_t
      processing can be disabled by setting an option in the
      resolver.  Also note  that  the  environment  variable
      ``LOCALDOMAIN''  can  override  this  _s_e_a_r_c_h_-_l_i_s_t on a
      per-process basis.

           The _s_e_r_v_e_r_-_a_d_d_r_e_s_s's are aggregated and then used
      as   the  default  destination  of  queries  generated
      through the resolver.  In other words, this is the way
      you  tell  the  resolver  which name servers it should
      use.  It is possible for a given client application to
      override  this list, and this is often done inside the
      name server (which is itself a _r_e_s_o_l_v_e_r client) and in
      test programs such as _n_s_l_o_o_k_u_p.  Note that if you wish
      to list the local host in your resolver  configuration
      file,  you  should  probably  use its primary Internet
      address  rather  than  a  local-host  alias  such   as
      127.0.0.1  or  0.0.0.0.   This  is due to a bug in the
      handling of connected SOCK_DGRAM sockets in some  ver-
      sions  of the BSD networking code.  If you must use an
      address-alias, you should prefer  0.0.0.0  (or  simply
      ``0'') over 127.0.0.1, though be warned that depending
      on the vintage of your  BSD-derived  networking  code,
      both of them are capable of failing in their own ways.
      If your host's IP implementation  does  not  create  a
      short-circuit  route between the default interface and
      the loopback interface, then you might  also  want  to
      add a static route (eg. in //eettcc//rrcc..llooccaall) to do so:

          _r_o_u_t_e _a_d_d _m_y_h_o_s_t_._d_o_m_a_i_n_._n_a_m_e _l_o_c_a_l_h_o_s_t _1


           The  _s_o_r_t_-_l_i_s_t  is  a list of IP address, netmask
      pairs. Addresses returned by gethostbyname are  sorted










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


      to  the  order  specified by this list.  Any addresses
      that do not match the address  netmask  pair  will  be
      returned  after those that do. The netmask is optional
      and the natural netmask will be used if not specified.

           The  _o_p_t_i_o_n_-_l_i_s_t  is a list of options which each
      override some internal resolver  variable.   Supported
      options at this time are:

      ddeebbuugg
           sets the RES_DEBUG bit in __rreess..ooppttiioonnss.

      nnddoottss::_n
           sets the lower threshold (measured in ``number of
           dots'') on names given to _r_e_s___q_u_e_r_y()  such  that
           names  with more than this number of dots will be
           tried as absolute names before  any  _l_o_c_a_l_-_d_o_m_a_i_n
           or  _s_e_a_r_c_h_-_l_i_s_t  processing is done.  The default
           for this internal variable is ``1''.


   66..33..  CCaacchhee IInniittiiaalliizzaattiioonn FFiillee

      66..33..11..  rroooott..ccaacchhee

              The name server needs to know the servers that
         are  the  authoritative  name  servers for the root
         domain of the network.  To do this we have to prime
         the name server's cache with the addresses of these
         higher authorities.  The location of this  file  is
         specified  in  the  boot  file.  This file uses the
         Standard Resource Record  Format  (aka.  Masterfile
         Format) covered further on in this paper.


   66..44..  DDoommaaiinn DDaattaa FFiilleess

           There  are  two standard files for specifying the
      data for a domain.   These  are  _h_o_s_t_s  and  _h_o_s_t_._r_e_v.
      These  files  use  the Standard Resource Record Format
      covered later in this paper.  Note that the file names
      are  arbitrary;  many network administrators prefer to
      name their zone files after the domains they  contain,
      especially  in the average case which is where a given
      server is primary and/or secondary for many  different
      zones.

      66..44..11..  hhoossttss

              This  file  contains  all  the  data about the
         machines in this zone.  The location of  this  file
         is specified in the boot file.











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


      66..44..22..  hhoossttss..rreevv

              This  file  specifies the IN-ADDR.ARPA domain.
         This is a special domain for  allowing  address  to
         name  mapping.   As  internet host addresses do not
         fall within domain boundaries, this special  domain
         was   formed   to   allow   inverse  mapping.   The
         IN-ADDR.ARPA domain has four labels  preceding  it.
         These  labels  correspond  to  the  4  octets of an
         Internet address.  All four octets must  be  speci-
         fied  even if an octet contains zero.  The Internet
         address  128.32.0.4  is  located  in   the   domain
         4.0.32.128.IN-ADDR.ARPA.    This  reversal  of  the
         address is awkward to read but allows for the natu-
         ral grouping of hosts in a network.

      66..44..33..  nnaammeedd..llooccaall

              This  file  specifies  the  _P_T_R record for the
         local loopback interface, better  known  as  _l_o_c_a_l_-
         _h_o_s_t,  whose  network  address  is  127.0.0.1.  The
         location of this file  is  specified  in  the  boot
         file.  It is vitally important to the proper opera-
         tion  of  every  name  server  that  the  127.0.0.1
         address have a _P_T_R record pointing back to the name
         ``llooccaallhhoosstt..''.  The name of  this  _P_T_R  record  is
         always  ``11..00..00..112277..IINN--AADDDDRR..AARRPPAA''.  This is neces-
         sary if you want your users to be able to use host-
         name-authentication  (_h_o_s_t_s_._e_q_u_i_v  or _~_/_._r_h_o_s_t_s) on
         the name ``llooccaallhhoosstt''.  As  implied  by  this  _P_T_R
         record,  there should be a ``llooccaallhhoosstt.._m_y_._d_o_m_._a_i_n''
         _A record (with address 127.0.0.1) in  every  domain
         that  contains hosts.  ``llooccaallhhoosstt..'' will lose its
         trailing dot when 11..00..00..112277..iinn--aaddddrr..aarrppaa is queried
         for;  then,  the  DEFNAMES  and/or  DNSRCH resolver
         options will cause ``llooccaallhhoosstt'' to be evaluated as
         a host name in the local domain, and that means the
         top domains (or  ideally,  every  domain)  in  your
         resolver's search path had better have something by
         that name.

   66..55..  SSttaannddaarrdd RReessoouurrccee RReeccoorrdd FFoorrmmaatt

           The records in the name  server  data  files  are
      called resource records.  The Standard Resource Record
      Format (RR) is specified in RFC1035.  The following is
      a general description of these records:

      _{_n_a_m_e_}   _{_t_t_l_}   _a_d_d_r_-_c_l_a_s_s   _R_e_c_o_r_d _T_y_p_e   _R_e_c_o_r_d _S_p_e_c_i_f_i_c _d_a_t_a

      Resource  records  have a standard format shown above.
      The first field is  always  the  name  of  the  domain











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


      record  and it must always start in column 1.  For all
      RR's other than the first in a file, the name  may  be
      left  blank;  in that case it takes on the name of the
      previous RR.  The second field is an optional time  to
      live field.  This specifies how long this data will be
      stored in the data base.  By leaving this field  blank
      the  default time to live is specified in the _S_t_a_r_t _O_f
      _A_u_t_h_o_r_i_t_y resource  record  (see  below).   The  third
      field  is the address class; currently, only one class
      is supported: _I_N  for  internet  addresses  and  other
      internet information.  Limited support is included for
      the _H_S  class,  which  is  for  MIT/Athena  ``Hesiod''
      information.   The fourth field states the type of the
      resource record.  The fields after that are  dependent
      on the type of the RR.  Case is preserved in names and
      data fields when loaded into  the  name  server.   All
      comparisons  and  lookups in the name server data base
      are case insensitive.

      TThhee ffoolllloowwiinngg cchhaarraacctteerrss hhaavvee ssppeecciiaall mmeeaanniinnggss::

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

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

      ``\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.   (At  present,  this
           notation  only  works  for  SOA  RR's  and is not
           optional.)

      ``;''
           Semicolon starts a comment; the remainder of  the
           line  is  ignored.   Note that a completely blank
           line is also considered a comment, and ignored.











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


      ``*''
           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 ``..''.

      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-exchanges

         The  line would be interpreted as a request to load
         the file  _/_u_s_r_/_l_o_c_a_l_/_a_d_m_/_n_a_m_e_d_/_d_a_t_a_/_m_a_i_l_-_e_x_c_h_a_n_g_e_s.
         The  $INCLUDE  command  does  not  cause data to be
         loaded into a different zone or tree. This is  sim-
         ply a way to allow data for a given primary zone to
         be organized  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.

              A $INCLUDE file must have a name on its  first
         RR.  That is, the first character of the first non-
         comment line must not  be  a  space.   The  current
         default name in the parent file _d_o_e_s _n_o_t carry into
         the $INCLUDE 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










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


         a data file, but that's not how it works.  The name
         server  fundamentally  requires a given zone to 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.. (
                                     1995122103   ; 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
         and is often given as ``@'' since  this  is  always
         the  current  $ORIGIN and the SOA RR is usually the
         first record of the primary zone file.   Origin  is
         the  name  of  the  host  on  which  this data file
         resides (in other words, the _p_r_i_m_a_r_y _m_a_s_t_e_r  server
         for  this  zone.)   Person  in charge is the e-mail
         address for the person  responsible  for  the  name
         server,  with ``@'' changed to a ``.''.  The serial
         number is the version number of this data file  and
         must  be  a  positive integer.  This number must 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 mean-
         ing of n.m was ``n000m'' rather than the more intu-
         itive ``n*1000+m'' (such that 1.234  translated  to
         1000234  rather  than  to  1234).  This feature has
         been  deprecated  due  to  its  obscurity,   unpre-
         dictability,  and  lack  of  necessity.   Note that
         using a ``YYYYMMDDNN'' notation you can still  make
         100  changes  per  day  until  the  year 4294.  You
         should choose a notation 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 secondary 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











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


         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 some resource record (RR) in the
         zone.  There must be exactly  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, creating a  _d_e_l_e_g_a_-
         _t_i_o_n  _p_o_i_n_t  and  a  _s_u_b_z_o_n_e.  The first name field
         specifies the zone that is  serviced  by  the  name
         server  specified  by  the second name.  Every zone
         needs at least two name servers.











































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


      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
         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  (using  ``"''
         characters.)   There  could be one _H_I_N_F_O record for
         each host, though for security reasons most domains
         don't  have  any _H_I_N_F_O records at all.  No applica-
         tion 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
         RFC1123 says of _W_K_S records:













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


            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

                  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 existence of a TXT or WKS RR in most
                          domains.


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

         _a_l_i_a_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 must be the only
         one  associated  with  the  alias  name.  All other
         resource records must be associated with the canon-
         ical  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 canonical name, not
         the nickname.  Similarly, a CNAME will be  followed
         when  searching for A RRs, but not for MX RRs or NS
         RRs or most other types of RRs.  CNAMEs are allowed
         to  point  to  other CNAMEs, but this is considered
         sloppy.

              Nicknames are useful when a  well  known  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.















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


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

         _n_a_m_e   _{_t_t_l_}   _a_d_d_r_-_c_l_a_s_s   _P_T_R   _r_e_a_l _n_a_m_e
         7.0            IN           PTR   monet..Berkeley..Edu..

         A _D_o_m_a_i_n _N_a_m_e _P_o_i_n_t_e_r record, _P_T_R,  allows  special
         names  to  point  to  some  other  location  in the
         domain.  The above example of a _P_T_R record is  used
         in  setting  up  reverse  pointers  for the special
         _I_N_-_A_D_D_R.._A_R_P_A domain. This line is from the  example
         _h_o_s_t_s_._r_e_v  file.   _P_T_R  records  are  needed by the
         _g_e_t_h_o_s_t_b_y_a_d_d_r function.  Note  the  trailing  ``..''
         which  prevents  BIND  from  appending  the current
         $ORIGIN to that domain name.

      66..55..1100..  MMXX -- MMaaiill EExxcchhaannggee

         _n_a_m_e             _{_t_t_l_}   _a_d_d_r_-_c_l_a_s_s   _M_X   _p_r_e_f_e_r_e_n_c_e _v_a_l_u_e   _m_a_i_l _e_x_c_h_a_n_g_e
         Munnari..OZ..AU..           IN           MX   0                  Seismo..CSS..GOV..
         *..IL..                    IN           MX   0                  RELAY..CS..NET..

         _M_a_i_l _e_X_c_h_a_n_g_e records, _M_X, are used  to  specify  a
         list  of hosts which are configured to receive mail
         sent  to  this  domain  name.   Every  name   which
         receives mail should have an _M_X since if one is not
         found at the time mail is being  delivered,  an  _M_X
         will be ``imputed'' with a cost of 0 and a destina-
         tion of the host itself.  If you  want  a  host  to
         receive  its  own mail, you should create an _M_X for
         your host's name, pointing at your host's name.  It
         is  better  to have this be explicit than to let it
         be imputed by remote mailers.  In the  first  exam-
         ple,  above, Seismo..CSS..GOV.. is a mail gateway that
         knows how to deliver mail to Munnari..OZ..AU...  These
         two machines may have a private connection or use a
         different transport medium.  The  preference  value
         is the order that a mailer should follow when there
         is more than one way to deliver mail  to  a  single
         machine.   Note  that lower numbers indicate higher
         precedence, and that mailers are supposed  to  ran-
         domize same-valued _M_X hosts so as to distribute the
         load evenly if the costs are equal.  See RFC974 for
         more detailed information.

              Wildcard  names containing the character ``*''
         may be used  for  mail  routing  with  _M_X  records.
         There  are likely to be servers on the network that
         simply state that any mail to a  domain  is  to  be
         routed through a relay.  Second example, above, all
         mail to hosts in the domain IL  is  routed  through
         RELAY.CS.NET.   This is done by creating a wildcard
         resource record, which states that *.IL has  an  _M_X











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


         of  RELAY.CS.NET.  Wildcard _M_X records are not very
         useful in practice, though, since once a mail  mes-
         sage  gets  to  the  gateway  for a given domain it
         still has to be routed _w_i_t_h_i_n that domain and it is
         not  currently  possible to have an apparently-dif-
         ferent set of _M_X records inside and  outside  of  a
         domain.  If you won't be needing any Mail Exchanges
         inside your domain, go ahead and  use  a  wildcard.
         If  you want to use both wildcard ``top-level'' and
         specific ``interior'' _M_X records,  note  that  each
         specific  record  will  have to ``end with'' a com-
         plete recitation of the same data that  is  carried
         in  the top-level record.  This is because the spe-
         cific _M_X records will take precedence over the top-
         level wildcard records, and must be able to perform
         the top-level's if a given interior domain is to be
         able  to  receive  mail  from  outside the gateway.
         Wildcard _M_X records are very subtle and you  should
         be careful with them.

      66..55..1111..  TTXXTT -- TTeexxtt

         _n_a_m_e             _{_t_t_l_}   _a_d_d_r_-_c_l_a_s_s   _T_X_T   _s_t_r_i_n_g
         Munnari..OZ..AU..           IN           TXT   "foo"

         A  _T_X_T record contains free-form textual data.  The
         syntax of the text depends on the domain  where  it
         is  found;  many  systems use _T_X_T records to encode
         local data in a stylized format.  MIT Hesiod is one
         such system.

      66..55..1122..  RRPP -- RReessppoonnssiibbllee PPeerrssoonn

         _o_w_n_e_r      _{_t_t_l_}   _a_d_d_r_-_c_l_a_s_s   _R_P   _m_b_o_x_-_d_o_m_a_i_n_-_n_a_m_e             _T_X_T_-_d_o_m_a_i_n_-_n_a_m_e
         franklin           IN           RP   ben.franklin.berkeley.edu.   sysadmins.berkeley.edu.


              The  Responsible Person record, _R_P, identifies
         the name or group name of  the  responsible  person
         for  a  host.   Often it is desirable to be able to
         identify the responsible entity  for  a  particular
         host.   When  that  host is down or malfunctioning,
         you would want to contact those parties  who  might
         be able to repair the host.

              The first field, _m_b_o_x_-_d_o_m_a_i_n_-_n_a_m_e, is a domain
         name that specifies the mailbox for the responsible
         person.   Its  format  in  a zone file uses the DNS
         convention for mailbox encoding, identical to  that
         used  for the _P_e_r_s_o_n_-_i_n_-_c_h_a_r_g_e mailbox field in the
         SOA record.  In the example above, the _m_b_o_x_-_d_o_m_a_i_n_-
         _n_a_m_e       shows       the       encoding       for











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


         ``<<bbeenn@@ffrraannkklliinn..bbeerrkkeelleeyy..eedduu>>''.  The  root  domain
         name (just ``..'') may be specified to indicate that
         no mailbox is available.

              The second field, _T_X_T_-_d_o_m_a_i_n_-_n_a_m_e, is a domain
         name  for  which  _T_X_T  records exist.  A subsequent
         query can be performed to retrieve  the  associated
         _T_X_T resource records at _T_X_T_-_d_o_m_a_i_n_-_n_a_m_e.  This pro-
         vides a level of indirection so that the entity can
         be  referred  to  from  multiple places in the DNS.
         The root domain name (just ``..'') may be  specified
         for  _T_X_T_-_d_o_m_a_i_n_-_n_a_m_e _t_o _i_n_d_i_c_a_t_e _t_h_a_t _n_o _a_s_s_o_c_i_a_t_e_d
         _T_X_T _R_R _e_x_i_s_t_s_.   _I_n  _t_h_e  _e_x_a_m_p_l_e  _a_b_o_v_e_,  _`_`ssyyssaadd--
         mmiinnss..bbeerrkkeelleeyy..eedduu.._'_'  _i_s  _t_h_e  _n_a_m_e _o_f _a _T_X_T _r_e_c_o_r_d
         _t_h_a_t _m_i_g_h_t _c_o_n_t_a_i_n _s_o_m_e _t_e_x_t _w_i_t_h _n_a_m_e_s  _a_n_d  _p_h_o_n_e
         _n_u_m_b_e_r_s_.

              The  format of the _R_P record is class-insensi-
         tive.  Multiple _R_P records at a single name may  be
         present  in  the  database, though they should have
         identical TTLs.

              The _R_P record is still experimental;  not  all
         name servers implement or recognize it.

      66..55..1133..  AAFFSSDDBB -- DDCCEE oorr AAFFSS SSeerrvveerr

         _n_a_m_e           _{_t_t_l_}   _a_d_d_r_-_c_l_a_s_s   _A_F_S_D_B   _s_u_b_t_y_p_e   _s_e_r_v_e_r _h_o_s_t _n_a_m_e
         toaster.com.           IN           AFSDB   1         jack.toaster.com.
         toaster.com.           IN           AFSDB   1         jill.toaster.com.
         toaster.com.           IN           AFSDB   2         tracker.toaster.com.

         _A_F_S_D_B  records  are  used to specify the hosts that
         provide a style of distributed  service  advertised
         under this domain name.  A subtype value (analogous
         to the ``preference'' value in the _M_X record) indi-
         cates  which  style  of distributed service is pro-
         vided with the given  name.   Subtype  1  indicates
         that  the  named host is an AFS (R) database server
         for the AFS cell of the given domain name.  Subtype
         2 indicates that the named host provides intra-cell
         name service for the DCE  (R)  cell  named  by  the
         given   domain   name.    In   the  example  above,
         jack..toaster..com and jill..toaster..com are  declared
         to  be AFS database servers for the toaster..com AFS
         cell, so that  AFS  clients  wishing  service  from
         toaster..com  are  directed  to  those two hosts for
         further information.   The  third  record  declares
         that  tracker..toaster..com houses a directory server
         for the root of the DCE cell toaster..com,  so  that
         DCE  clients  that  wish  to  refer to DCE services
         should consult with  the  host  tracker..toaster..com











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


         for  further  information.   The  DCE  sub-type  of
         record is usually accompanied by a _T_X_T  record  for
         other  information  specifying  other details to be
         used in accessing the DCE cell.   RFC1183  contains
         more detailed information on the use of this record
         type.

              The _A_F_S_D_B record is  still  experimental;  not
         all name servers implement or recognize it.


      66..55..1144..    PPXX   --   PPooiinntteerr  ttoo  XX..440000//RRFFCC882222  mmaappppiinngg
         iinnffoorrmmaattiioonn

         _n_a_m_e                   _{_t_t_l_}   _a_d_d_r_-_c_l_a_s_s   _P_X   _p_r_e_f_e_r   _8_2_2_-_d_o_m    _X_._4_0_0_-_d_o_m
         *.ADMD-garr.X42D.it.           IN           PX   50       it.        ADMD-garr.C-it.
         *.infn.it.                     IN           PX   50       infn.it.   O.PRMD-infn.ADMD-garr.C-it.
         *.it.                          IN           PX   50       it.        O-gate.PRMD-garr.ADMD-garr.C-it.


              The _P_X records (_P_o_i_n_t_e_r _t_o  _X_._4_0_0_/_R_F_C_8_2_2  _m_a_p_-
         _p_i_n_g  _i_n_f_o_r_m_a_t_i_o_n) are used to specify address map-
         ping rules between X.400 O/R addresses  and  RFC822
         style (domain-style) mail addresses. For a detailed
         description of the mapping process please refer  to
         RFC1327.

              Mapping rules are of 3 different types:

              1)  mapping  from  X.400 to RFC822 (defined as
         "table 1 rules" in RFC1327)

              2) mapping from RFC822 to  X.400  (defined  as
         "table 2 rules" in RFC1327)

              3)  encoding  RFC822  into X.400   (defined as
         "gate table" in RFC1327)

              All three types of mapping rules are specified
         using _P_X Resource Records in DNS, although the _n_a_m_e
         value is different: for case 1, the _n_a_m_e  value  is
         an  X.400 domain in DNS syntax, whereas for cases 2
         and 3 the _n_a_m_e value is an RFC822 domain. Refer  to
         RFC-1664  for details on specifying an X.400 domain
         in DNS syntax and for the use of the  _X_4_2_D  keyword
         in  it. Tools are available to convert from RFC1327
         tables format into DNS files syntax.  _P_r_e_f_e_r_e_n_c_e is
         analogous  to the _M_X RR Preference parameter: it is
         currently advised to use a fixed value  of  50  for
         it.  _8_2_2_-_d_o_m  gives  the RFC822 part of the mapping
         rules, and _X_._4_0_0_-_d_o_m gives the X.400  part  of  the
         mapping  rule  (in  DNS  syntax).  It  is currently











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


         advised always to use wildcarded  _n_a_m_e  values,  as
         the  RFC1327  tables specifications permit wildcard
         specifications only. This is to keep  compatibility
         with  existing services using static RFC1327 tables
         instead of DNS _P_X information.

              Specifications of mapping rules from X.400  to
         RFC822 syntax requires the creation of an appropri-
         ate X.400 domain tree into DNS, including thus spe-
         cific  _S_O_A  and  _N_S  records for the domain itself.
         Specification of mapping  rules  from  RFC822  into
         X.400  can  be  embedded  directly  into the normal
         direct _n_a_m_e tree.   Again,  refer  to  RFC1664  for
         details about organization of this structure.

              Tools and library routines, based on the stan-
         dard resolver ones, are available to retrieve  from
         DNS the appropriate mapping rules in RFC1327 or DNS
         syntax.

              Once again, refer to RFC1664  to  use  the  _P_X
         resource record, and be careful in coordinating the
         mapping information you can specify in DNS with the
         same  information specified into the RFC1327 static
         tables.

              The _P_X record is still experimental;  not  all
         servers implement or recognize it.


   66..66..  DDiissccuussssiioonn aabboouutt tthhee TTTTLL

           The  use of different Time To Live fields with in
      a RRset have been deprecated and this is  enforced  by
      the server when loading a primary zone.  See the Secu-
      rity section for more discussion of differing TTLs.

           The Time To Live assigned to the records  and  to
      the  zone  via  the Minimum field in the SOA record is
      very important. High values will lead  to  lower  BIND
      network traffic and faster response time. Lower values
      will tend to generate lots of requests but will  allow
      faster propagation of changes.

           Only  changes  and  deletions  from  the zone are
      affected by the TTLs.  Additions  propagate  according
      to the Refresh value in the SOA.

           Experience  has shown that sites use default TTLs
      for their zones varying from around 0.5 day to  around
      7  days. You may wish to consider boosting the default
      TTL shown in former versions of this  guide  from  one
      day  (86400  seconds)  to three days (259200 seconds).










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


      This will drastically reduce the  number  of  requests
      made to your name servers.

           If you need fast propagation of changes and dele-
      tions, it might be wise to reduce the Minimum field  a
      few  days  before the change, then do the modification
      itself and augment the TTL to its former value.

           If you know that your zone is pretty stable  (you
      mainly  add  new  records without deleting or changing
      old ones) then you may even wish  to  consider  a  TTL
      higher than three days.

           Note  that in any case, it makes no sense to have
      records with a TTL below the  SOA  Refresh  delay,  as
      Delay  is  the  time required for secondaries to get a
      copy of the newly modified zone.


   66..77..  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, _n_a_m_e_d must be com-
      piled with SECURE_ZONES defined and you must  have  at
      least  one  secure_zone  TXT RR.  Unless a _s_e_c_u_r_e___z_o_n_e
      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 _H_S or _I_N.  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
      specified.

           ``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:










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


      secure_zone     HS     TXT     ``130.215.0.0:255.255.0.0''
      secure_zone     HS     TXT     ``128.23.10.56:H''

           This  feature can be used to restrict access to a
      Hesiod password map or to separate internal and exter-
      nal  internet address resolution on a firewall machine
      without needing to run a separate named  for  internal
      and external address resolution.

           Note  that you will need to include your loopback
      interface (127.0.0.1) in your secure_zone  record,  or
      your local clients won't be able to resolve names.


   66..88..  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//AATTHHEENNAA//hheess--
      iioodd..ttaarr..ZZ.  You will not need the named  and  resolver
      library  portions  of  the  distribution because their
      functionality has already been integrated into BIND as
      of  4.9.  To learn how Hesiod functions as part of the
      Athena  computing   environment   obtain   the   paper
      //ppuubb//AATTHHEENNAA//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.












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


   66..99..  SSaammppllee FFiilleess

           The  following  section contains sample files for
      the name server.  This covers example boot  files  for
      the different types of servers and example domain data
      base files.

      66..99..11..  BBoooott FFiilleess

         66..99..11..11..  PPrriimmaarryy SSeerrvveerr


            ;
            ; Boot file for Primary Name Server
            ;


            ; type      domain                 source file or host
            ;
            directory   /usr/local/adm/named
            primary     Berkeley..Edu           ucbhosts
            primary     32..128..in-addr..arpa    ucbhosts..rev
            primary     0..0..127..in-addr..arpa   named..local
            cache       ..                      root..cache



         66..99..11..22..  SSeeccoonnddaarryy SSeerrvveerr


            ;
            ; Boot file for Secondary Name Server
            ;


            ; type      domain                 source file or host
            ;
            directory   /usr/local/adm/named
            secondary   Berkeley..Edu           128..32..0..4 128..32..0..10 ucbhosts.bak
            secondary   32..128..in-addr..arpa    128..32..0..4 128..32..0..10 ucbhosts.rev.bak
            primary     0..0..127..in-addr..arpa   named..local
            cache       ..                      root..cache





















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


         66..99..11..33..  CCaacchhiinngg OOnnllyy SSeerrvveerr


            ;
            ; Boot file for Caching Only Name Server
            ;


            ; type      domain                 source file or host
            ;
            directory   /usr/local/adm/named
            cache       ..                      root..cache
            primary     0..0..127..in-addr..arpa   named..local





      66..99..22..  RReemmoottee SSeerrvveerr // DDNNSS CClliieenntt

         66..99..22..11..  //eettcc//rreessoollvv..ccoonnff


            domain Berkeley..Edu
            nameserver 128..32..0..4
            nameserver 128..32..0..10
            sortlist 130.155.160.0/255.255.240.0 130.155.0.0




































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


      66..99..33..  rroooott..ccaacchhee


         ;
         ;       This file holds the information on root name servers needed to
         ;       initialize cache of Internet domain name servers
         ;       (e.g. reference this file in the "cache  .  <file>"
         ;       configuration file of BIND domain name servers).
         ;
         ;       This file is made available by InterNIC registration services
         ;       under anonymous FTP as
         ;           file                /domain/named.root
         ;           on server           FTP.RS.INTERNIC.NET
         ;       -OR- under Gopher at    RS.INTERNIC.NET
         ;           under menu          InterNIC Registration Services (NSI)
         ;              submenu          InterNIC Registration Archives
         ;           file                named.root
         ;
         ;       last update:    Oct 5, 1994
         ;       related version of root zone:   1994100500
         ;

         ..                   604800   IN   NS   NS..INTERNIC..NET..
         NS..INTERNIC..NET..    604800   IN   A    198..41..0..4
         ..                   604800   IN   NS   NS1..ISI..EDU..
         NS1..ISI..EDU..        604800   IN   A    128..9..0..107
         ..                   604800   IN   NS   C..PSI..NET..
         C..PSI..NET..          604800   IN   A    192..33..4..12
         ..                   604800   IN   NS   TERP..UMD..EDU..
         TERP..UMD..EDU..       604800   IN   A    128..8..10..90
         ..                   604800   IN   NS   NS..NASA..GOV..
         NS..NASA..GOV..        604800   IN   A    128..102..16..10
                             604800   IN   A    192..52..195..10
         ..                   604800   IN   NS   NS..ISC..ORG..
         NS..ISC..ORG..         604800   IN   A    192..5..5..241
         ..                   604800   IN   NS   NS..NIC..DDN..MIL..
         NS..NIC..DDN..MIL..     604800   IN   A    192..112..36..4
         ..                   604800   IN   NS   AOS..ARL..ARMY..MIL..
         AOS..ARL..ARMY..MIL..   604800   IN   A    128..63..4..82
                             604800   IN   A    192..5..25..82
         ..                   604800   IN   NS   NIC..NORDU..NET..
         NIC..NORDU..NET..      604800   IN   A    192..36..148..17

         ; End of File



















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


      66..99..44..  nnaammeedd..llooccaall



         @   IN   SOA   ucbvax..Berkeley..Edu.   kjd..ucbvax..Berkeley..Edu.. (
                        1994072100             ; Serial
                        10800                  ; Refresh
                        1800                   ; Retry
                        3600000                ; Expire
                        259200 )               ; Minimum
             IN   NS    ucbvax..Berkeley..Edu..   ; pedantic
         1   IN   PTR   localhost..



      66..99..55..  hhoosstt..rreevv


         ;
         ;    @(#)ucb-hosts.rev    1.1    (Berkeley)    86/02/05
         ;

         @       IN   SOA   ucbvax..Berkeley..Edu..   kjd..monet..Berkeley..Edu.. (
                            1986020501             ; Serial
                            10800                  ; Refresh
                            1800                   ; Retry
                            3600000                ; Expire
                            259200 )               ; Minimum
                 IN   NS    ucbarpa..Berkeley..Edu..
                 IN   NS    ucbvax..Berkeley..Edu..
         0..0     IN   PTR   Berkeley-net..Berkeley..EDU..
                 IN   A     255..255..255..0
         0..130   IN   PTR   csdiv-net..Berkeley..EDU..
         4..0     IN   PTR   ucbarpa..Berkeley..Edu..
         6..0     IN   PTR   ernie..Berkeley..Edu..
         7..0     IN   PTR   monet..Berkeley..Edu..
         10..0    IN   PTR   ucbvax..Berkeley..Edu..
         6..130   IN   PTR   monet..Berkeley..Edu..



      66..99..66..  HHoossttss





















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


         ;
         ;    @(#)ucb-hosts    1.2    (berkeley)    88/02/05
         ;

         @           IN   SOA     ucbvax..Berkeley..Edu..               kjd..monet..Berkeley..Edu.. (
                                  1988020501                         ; Serial
                                  10800                              ; Refresh
                                  1800                               ; Retry
                                  3600000                            ; Expire
                                  259200 )                           ; Minimum
                     IN   NS      ucbarpa..Berkeley..Edu..
                     IN   NS      ucbvax..Berkeley..Edu..
         localhost   IN   A       127..1
                                  ; note that 127.1 is the same as 127.0.0.1; see inet(3n)
         ucbarpa     IN   A       128..32..4
                     IN   A       10..0..0..78
                     IN   HINFO   VAX-11/780 UNIX
         arpa        IN   CNAME   ucbarpa
         ernie       IN   A       128..32..6
                     IN   HINFO   VAX-11/780 UNIX
         ucbernie    IN   CNAME   ernie
         monet       IN   A       128..32..7
                     IN   A       128..32..130..6
                     IN   HINFO   VAX-11/750 UNIX
         ucbmonet    IN   CNAME   monet
         ucbvax      IN   A       10..2..0..78
                                  ; 128.32.10 means 128.32.0.10; see inet(3n)
                     IN   A       128..32..10
                                  ; HINFO and WKS are widely unused,
                                  ; but we'll show them as examples.
                     IN   HINFO   VAX-11/750 UNIX
                     IN   WKS     128.32.0.10 TCP ( echo telnet
                                  discard sunrpc sftp
                                  uucp-path systat daytime
                                  netstat qotd nntp
                                  link chargen ftp
                                  auth time whhois mtp
                                  pop rje finger smtp
                                  supdup hostnames
                                  domain
                                  nameserver )
         vax         IN   CNAME   ucbvax
         toybox      IN   A       128..32..131..119
                     IN   HINFO   Pro350 RT11
         toybox      IN   MX      0  monet.Berkeley.Edu.
         csrg        IN   MX      0 Ralph.CS
                     IN   MX      0 Zhou.CS
                     IN   MX      0 Painter.CS
                     IN   MX      0 Riggle.CS
                     IN   MX      0 Terry.CS
                     IN   MX      0 Kevin.CS












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


77..  SSeettttiinngg uupp YYoouurr OOwwnn DDoommaaiinn

        When setting up a domain that is going to  be  on  a
   public  network the site administrator should contact the
   organization in charge of the  network  and  request  the
   appropriate  domain  registration  form.  An organization
   that belongs to multiple networks (such as  the  _I_n_t_e_r_n_e_t
   and _B_I_T_N_E_T) should register with only one network.

   77..11..  IInntteerrnneett

           Sites  on  the  Internet  who need information on
      setting up a domain should contact the  registrar  for
      their network, which is one of the following:

      MILnet   HOSTMASTER@NIC..DDN..MIL
      other    HOSTMASTER@INTERNIC..NET

      You  may  also  want  to be placed on the BIND mailing
      list, which is a mail group for people on the Internet
      who run BIND.  The group discusses future design deci-
      sions, operational problems, and other related  topic.
      The  address  to  request being placed on this mailing
      list is:

          _b_i_n_d_-_r_e_q_u_e_s_t_@_u_u_n_e_t.._u_u.._n_e_t


   77..22..  SSuubbddoommaaiinnss ooff EExxiissttiinngg DDoommaaiinnss

           If you want a subdomain of some existing  domain,
      you  should  find  the  contact  point  for the parent
      domain rather than asking one of the  above  top-level
      registrars.   There should be a convention that rreeggiiss--
      ttrraarr@_d_o_m_a_i_n or hhoossttmmaasstteerr@_d_o_m_a_i_n for any given  domain
      will  always  be  an alias for that domain's registrar
      (somewhat analogous to ppoossttmmaasstteerr), but  there  is  no
      such  convention.   Try it as a last resort, but first
      you should examine the _S_O_A record for the  domain  and
      send mail to the ``responsible person'' shown therein.
      You can also try _w_h_o_i_s.


88..  DDoommaaiinn MMaannaaggeemmeenntt

        This section contains information for starting, con-
   trolling and debugging _n_a_m_e_d.

   88..11..  //eettcc//rrcc..llooccaall

           The  hostname  should  be  set to the full domain
      style name in _/_e_t_c_/_r_c_._l_o_c_a_l  using  _h_o_s_t_n_a_m_e_(_1_).   The











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


      following  entry  should  be added to _/_e_t_c_/_r_c_._l_o_c_a_l to
      start up _n_a_m_e_d at system boot time:

          _i_f _[ _-_f _/_u_s_r_/_s_b_i_n_/_n_a_m_e_d _]_; _t_h_e_n
              _/_u_s_r_/_s_b_i_n_/_n_a_m_e_d [options] _& _e_c_h_o _-_n _' _n_a_m_e_d_'  _>_/_d_e_v_/_c_o_n_s_o_l_e
          _f_i

      This usually directly follows  the  lines  that  start
      _s_y_s_l_o_g_d.   DDoo  NNoott  attempt  to  run _n_a_m_e_d from _i_n_e_t_d.
      This will continuously restart  the  name  server  and
      defeat the purpose of the cache.

   88..22..  //vvaarr//rruunn//nnaammeedd..ppiidd

           When  _n_a_m_e_d  is successfully started up it writes
      its process id into the file _/_v_a_r_/_r_u_n_/_n_a_m_e_d_._p_i_d.  This
      is  useful  to  programs  that want to send signals to
      _n_a_m_e_d. The name of this file may be changed by  defin-
      ing _P_I_D_F_I_L_E to the new name when compiling _n_a_m_e_d.

   88..33..  //eettcc//hhoossttss

           The  _g_e_t_h_o_s_t_b_y_n_a_m_e_(_)  library  call can detect if
      _n_a_m_e_d is running.  If it is determined that  _n_a_m_e_d  is
      not  running  it will look in _/_e_t_c_/_h_o_s_t_s to resolve an
      address.  This option was added to allow  _i_f_c_o_n_f_i_g_(_8_C_)
      to  configure  the  machines  local  interfaces and to
      enable a system manager to access  the  network  while
      the system is in single user mode.  It is advisable to
      put the local machines interface addresses and a  cou-
      ple  of machine names and address in _/_e_t_c_/_h_o_s_t_s so the
      system manager can rcp files from another machine when
      the  system  is  in  single  user mode.  The format of
      _/_e_t_c_/_h_o_s_t_s has not  changed.  See  _h_o_s_t_s_(_5_)  for  more
      information.   Since the process of reading _/_e_t_c_/_h_o_s_t_s
      is slow, it is not advisable to use this  option  when
      the system is in multi user mode.


   88..44..  SSiiggnnaallss

           There are several signals that can be sent to the
      _n_a_m_e_d process to have it do tasks  without  restarting
      the process.

      88..44..11..  RReellooaadd

              SIGHUP  -  Causes _n_a_m_e_d to read _n_a_m_e_d_._b_o_o_t and
         reload the database.  This is useful when you  have
         made  a  change  to a ``primary'' data file and you
         want  _n_a_m_e_d's  internal  database  to  reflect  the
         change.   If  you build BIND with the FORCED_RELOAD
         option,  then  SIGHUP  also  has  the   effect   of










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


         scheduling  all ``secondary'' zones for serial-num-
         ber checks, which  could  lead  to  zone  transfers
         ahead  of the usual schedule.  Normally serial-num-
         ber compares are done only at the intervals  speci-
         fied in the zone's SOA record.

      88..44..22..  DDeebbuuggggiinngg

              When  _n_a_m_e_d is running incorrectly, look first
         in _/_v_a_r_/_l_o_g_/_m_e_s_s_a_g_e_s and  check  for  any  messages
         logged  by  _s_y_s_l_o_g.   Next  send it a signal to see
         what is happening.  Unless  you  run  it  with  the
         ``-d''  option, _n_a_m_e_d has very little to say on its
         standard  output  or  standard  error.   Everything
         _n_a_m_e_d has to say, it says to _s_y_s_l_o_g.

              SIGINT - Dumps the current data base and cache
         to _/_v_a_r_/_t_m_p_/_n_a_m_e_d___d_u_m_p_._d_b This should give  you  an
         indication to whether the data base was loaded cor-
         rectly.  The name of the dump file may  be  changed
         by defining _D_U_M_P_F_I_L_E to the new name when compiling
         _n_a_m_e_d.

         _N_o_t_e_: the following  two  signals  only  work  when
         _n_a_m_e_d is built with _D_E_B_U_G defined.

              SIGUSR1  -  Turns on debugging. Each following
         SIGUSR1 increments the  debug  level.   The  output
         goes  to  _/_v_a_r_/_t_m_p_/_n_a_m_e_d_._r_u_n The name of this debug
         file may be changed by defining  _D_E_B_U_G_F_I_L_E  to  the
         new name before compiling _n_a_m_e_d.

              SIGUSR2 - Turns off debugging completely.

         For more detailed debugging, define DEBUG when com-
         piling the resolver routines into _/_l_i_b_/_l_i_b_c_._a.

              SIGWINCH - Toggles  tracing  of  all  incoming
         queries  if  _n_a_m_e_d  has  been  compiled with _Q_R_Y_L_O_G
         defined.  The trace is sent to syslog, and is huge,
         but it is very useful for tracking down problems.

         To  run  with tracing of all queries specify the _-_q
         flag on the command line.   If  you  routinely  log
         queries  you  will  probably  want  to  analyze the
         results using the dnsstats stats script in the con-
         trib directory.

              SIGIOT    -   Dumps   statistics   data   into
         _/_v_a_r_/_t_m_p_/_n_a_m_e_d_._s_t_a_t_s if the server  is  built  with
         _S_T_A_T_S  defined.   Statistics  are  appended  to the
         file.











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


99..  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.

   99..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
      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
____________________
   |=VAX is a Trademark of Digital Equipment Corporation












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


      compile/link  path  so  that your own network applica-
      tions will be able to use the newer features.





























































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


                 AACCKKNNOOWWLLEEDDGGEEMMEENNTTSS ---- 44..99..33

     The _<_b_i_n_d_-_w_o_r_k_e_r_s_@_v_i_x_._c_o_m_> mailing list was once  again
of great help; this release would not be nearly as ready for
prime time if not for their efforts.  Special  commendations
are  owed to Robert Elz, Don "Truck" Lewis, Bob Halley, Mark
Andrews, Berthold Paffrath, Ruediger Volk, and Peter Koch.

     Digital Equipment Corporation, Hewlett Packard, Silicon
Graphics,  and SunSoft all made hardware available for inte-
gration testing; this made the release far more  solid  than
it  would otherwise have been.  More hardware loans are wel-
come -- if you are a system vendor and you would  like  BIND
to  run  ``out of the box'' on your platform and are willing
to lend some rusty old hardware for the purpose, please con-
tact me (_<_p_a_u_l_@_v_i_x_._o_r_g_>) to make the arrangements.

     Special  thanks to the Internet Software Consortium for
funding this work.  Contact _<_i_s_c_-_i_n_f_o_@_i_s_c_._o_r_g_> if your orga-
nization   would  like  to  participate  in  funding  future
releases of BIND and other freely  redistributable  software
packages that are in wide use on the Internet.


              AACCKKNNOOWWLLEEDDGGEEMMEENNTTSS ---- tthhrroouugghh 44..99

     The  alpha-test group was extremely helpful in furnish-
ing improvements, finding  and  repairing  bugs,  and  being
patient.   I  would  like to express special thanks to Brian
Reid of Digital Equipment corporation for funding this work.
Robert Elz, Alan Barrett, Paul Albitz, Bryan Beecher, Andrew
Partan, Andy Cherenson, Tom Limoncelli,  Berthold  Paffrath,
Fuat  Baran, Anant Kumar, Art Harkin, Win Treese, Don Lewis,
Christophe Wolfhugel, and a cast of dozens  all  helped  out
above  and  beyond the call of duty.  Special thanks to Phil
Almquist, who got the project started and contributed a  lot
of the code and fixed several of the worst bugs.


             AACCKKNNOOWWLLEEDDGGEEMMEENNTTSS ---- tthhrroouugghh 44..88..33

     Many  thanks to the users at U. C. Berkeley for falling
into many of the holes involved with integrating  BIND  into
the  system  so  that  others would be spared the trauma.  I
would also like to extend gratitude  to  Jim  McGinness  and
Digital  Equipment  Corporation  for  permitting me to spend
most of my time on this project.

     Ralph Campbell, Doug Kingston, Craig  Partridge,  Smoot
Carl-Mitchell,  Mike  Muuss  and  everyone else on the DARPA
Internet who has contributed to the development of BIND.  To
the  members  of  the  original BIND project, Douglas Terry,
Mark Painter, David Riggle and Songnian Zhou.










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


     Anne Hughes, Jim Bloom and Kirk McKusick and  the  many
others  who  have  reviewed  this  paper giving considerable
advice.

     This  work  was  sponsored  by  the  Defense   Advanced
Research  Projects  Agency  (DoD), Arpa Order No. 4871 moni-
tored by the Naval Electronics Systems  Command  under  con-
tract  No. N00039-84-C-0089.  The views and conclusions con-
tained in this document are those of the authors and  should
not be interpreted as representing official policies, either
expressed or  implied,  of  the  Defense  Research  Projects
Agency, of the US Government, or of Digital Equipment Corpo-
ration.


















































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


                         RREEFFEERREENNCCEESS


[Birrell] Birrell, A. D., Levin, R.,  Needham,  R.  M.,  and
          Schroeder,  M.D.,  "Grapevine: An Exercise in Dis-
          tributed  Computing."    In   _C_o_m_m_.   _A_._C_._M_.   _2_5_,
          4:260-274 April 1982.

[RFC819]  Su,  Z.  Postel, J., "The Domain Naming Convention
          for Internet User Applications."  _I_n_t_e_r_n_e_t _R_e_q_u_e_s_t
          _F_o_r  _C_o_m_m_e_n_t  _8_1_9  Network Information Center, SRI
          International,  Menlo  Park,  California.   August
          1982.

[RFC974]  Partridge,  C.,  "Mail Routing and The Domain Sys-
          tem."  _I_n_t_e_r_n_e_t _R_e_q_u_e_s_t _F_o_r  _C_o_m_m_e_n_t  _9_7_4  Network
          Information Center, SRI International, Menlo Park,
          California.  February 1986.

[RFC1032] Stahl, M., "Domain Administrators Guide"  _I_n_t_e_r_n_e_t
          _R_e_q_u_e_s_t  _F_o_r _C_o_m_m_e_n_t _1_0_3_2 Network Information Cen-
          ter, SRI International,  Menlo  Park,  California.
          November 1987.

[RFC1033] Lottor, M., "Domain Administrators Guide" _I_n_t_e_r_n_e_t
          _R_e_q_u_e_s_t _F_o_r _C_o_m_m_e_n_t _1_0_3_3 Network Information  Cen-
          ter,  SRI  International,  Menlo Park, California.
          November 1987.

[RFC1034] Mockapetris,  P.,  "Domain  Names  -  Concept  and
          Facilities."   _I_n_t_e_r_n_e_t  _R_e_q_u_e_s_t  _F_o_r _C_o_m_m_e_n_t _1_0_3_4
          Network  Information  Center,  SRI  International,
          Menlo Park, California.  November 1987.

[RFC1035] Mockapetris,  P.,  "Domain  Names - Implementation
          and Specification."  _I_n_t_e_r_n_e_t _R_e_q_u_e_s_t _F_o_r  _C_o_m_m_e_n_t
          _1_0_3_5  Network  Information  Center,  SRI  Interna-
          tional, Menlo Park, California.  November 1987.

[RFC1101] Mockapetris, P., "DNS Encoding  of  Network  Names
          and  Other  Types."   _I_n_t_e_r_n_e_t _R_e_q_u_e_s_t _F_o_r _C_o_m_m_e_n_t
          _1_1_0_1  Network  Information  Center,  SRI  Interna-
          tional, Menlo Park, California.  April 1989.

[RFC1123] R.  Braden,  Editor,  "Requirements  for  Internet
          Hosts -- Application and Support" _I_n_t_e_r_n_e_t _R_e_q_u_e_s_t
          _F_o_r  _C_o_m_m_e_n_t  _1_1_2_3 Network Information Center, SRI
          International, Menlo  Park,  California.   October
          1989.

[RFC1183] Everhart,  C., Mamakos, L., Ullmann, R., and Mock-
          apetris, P., "New  DNS  RR  Definitions"  _I_n_t_e_r_n_e_t
          _R_e_q_u_e_s_t   _F_o_r  _C_o_m_m_e_n_t  _1_1_8_3  Network  Information










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


          Center, SRI International, Menlo Park, California.
          October 1990.

[RFC1327] Hardcastle-Kille, S., "Mapping between X.400(1988)
          / ISO 10021 and RFC 822" _I_n_t_e_r_n_e_t _R_e_q_u_e_s_t _F_o_r _C_o_m_-
          _m_e_n_t _1_3_2_7 Network Information Center, SRI Interna-
          tional, Menlo Park, California.  May 1992.

[RFC1664] Allocchio, C., Bonito, A., Cole, B., Giordano, S.,
          Hagens,  R., "Using the Internet DNS to Distribute
          RFC1327  Mail  Address  Mapping  Tables"  _I_n_t_e_r_n_e_t
          _R_e_q_u_e_s_t  _F_o_r _C_o_m_m_e_n_t _1_6_6_4 Network Information Cen-
          ter, SRI International,  Menlo  Park,  California.
          August 1994.

[RFC1713] Romao,  A.,  "Tools  for  DNS  debugging" _I_n_t_e_r_n_e_t
          _R_e_q_u_e_s_t  _F_o_r  _C_o_m_m_e_n_t  _1_7_1_3_,  _a_l_s_o  _F_Y_I_2_7  Network
          Information Center, SRI International, Menlo Park,
          California.  November 1994.

[Terry]   Terry, D. B., Painter,  M.,  Riggle,  D.  W.,  and
          Zhou,   S.,  _T_h_e  _B_e_r_k_e_l_e_y  _I_n_t_e_r_n_e_t  _N_a_m_e  _D_o_m_a_i_n
          _S_e_r_v_e_r_.   Proceedings  USENIX  Summer  Conference,
          Salt Lake City, Utah.  June 1984, pages 23-31.

[Zhou]    Zhou,  S.,  _T_h_e  _D_e_s_i_g_n  _a_n_d _I_m_p_l_e_m_e_n_t_a_t_i_o_n _o_f _t_h_e
          _B_e_r_k_e_l_e_y  _I_n_t_e_r_n_e_t  _N_a_m_e  _D_o_m_a_i_n  _(_B_I_N_D_)  _S_e_r_v_e_r_s_.
          UCB/CSD  84/177.  University of California, Berke-
          ley, Computer Science Division.  May 1984.

[Mockapetris]
          Mockapetris, P., Dunlap,  K,  _D_e_v_e_l_o_p_m_e_n_t  _o_f  _t_h_e
          _D_o_m_a_i_n  _N_a_m_e  _S_y_s_t_e_m  ACM  Computer Communications
          Review 18, 4:123-133.  Proceedings ACM SIGCOMM '88
          Symposium, August 1988.

[Liu]     Liu, C., Albitz, P., _D_N_S _a_n_d _B_I_N_D O'Reilly & Asso-
          ciates,   Sebastopol,   CA,   502   pages,    ISBN
          0-937175-82-X 1992




















