










                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>

                     Vixie Enterprises
                      Redwood City, 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 the BSD operating system.
   The BIND consists of  a  server  (or  ``daemon'')  and  a
   _r_e_s_o_l_v_e_r  library.   A  name  server is a network service
   that enables clients to name  resources  or  objects  and
   share this information with other objects in the network.
   This in effect is a  distributed  data  base  system  for
   objects  in a computer network.  BIND is fully integrated
   into BSD (4.3 and later releases)  network  programs  for
____________________
   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


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


22..  BBuuiillddiinngg AA SSyysstteemm wwiitthh aa NNaammee SSeerrvveerr

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

   22..11..  RReessoollvveerr RRoouuttiinneess iinn lliibbcc

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

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

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

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

           If your operating system isn't VAX|= 4.3BSD, it is
      probably  the  case  that  your  vendor  has  included
____________________
   |=VAX is a Trademark of Digital Equipment Corporation












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


      _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
      compile/link path so that your  own  network  applica-
      tions will be able to use the newer features.


   22..22..  TThhee NNaammee SSeerrvviiccee

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

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

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

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











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


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


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

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

           To  learn  about and obtain Hesiod make an anony-
      mous FTP connection to  host  ATHENA-DIST.MIT.EDU  and
      retrieve       the       compressed      tar      file
      ppuubb//AATTHHEENNAA//hheessiioodd..ttaarr..ZZ.  You will not need the  named
      and  resolver  library  portions  of  the distribution
      because their functionality  has  already  been  inte-
      grated into BIND as of 4.9.  To learn how Hesiod func-
      tions 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.


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

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











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


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

           This feature can be used to restrict access to  a
      Hesiod password map or to seperate internal and exter-
      nal internet address resolution on a firewall  machine
      without  needing  to run a seperate 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.


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












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


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

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

        Each  zone  will  have one ``primary'' server, which
   loads the zone contents from some  local  file  which  is
   edited  by  humans or perhaps generated mechanically from
   some other local file which is edited  by  humans.   Then
   there will be some number of ``secondary'' servers, which
   load the zone contents using the  IP/DNS  protocol  (that
   is,  the  secondary  servers will contact the primary and
   fetch the zone using IP/TCP).  This set of  servers  (the
   primary  and  all of the secondaries) should be listed in
   the _N_S records in the parent zone, which will  constitute
   a  ``delegation''.   This  set  of  servers  must also be
   listed in the zone file itself, usually under  the  ``@''
   name which is a magic cookie that means the ``top level''
   or ``root'' of current $ORIGIN.  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 ``@''.  (This latter condition is one form of what
   is called a ``lame delegation''.)


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










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


   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 domain.
      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.  This kind
      of host is technically not a ``server'', since it  has
      no  cache  and  does not answer queries.  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  but  more
      often it is called simply a DNS Client.

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










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


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

        The contacts are as follows:

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


   55..22..  BBIITTNNEETT

           If you are on the BITNET and need  to  set  up  a
      domain, contact INFO@BITNIC.













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


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


