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

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










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


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


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

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

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










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


      simply a DNS Client.  This kind of host is technically
      not a ``server'', since it has no cache and  does  not
      answer queries.

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


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

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










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


      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.

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

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

      55..11..33..  PPrriimmaarryy SSeerrvviiccee

              The line in the boot file that designates  the
         server  as a primary master server for a zone looks










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


         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

         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.

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










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


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

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


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











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


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

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


      55..11..88..  SSllaavvee SSeerrvveerrss

              Slave mode is used if the use of forwarders is
         the only possible way to  resolve  queries  due  to










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


         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

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


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











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


              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.


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


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


      55..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:










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


             _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  pro-
         cesses  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.


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











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


              This  directive  has  the  same syntax as _f_o_r_-
         _w_a_r_d_e_r_s except that you can list network numbers in
         addition to host addresses.  For example, you could
         add the directive

             _x_f_r_n_e_t_s _1_6_._0_._0_._0

         if you wanted to permit only hosts on Class A  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.


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












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


              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 num-
         ber 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.


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










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


         sparingly or not at all.


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


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










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


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












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


           The _s_o_r_t_-_l_i_s_t is a list of  IP  address,  netmask
      pairs.  Addresses returned by gethostbyname are sorted
      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''.


   55..33..  CCaacchhee IInniittiiaalliizzaattiioonn FFiillee

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


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

      55..44..11..  hhoossttss

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










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


         is specified in the boot file.

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

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

   55..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:














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


      _{_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
      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.)












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


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

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

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

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












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


      55..55..22..  $$OORRIIGGIINN

              The  origin is a way of changing the origin in
         a data file.  The line starts in column 1,  and  is
         followed  by  a  domain origin.  This seems like it
         could be useful for putting more then one zone into
         a data file, but that's not how it works.  The name
         server fundamentally requires 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.

      55..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,











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


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

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





































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


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

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


      55..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:













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


            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.


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















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


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

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











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


         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.

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

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











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


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

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











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


         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.


      55..55..1144..  PPXX -- PPooiinntteerr ttoo XX..440000//RRFFCC882222 mmaappppiinngg iinnffoorrmmaa--
         ttiioonn

         _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











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


         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.


   55..66..  DDiissccuussssiioonn aabboouutt tthhee TTTTLL

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










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


      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.


   55..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:

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












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


           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.


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















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


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

      55..99..11..  BBoooott FFiilleess

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



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





















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


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





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

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




































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


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



















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


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



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



      55..99..66..  HHoossttss





















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


         ;
         ;    @(#)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












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


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

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


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


77..  DDoommaaiinn MMaannaaggeemmeenntt

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

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











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


      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.

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

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


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

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










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


         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.

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











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


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

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












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


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





























































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


                 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.










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


     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.


















































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


                         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










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


          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