66..  FFiilleess

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

   66..11..  BBoooott FFiillee

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

      66..11..11..  DDoommaaiinn

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

             _d_o_m_a_i_n           _B_e_r_k_e_l_e_y.._E_d_u

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










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


         file is strongly discouraged.

      66..11..22..  DDiirreeccttoorryy

              The _d_i_r_e_c_t_o_r_y directive specifies  the  direc-
         tory  in which the name server should run, allowing
         the other file names in the boot file to use  rela-
         tive  path  names.  There can be only one _d_i_r_e_c_t_o_r_y
         directive and it should be given before  any  other
         directives that specify file names.

             _d_i_r_e_c_t_o_r_y        _/_v_a_r_/_n_a_m_e_d

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

      66..11..33..  PPrriimmaarryy SSeerrvviiccee

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

             _p_r_i_m_a_r_y          _B_e_r_k_e_l_e_y.._E_d_u   _u_c_b_h_o_s_t_s

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

              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.













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


      66..11..44..  SSeeccoonnddaarryy SSeerrvviiccee

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

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

         The first field specifies that the server is a sec-
         ondary  server  for  the  zone stated in the second
         field.  The two network addresses specify the  name
         servers which have data for the zone.  Note that at
         least one of these will be a _p_r_i_m_a_r_y,  and,  unless
         you  are  using some protocol other than IP/DNS for
         your zone transfer mechanism, the others  will  all
         be  other _s_e_c_o_n_d_a_r_y servers.  Having your secondary
         server pull data from other  secondary  servers  is
         usually  unwise,  since  you  can  add delay to the
         propagation of zone updates if your network's  con-
         nectivity  varies  in pathological but common ways.
         The intended use for multiple addresses on  a  _s_e_c_-
         _o_n_d_a_r_y  declaration  is when the _p_r_i_m_a_r_y server has
         multiple network interfaces and therefore  multiple
         host addresses.  The secondary server gets its data
         across the network from one of the listed  servers.
         The server addresses are tried in the order listed.
         If a filename is present after the list of  primary
         servers, data for the zone will be dumped into that
         file  as  a  backup.   When  the  server  is  first
         started, the data is loaded from the backup file if
         possible, and a primary server is then consulted to
         check that the zone is still up-to-date.  Note that
         listing your server as a _s_e_c_o_n_d_a_r_y server does  not
         necessarily  make  it  one  -- the parent zone must
         _d_e_l_e_g_a_t_e authority to your server as  well  as  the
         primary  and  the other secondaries, or you will be
         transferring a zone over for no  reason;  no  other
         server  will  have  a  reason to query you for that
         zone unless the parent zone lists you as  a  server
         for the zone.

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

      66..11..55..  SSttuubb SSeerrvviiccee

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











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


             _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 intened to ensure that a pri-
         mary for a zone always has the correct  _N_S  records
         for  children of that zone. If the primary is not a
         secondary for a child zone it should be  configured
         with  stub  zones  for all its children. Stub zones
         provide a mechanism to allow _N_S records for a  zone
         to be specified in only one place.

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


      66..11..66..  CCaacchhiinngg SSeerrvveerr

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

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

             _c_a_c_h_e                        ..             _r_o_o_t.._c_a_c_h_e

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

              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.

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

      66..11..77..  FFoorrwwaarrddeerrss

              Any server can make use of _f_o_r_w_a_r_d_e_r_s.  A _f_o_r_-
         _w_a_r_d_e_r  is  another  server  capable  of processing










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


         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 his server and therefore  it  builds  up  a
         very  rich cache of data compared to the cache in a
         typical workstation name server.   In  effect,  the
         _f_o_r_w_a_r_d_e_r  becomes  a meta-cache that all hosts can
         benefit from, thereby reducing the total number  of
         queries from that site to the rest of the net.

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


      66..11..88..  SSllaavvee SSeerrvveerrss

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

             _s_l_a_v_e

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

              So  while _f_o_r_w_a_r_d_e_r_s prepends addresses to the
         ``server list'' for each query,  _s_l_a_v_e  causes  the
         ``server  list''  to  contain  _o_n_l_y those addresses










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


         listed in the  _f_o_r_w_a_r_d_e_r_s  declarations.   Careless
         use  of the _s_l_a_v_e directive can cause really horri-
         ble forwarding loops, since you could end  up  for-
         warding queries only to some set of hosts which are
         also slaves, and one or several of  them  could  be
         forwarding queries back to you.

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


      66..11..99..  ZZoonnee TTrraannssffeerr RReessttrriiccttiioonnss

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

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

             _x_f_r_n_e_t_s _1_6_._0_._0_._0

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










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


         BIND 4.9.


      66..11..1100..  SSoorrttiinngg AAddddrreesssseess

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

              If  you are on a Class C net which has a Class
         B net between you and the rest of the Internet, you
         could try to improve the name server's luck in get-
         ting answers by listing the Class B network's  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, noone uses this directive
         since  it  hardwires  information   which   changes
         rapidly;  a network which is ``close'' today may be
         ``distant'' next month.  Since  BIND  builds  up  a
         cache  of  the remote name servers' response times,
         it  will   quickly   converge   on   ``reasonable''
         behaviour,  which isn't the same as ``optimal'' but










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


         it's close  enough.   Future  directions  for  BIND
         include choosing addresses based on local interface
         metrics (on hosts that have more than one) and per-
         haps  on  routing  table  information.   We  do not
         intend to solve the generalized ``multihomed host''
         problem,  but we should be able to do a little bet-
         ter than we're doing now.  Likewise, we hope to see
         a   higher   level   resolver  library  that  sorts
         responses  using  topology  information  that  only
         exists on the client's host.


      66..11..1111..  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.   _B_o_g_u_s_n_s  addresses,  unless  qualified
         with   explicit  masks,  are  assumed  to  be  host
         addresses.


      66..11..1122..  SSeeggmmeenntteedd BBoooott FFiilleess

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

      66..11..1133..  NNuummbbeerr ooff CCoonnccuurrrreenntt SSuubbpprroocceesssseess

              BIND spawns up to 10 subprocesses at a time to
         fetch  zones which it provides secondary zones for.
         The _m_a_x_-_f_e_t_c_h directive can be used to override the










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


         default number as follows:

             _m_a_x_-_f_e_t_c_h                    _5


   66..22..  RReessoollvveerr CCoonnffiigguurraattiioonn

           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 you can list the local host's
      address  if  the  local  host  runs a name server, and
      there is no other recommended way to specify a system-
      level  default  domain.  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 con-
      nected SOCK_DGRAM sockets in some versions 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 vin-
      tage of your BSD-derived networking code, both of them
      are capable of failing in their own ways.

           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.
      It is considered reasonable to create this  file  even
      if  you run a local server, since its contents will be
      cached by each client of the resolver library when the
      client makes its first call to a resolver routine.  If
      you run  a  name  server  locally,  list  it  in  your
      _r_e_s_o_l_v_._c_o_n_f file.

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

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

      Exactly one of the _d_o_m_a_i_n or _s_e_a_r_c_h directives  should
      be  given,  exactly  once.  If the _s_e_a_r_c_h directive is
      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  ``;;''










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


      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.   This is, in other words, 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.

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

           Finally,  if the environment variable HOSTALIASES
      is set, it is taken to contain  the  name  of  a  file










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


      which  in turn contains resolver-level aliases.  These
      aliases are applied only to names which do not contain
      any  ``..''  characters, and they are applied to query-
      names before the query is generated.   Note  that  the
      resolver  options  governing  the  operation of _l_o_c_a_l_-
      _d_o_m_a_i_n and _s_e_a_r_c_h_-_l_i_s_t do not apply to HOSTALIASES.


   66..33..  CCaacchhee IInniittiiaalliizzaattiioonn

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

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


      66..33..22..  nnaammeedd..llooccaall

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


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










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


      covered later in this paper.  Note that the file names
      are arbitrary; many network administrators  prefer  to
      name  their zone files after the domains they contain,
      especially in the average case which is where a  given
      server  is primary and/or secondary for many different
      zones.

      66..44..11..  hhoossttss

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

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

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

   66..55..  SSttaannddaarrdd RReessoouurrccee RReeccoorrdd FFoorrmmaatt

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

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

      Resource  records  have a standard format shown above.
      The first field is  always  the  name  of  the  domain
      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''











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


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

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

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

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

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

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

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

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

           Anywhere a name appears --  either  in  the  name
      field  or  in some data field defined to contain names










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


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

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

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

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

         The  line would be interpreted as a request to load
         the   file   _/_u_s_r_/_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 simply a way
         to  allow data for a given primary zone to be orga-
         nized in separate files.  Not even the  ``temporary
         $ORIGIN''  feature described above is sufficient to
         cause your data to branch out into some other  zone
         --  zone  boundaries  can only be introduced in the
         boot file.

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

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

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














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


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


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


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

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

         _{_n_a_m_e_}   _{_t_t_l_}   _a_d_d_r_-_c_l_a_s_s   _N_S   _N_a_m_e _s_e_r_v_e_r_s _n_a_m_e













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


                          IN           NS   ucbarpa..Berkeley..Edu..

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























































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


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

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

         The _A_d_d_r_e_s_s record, _A,  lists  the  address  for  a
         given  machine.  The name field is the machine name
         and the address  is  the  network  address.   There
         should  be  one  _A  record  for each address of the
         machine.

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

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

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


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

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

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


            2.2  Using Domain Name Service











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


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


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

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

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

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

      66..55..99..  PPTTRR -- DDoommaaiinn NNaammee 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











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


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

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

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

         _M_a_i_l _e_X_c_h_a_n_g_e records, _M_X, are used  to  specify  a
         list  of hosts which are configured to receive mail
         sent  to  this  domain  name.   Every  name   which
         receives mail should have an _M_X since if one is not
         found at the time mail is being  delivered,  an  _M_X
         will be ``imputed'' with a cost of 0 and a destina-
         tion of the host itself.  If you  want  a  host  to
         receive  its  own mail, you should create an _M_X for
         your host's name, pointing at your host's name.  It
         is  better  to have this be explicit than to let it
         be imputed by remote mailers.  In the  first  exam-
         ple,  above, Seismo..CSS..GOV.. is a mail gateway that
         knows how to deliver mail to Munnari..OZ..AU...  These
         two machines may have a private connection or use a
         different transport medium.  The  preference  value
         is the order that a mailer should follow when there
         is more then 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  RFC  974
         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
         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-
         different 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











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


         specific ``interior'' _M_X records,  note  that  each
         specific  record  will  have to ``end with'' a com-
         plete recitation of the same data that  is  carried
         in  the top-level record.  This is because the spe-
         cific _M_X records will take precedence over the top-
         level wildcard records, and must be able to perform
         the top-level's if a given interior domain is to be
         able  to  receive  mail  from  outside the gateway.
         Wildcard _M_X records are very subtle and you  should
         be careful with them.

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

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

         A  _T_X_T record contains free-form textual data.  The
         syntax of the text depends on the domain  where  it
         is  found;  many  systems use _T_X_T records to encode
         local data in a stylized format.  MIT Hesiod is one
         such  system.  The quotes (") around the data field
         are optional but highly recommended.

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

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


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

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











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


         provides  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 TXT domain name to indicate that no  associated
         _T_X_T  RR  exists.   In  the  example above, ``ssyyssaadd--
         mmiinnss..bbeerrkkeelleeyy..eedduu..'' is the name of  a  TXT  record
         that  might  contain some text with names and phone
         numbers.

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

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

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

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

         _A_F_S_D_B records are used to specify  the  hosts  that
         provide  a  style of distributed service advertised
         under this domain name.  A subtype value (analogous
         to the ``preference'' value in the _M_X record) indi-
         cates which style of distributed  service  is  pro-
         vided  with  the  given  name.  Subtype 1 indicates
         that the named host is an AFS (R)  database  server
         for the AFS cell of the given domain name.  Subtype
         2 indicates that the named host provides intra-cell
         name  service  for  the  DCE  (R) cell named by the
         given  domain  name.    In   the   example   above,
         jack..toaster..com  and jill..toaster..com are declared
         to be AFS database servers for the toaster..com  AFS
         cell,  so  that  AFS  clients  wishing service from
         toaster..com are directed to  those  two  hosts  for
         further  information.   The  third  record declares
         that tracker..toaster..com houses a directory  server
         for  the  root of the DCE cell toaster..com, so that
         DCE clients that wish  to  refer  to  DCE  services
         should  consult  with  the host tracker..toaster..com
         for  further  information.   The  DCE  sub-type  of
         record  is usually accompanied by a _T_X_T_P _r_e_c_o_r_d _f_o_r
         _o_t_h_e_r _i_n_f_o_r_m_a_t_i_o_n _s_p_e_c_i_f_y_i_n_g _o_t_h_e_r  _d_e_t_a_i_l_s  _t_o  _b_e
         _u_s_e_d  _i_n _a_c_c_e_s_s_i_n_g _t_h_e _D_C_E _c_e_l_l_.  _R_F_C _1_1_8_3 _c_o_n_t_a_i_n_s
         _m_o_r_e _d_e_t_a_i_l_e_d _i_n_f_o_r_m_a_t_i_o_n _o_n _t_h_e _u_s_e _o_f _t_h_i_s _r_e_c_o_r_d
         _t_y_p_e_.













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


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

   66..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
      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 changing regularly old
      ones) then you may even wish to consider a TTL  higher
      than three days.

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

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



















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


      base files.

      66..77..11..  BBoooott FFiilleess

         66..77..11..11..  PPrriimmaarryy SSeerrvveerr


            ;
            ; Boot file for Primary Name Server
            ;


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



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



         66..77..11..33..  CCaacchhiinngg OOnnllyy SSeerrvveerr






















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



            ;
            ; Boot file for Caching Only Name Server
            ;


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





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

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


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






































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


      66..77..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:    May 11, 1994
         ;       related version of root zone:   940516
         ;

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

         ; End of File





















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


      66..77..44..  nnaammeedd..llooccaall



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



      66..77..55..  hhoosstt..rreevv


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

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



      66..77..66..  HHoossttss





















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


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

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












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


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
      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 _/_e_t_c_/_n_a_m_e_d _]_; _t_h_e_n
               _/_e_t_c_/_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..  //eettcc//nnaammeedd..ppiidd

           When _n_a_m_e_d is successfully started up  it  writes
      its  process id into the file _/_e_t_c_/_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 defining _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.










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


      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 schedul-
         ing  all  ``secondary''  zones  for   serial-number
         checks, which could lead to zone transfers ahead of
         the usual schedule.   Normally  serial-number  com-
         pares  are  done only at the intervals specified 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
         USR1  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










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


         results using the dnsstats stats script in the con-
         trib directory.





























































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


                 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 Heiney, 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_._c_o_m_>) 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
organization  would  like  to  participate in funding future
releases.)


              AACCKKNNOOWWLLEEDDGGEEMMEENNTTSS ---- tthhrroouugghh 44..99

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


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

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

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











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


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

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


















































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


                         RREEFFEERREENNCCEESS


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

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

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

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

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

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

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

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

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

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










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


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

[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





































