










                Name Server Operations Guide
                          for BIND
                        _R_e_l_e_a_s_e _4._8

                      Kevin J. Dunlap*
                     Michael J. Karels

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





1.  Introduction

        The Berkeley  Internet  Name  Domain  (BIND)  Server
   implements  the  DARPA Internet name server for the UNIX|-
   operating system.  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 intergrated
   into  4.3BSD  network  programs  for  use  in storing and
   retrieving host names and address.  The  system  adminis-
   trator can configure the system to use BIND as a replace-
   ment to the original host table lookup of information  in
   the  network  hosts  file /_e_t_c/_h_o_s_t_s.  The default confi-
   guration for 4.3BSD uses BIND.


2.  Building A System with a Name Server

        BIND is comprised 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
____________________
   *  The  author  was  an  employee  of  Digital  Equipment
Corporation's  Ultrix Engineering Advanced Development Group
and was on loan to CSRG when this work was done.  Ultrix  is
a trademark of Digital Equipment Corporation.
   |-UNIX is a Trademark of AT&T Bell Laboratories












SMM:11-2               Name Server Operations Guide for BIND


   given network port. The standard port for UDP and TCP  is
   specified in /_e_t_c/_s_e_r_v_i_c_e_s.

   2.1.  Resolver Routines in libc

           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.

           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 is comprised of a few routines  that
      build  query  packets  and exchange them with the name
      server.

           Before building the 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|=''.


   2.2.  The Name Service

           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  RFC882, RFC883, RFC973 and RFC974.  These
      documents can be found  in  /_u_s_r/_s_r_c/_e_t_c/_n_a_m_e_d/_d_o_c  in
      4.3BSD  or  _f_t_ped from sri-nic.arpa. It is also recom-
      meded  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.
____________________
   |=VAX is a Trademark of Digital Equipment Corporation












Name Server Operations Guide for BIND               SMM:11-3


           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
      cooperate.  But this does not work well for large net-
      works where machines cross organizational boundaries.

           With the name server, the network can  be  broken
      into  a hierarchy of domains. The name space is organ-
      ized as a tree according to organizational or adminis-
      trative  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
      several  areas called _z_o_n_e_s, each starting at a domain
      and extending down to the leaf domains or  to  domains
      where  other  zones  start.  Zones  usually  represent
      administrative  boundaries.   An  example  of  a  host
      address  for  a  host at the University of California,
      Berkeley would look as follows:

          _m_o_n_e_t._B_e_r_k_e_l_e_y._E_D_U

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


3.  Types of Servers

        There are several types of servers: Master, Caching,
   Remote, and Slave.

   3.1.  Master Servers

           A Master Server for a domain is the authority for
      that  domain.   This  server  maintains  all  the data
      corresponding to its domain.  Each domain should  have
      at least two master servers, a primary master and some
      secondary masters to provide  backup  service  if  the
      primary is unavailable or overloaded.  A server may be
      a master for multiple domains, being primary for  some
      domains and secondary for others.

      3.1.1.  Primary

              A Primary Master Server is a server that loads
         its data from a file on disk.  This server may also
         delegate authority to other servers in its domain.











SMM:11-4               Name Server Operations Guide for BIND


      3.1.2.  Secondary

              A Secondary Master Server is a server that  is
         delegated  authority  and  receives  its data for a
         domain from a primary master server.  At boot time,
         the  secondary server requests all the data for the
         given zone from the primary  master  server.   This
         server  then  periodically  checks with the primary
         server to see if it needs to update its data.

   3.2.  Caching Only Server

           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 time to live field attached to the
      data when it is received from another server.

   3.3.  Remote Server

           A Remote Server is an option given to people  who
      would  like  to use a name server on 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
      without  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.

   3.4.  Slave Server

           A Slave Server is a server that  always  forwards
      queries  it  cannot satisfy locally to a fixed list of
      _f_o_r_w_a_r_d_i_n_g servers instead  of  interacting  with  the
      master  nameservers  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  give  site  to  be interacting with the rest of the
      Internet servers.  A typically senario 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










Name Server Operations Guide for BIND               SMM:11-5


      other nameservers to resolv the query before returning
      the  answer.  An added benefit of using the forwarding
      feature is that the central machine  develops  a  much
      more complete cache of information that all the works-
      tations can take advantage of.  The use Slave mode and
      forwarding  is discussed further under the description
      of the named bootfile commands.


4.  Setting up Your Own Domain

        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  _C_S_N_E_T,  _D_A_R_P_A
   _I_n_t_e_r_n_e_t  and  _B_I_T_N_E_T) should register with only one net-
   work.

   The contacts are as follows:

   4.1.  DARPA Internet

           Sites that are already on the DARPA Internet  and
      need information on setting up a domain should contact
      HOSTMASTER@SRI-NIC._A_R_P_A.  You  may  also  want  to  be
      placed on the BIND mailing list, which is a mail group
      for people on the DARPA Internet  running  BIND.   The
      group  discusses  future design decisions, 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_c_b_a_r_p_a._B_e_r_k_e_l_e_y._E_D_U.


   4.2.  CSNET

           A  _C_S_N_E_T  member  organization   that   has   not
      registered  its  domain  name should contact the _C_S_N_E_T
      Coordination  and  Information  Center  (_C_I_C)  for  an
      application and information about setting up a domain.

           An organization that  already  has  a  registered
      domain  name should keep the _C_I_C informed about how it
      would like its mail routed.   In  general,  the  _C_S_N_E_T
      relay  will  prefer to send mail via _C_S_N_E_T (as opposed
      to _B_I_T_N_E_T or the _I_n_t_e_r_n_e_t) if possible. For an organi-
      zation  on  multiple  networks, this may not always be
      the preferred behavior. The _C_I_C  can  be  reached  via
      electronic mail at _c_i_c@_s_h._c_s._n_e_t, or by phone at (617)
      497-2777.












SMM:11-6               Name Server Operations Guide for BIND


   4.3.  BITNET

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


5.  Files

        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.

   5.1.  Boot File

           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.

      5.1.1.  Domain

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

             _d_o_m_a_i_n           _B_e_r_k_e_l_e_y._E_d_u

         The name  server  uses  this  information  when  it
         receives a query for a name without a ``.'' that is
         not known.  When it receives one of these  queries,
         it  appends  the  name  in  the second field to the
         query name.  This is  an  obsolete  facility  which
         will be removed from future releases.

      5.1.2.  Directory

              The directory line specifies the directory  in
         which the nameserver should run, allowing the other
         file names in the boot file to  use  relative  path
         names.

             _d_i_r_e_c_t_o_r_y        /_u_s_r/_l_o_c_a_l/_d_o_m_a_i_n

         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 /usr/local/domain 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










Name Server Operations Guide for BIND               SMM:11-7


         named  to  run  in a location that is reasonable to
         dump core if it feels the urge.

      5.1.3.  Primary Master

              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.

      5.1.4.  Secondary Master

              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
         secondary  master server for the zone stated in the
         second field.  The two  network  addresses  specify
         the  name  servers  that  are primary for the zone.
         The secondary server gets its data across the  net-
         work from the listed servers.  Each server is tried
         in the order listed until it successfully  receives
         the  data  from  a listed server.  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  are
         loaded from the backup file if possible, and a pri-
         mary server is then consulted  to  check  that  the
         zone is still up-to-date.

      5.1.5.  Caching Only Server

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











SMM:11-8               Name Server Operations Guide for BIND


         All cache files listed will be  read  in  at  named
         boot  time and any values still valid will be rein-
         stated in the cache and the root nameserver  infor-
         mation in the cache files will always be used.  For
         information on cache file see section on _C_a_c_h_e _I_n_i_-
         _t_i_a_l_i_z_a_t_i_o_n.

      5.1.6.  Forwarders   Any server can make use  of  _f_o_r_-
         _w_a_r_d_e_r_s.   A _f_o_r_w_a_r_d_e_r is another server capable of
         processing recursive queries that is willing to try
         resolving  queries on behalf of other systems.  The
         _f_o_r_w_a_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,  the other systems may not have full network
         access and may be prevent from sending any IP pack-
         ets into the rest of the network and therefore must
         rely on a forwarder which does have access  to  the
         full  net.  The second reason is that the forwarder
         sees a union of all queries as  they  pass  through
         his  server  and therefore he builds up a very rich
         cache of data compared to the cache  in  a  typical
         workstation  nameserver.   In effect, the _f_o_r_w_a_r_d_e_r
         becomes a meta-cache that  all  hosts  can  benefit
         from,  thereby reducing the total number of queries
         from that site to the rest of the net.

      5.1.7.  Slave Mode

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

             _s_l_a_v_e

         in the bootfile.  If _s_l_a_v_e is used, then  you  must
         specify forwarders.  When in slave mode, the server
         will forward each query to each of the the forward-
         ers  until  an  answer is found or the list of for-
         warders is exhausted.

      5.1.8.  Remote Server

              To set up a host that will use a remote server
         instead  of  a  local server to answer queries, the
         file /_e_t_c/_r_e_s_o_l_v._c_o_n_f needs to  be  created.   This
         file  designates  the  name  servers on the network










Name Server Operations Guide for BIND               SMM:11-9


         that should be sent queries.  It is  not  advisable
         to create this file if you have a local server run-
         ning.  If this file exists it is read almost  every
         time _g_e_t_h_o_s_t_b_y_n_a_m_e() or _g_e_t_h_o_s_t_b_y_a_d_d_r() is called.

   5.2.  Cache Initialization

      5.2.1.  root.cache

              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.

   5.3.  Domain Data Files

           There are three standard files for specifying the
      data  for  a domain.  These are _n_a_m_e_d._l_o_c_a_l, _h_o_s_t_s and
      _h_o_s_t._r_e_v.   These  files  use  the  Standard  Resource
      Record Format covered later in this paper.

      5.3.1.  named.local

              This file specifies the address for the  local
         loopback  interface, better known as _l_o_c_a_l_h_o_s_t with
         the network address  127.0.0.1.   The  location  of
         this file is specified in the boot file.

      5.3.2.  hosts

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

      5.3.3.  hosts.rev

              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 specified
         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 natural grouping of
         hosts in a network.










SMM:11-10              Name Server Operations Guide for BIND


   5.4.  Standard Resource Record Format

           The records in the name  server  data  files  are
      called resource records.  The Standard Resource Record
      Format (RR) is specified in RFC882  and  RFC973.   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 some
      RR's 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;
      there are  currently  two  classes:  _I_N  for  internet
      addresses and _A_N_Y for all address classes.  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.

      The following characters have special meanings:

      .    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 recog-
           nized within parentheses.












Name Server Operations Guide for BIND              SMM:11-11


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

      *    An asterisk signifies wildcarding.

           Most resource records will have the current  ori-
      gin  appended to names if they are not terminated by 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 of the
      domain for which you are creating the data  file,  end
      the name with a ``.''.

      5.4.1.  $INCLUDE

              An include line begins with $INCLUDE, starting
         in  column 1, and is followed by a file name.  This
         feature is particularly useful for separating  dif-
         ferent types of data into multiple files.  An exam-
         ple would be:

             $INCLUDE /usr/named/data/mailboxs

         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_b_o_x_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  zone  to  be  organized  in
         separate files.  For example, mailbox data might be
         kept separately from host data using  this  mechan-
         ism.

      5.4.2.  $ORIGIN

              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  is  useful  for
         putting more then one domain in a data file.

      5.4.3.  SOA - Start Of Authority


         _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. (
                                     1.1       ; Serial
                                     3600      ; Refresh
                                     300       ; Retry
                                     3600000   ; Expire
                                     3600 )    ; Minimum













SMM:11-12              Name Server Operations Guide for BIND


         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.  The name
         server cannot handle numbers over  9999  after  the
         decimal point.  The refresh indicates how often, in
         seconds, a secondary name servers is to check  with
         the  primary  name  server  to  see if an update is
         needed.  The retry indicates how long, in  seconds,
         a  secondary  server is to retry after a failure to
         check for a refresh.  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.   There  should only be one _S_O_A record per
         zone.

      5.4.4.  NS - Name Server

         {_n_a_m_e}   {_t_t_l}   _a_d_d_r-_c_l_a_s_s   _N_S   _N_a_m_e _s_e_r_v_e_r_s _n_a_m_e
                          IN           NS   ucbarpa.Berkeley.Edu.

         The _N_a_m_e _S_e_r_v_e_r record, _N_S,  lists  a  name  server
         responsible  for  a  given  domain.  The first name
         field lists the domain  that  is  serviced  by  the
         listed  name server.  There should be one _N_S record
         for each Primary Master server for the domain.

      5.4.5.  A - Address

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

      5.4.6.  HINFO - Host Information

         {_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
                          ANY          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











Name Server Operations Guide for BIND              SMM:11-13


         operating system that are  running  at  the  listed
         host.   It should be noted that only a single space
         separates the hardware info and the operating  sys-
         tem  info.  If  you  want to include a space in the
         machine name you must quote the name.  Host  infor-
         mation is not specific to any address class, so _A_N_Y
         may be used for the address class.  There should be
         one _H_I_N_F_O record for each host.


      5.4.7.  WKS - Well Known Services

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


      5.4.8.  CNAME - Canonical Name

         _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

         _C_a_n_o_n_i_c_a_l _N_a_m_e resource record, _C_N_A_M_E, specifies an
         alias for a canonical name.  An alias should be the
         only record associated with  the  alias  name;  all
         other  resource  records  should be associated with
         the canonical name and not  with  the  alias.   Any
         resource  records  that  include  a  domain name as
         their value (e.g. NS or MX) should list the canoni-
         cal name, not the alias.

      5.4.9.  PTR - Domain Name Pointer

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












SMM:11-14              Name Server Operations Guide for BIND


         A _D_o_m_a_i_n _N_a_m_e _P_o_i_n_t_e_r record, _P_T_R,  allows  special
         names  to  point  to  some  other  location  in the
         domain. The above example of a _P_T_R record  is  used
         in  setting up reverse pointers for the special _I_N-
         _A_D_D_R._A_R_P_A domain. This line  is  from  the  example
         _h_o_s_t_s._r_e_v  file.  _P_T_R names should be unique to the
         zone.

      5.4.10.  MB - Mailbox

         _n_a_m_e     {_t_t_l}   _a_d_d_r-_c_l_a_s_s   _M_B   _M_a_c_h_i_n_e
         miriam           IN           MB   vineyd.DEC.COM.

         _M_B is the _M_a_i_l_b_o_x record.  This lists  the  machine
         where a user wants to receive mail.  The name field
         is the users login; the machine field  denotes  the
         machine to which mail is to be delivered.  Mail Box
         names should be unique to the zone.

      5.4.11.  MR - Mail Rename Name

         _n_a_m_e           {_t_t_l}   _a_d_d_r-_c_l_a_s_s   _M_R   _c_o_r_r_e_s_p_o_n_d_i_n_g _M_B
         Postmistress           IN           MR   miriam

         _M_a_i_n _R_e_n_a_m_e, _M_R, can be used to list aliases for  a
         user.   The name field lists the alias for the name
         listed in the fourth field,  which  should  have  a
         corresponding _M_B record.

      5.4.12.  MINFO - Mailbox Information

         _n_a_m_e   {_t_t_l}   _a_d_d_r-_c_l_a_s_s   _M_I_N_F_O   _r_e_q_u_e_s_t_s       _m_a_i_n_t_a_i_n_e_r
         BIND           IN           MINFO   BIND-REQUEST   kjd.Berkeley.Edu.

         _M_a_i_l _I_n_f_o_r_m_a_t_i_o_n  record,  _M_I_N_F_O,  creates  a  mail
         group  for a mailing list.  This resource record is
         usually associated with a mail  group  _M_a_i_l  _G_r_o_u_p,
         but  may  be used with a _M_a_i_l _B_o_x record.  The _n_a_m_e
         specifies the name of the  mailbox.   The  _r_e_q_u_e_s_t_s
         field is where mail such as requests to be added to
         a mail group should be sent.  The _m_a_i_n_t_a_i_n_e_r  is  a
         mailbox  that  should receive error messages.  This
         is particularly appropriate for mailing lists  when
         errors  in  members  names  should be reported to a
         person other than the sender.

      5.4.13.  MG - Mail Group Member

         {_m_a_i_l _g_r_o_u_p _n_a_m_e}   {_t_t_l}   _a_d_d_r-_c_l_a_s_s   _M_G   _m_e_m_b_e_r _n_a_m_e
                                     IN           MG   Bloom

         _M_a_i_l _G_r_o_u_p, _M_G lists members of a mail group.











Name Server Operations Guide for BIND              SMM:11-15


         An example for setting up a mailing list is as fol-
         lows:

         Bind      IN   MINFO   Bind-Request            kjd.Berkeley.Edu.
                   IN   MG      Ralph.Berkeley.Edu.
                   IN   MG      Zhou.Berkeley.Edu.
                   IN   MG      Painter.Berkeley.Edu.
                   IN   MG      Riggle.Berkeley.Edu.
                   IN   MG      Terry.pa.Xerox.Com.


      5.4.14.  MX - Mail Exchanger

         _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_r _e_x_c_h_a_n_g_e_r
         Munnari.OZ.AU.           IN           MX   0                  Seismo.CSS.GOV.
         *.IL.                    IN           MX   0                  RELAY.CS.NET.

         _M_a_i_n _E_x_c_h_a_n_g_e_r records, _M_X, are used to  specify  a
         machine that knows how to deliver mail to a machine
         that is not directly connected to the network.   In
         the first example, above, Seismo.CSS.GOV. is a mail
         gateway  that  knows  how  to   deliver   mail   to
         Munnari.OZ.AU.  but  other  machines on the network
         can not deliver mail directly to Munnari. 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.  See RFC974 for more detailed information.

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

   5.5.  Sample Files

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

      5.5.1.  Boot File















SMM:11-16              Name Server Operations Guide for BIND


         5.5.1.1.  Primary Master Server


            ;
            ; Boot file for Primary Master Name Server
            ;


            ; type      domain                 source file or host
            ;
            directory   /usr/local/domain
            primary     Berkeley.Edu           ucbhosts
            primary     32.128.in-addr.arpa    ucbhosts.rev
            primary     0.0.127.in-addr.arpa   named.local
            cache       .                      root.cache



         5.5.1.2.  Secondary Master Server


            ;
            ; Boot file for Primary Master Name Server
            ;


            ; type      domain                 source file or host
            ;
            directory   /usr/local/domain
            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



         5.5.1.3.  Caching Only Server


            ;
            ; Boot file for Caching Only Name Server
            ;


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














Name Server Operations Guide for BIND              SMM:11-17


      5.5.2.  Remote Server

         5.5.2.1.  /etc/resolv.conf


            domain Berkeley.Edu
            nameserver 128.32.0.4
            nameserver 128.32.0.10



      5.5.3.  root.cache


         ;
         ;
         ; Initial cache data for root domain servers.
         ;


         .                                            99999999   IN   NS   SRI-NIC.ARPA.
                                                      99999999   IN   NS   NS.NASA.GOV.
                                                      99999999   IN   NS   TERP.UMD.EDU.
                                                      99999999   IN   NS   A.ISI.EDU.
                                                      99999999   IN   NS   BRL-AOS.ARPA.
                                                      99999999   IN   NS   GUNTER-ADAM.ARPA.
                                                      99999999   IN   NS   C.NYSER.NET.

         .T&
         l s s s s
         l l l l l.
         ;  Prep the cache (hotwire the addresses).
         SRI-NIC.ARPA.                                99999999   IN   A    10.0.0.51
         SRI-NIC.ARPA.                                99999999   IN   A    26.0.0.73
         NS.NASA.GOV.                                 99999999   IN   A    128.102.16.10
         A.ISI.EDU.                                   99999999   IN   A    26.3.0.103
         BRL-AOS.ARPA.                                99999999   IN   A    128.20.1.2
         BRL-AOS.ARPA.                                99999999   IN   A    192.5.25.82
         BRL-AOS.ARPA.                                99999999   IN   A    192.5.22.82
         GUNTER-ADAM.ARPA.                            99999999   IN   A    26.1.0.13
         C.NYSER.NET.                                 99999999   IN   A    128.213.5.17
         TERP.UMD.EDU.                                99999999   IN   A    10.1.0.17



      5.5.4.  named.local

















SMM:11-18              Name Server Operations Guide for BIND




         @   IN   SOA   ucbvax.Berkeley.Edu. kjd.ucbvax.Berkeley.Edu. (
                        1       ; Serial
                        3600    ; Refresh
                        300     ; Retry
                        3600000 ; Expire
                        3600 )  ; Minimum
             IN   NS    ucbvax.Berkeley.Edu.
         1   IN   PTR   localhost.





















































Name Server Operations Guide for BIND              SMM:11-19


      5.5.5.  Hosts






























































SMM:11-20              Name Server Operations Guide for BIND


         ;
         ;    @(#)ucb-hosts    1.1    (berkeley)    86/02/05
         ;

         @              IN    SOA     ucbvax.Berkeley.Edu. kjd.monet.Berkeley.Edu. (
                                      1.1       ; Serial
                                      3600      ; Refresh
                                      300       ; Retry
                                      3600000   ; Expire
                                      3600 )    ; Minimum
                        IN    NS      ucbarpa.Berkeley.Edu.
                        IN    NS      ucbvax.Berkeley.Edu.
         localhost      IN    A       127.1
         ucbarpa        IN    A       128.32.4
                        IN    A       10.0.0.78
                        ANY   HINFO   VAX-11/780 UNIX
         arpa           IN    CNAME   ucbarpa
         ernie          IN    A       128.32.6
                        ANY   HINFO   VAX-11/780 UNIX
         ucbernie       IN    CNAME   ernie
         monet          IN    A       128.32.7
                        IN    A       128.32.130.6
                        ANY   HINFO   VAX-11/750 UNIX
         ucbmonet       IN    CNAME   monet
         ucbvax         IN    A       10.2.0.78
                        IN    A       128.32.10
                        ANY   HINFO   VAX-11/750 UNIX
                        IN    WKS     128.32.0.10 UDP syslog 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 )
         vax            IN    CNAME   ucbvax
         toybox         IN    A       128.32.131.119
                        ANY   HINFO   Pro350 RT11
         toybox         IN    MX      0  monet.Berkeley.Edu
         miriam         ANY   MB      vineyd.DEC.COM.
         postmistress   ANY   MR      Miriam
         Bind           ANY   MINFO   Bind-Request kjd.Berkeley.Edu.
                        ANY   MG      Ralph.Berkeley.Edu.
                        ANY   MG      Zhou.Berkeley.Edu.
                        ANY   MG      Painter.Berkeley.Edu.
                        ANY   MG      Riggle.Berkeley.Edu.
                        ANY   MG      Terry.pa.Xerox.Com.













Name Server Operations Guide for BIND              SMM:11-21


      5.5.6.  host.rev


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

         @       IN   SOA   ucbvax.Berkeley.Edu. kjd.monet.Berkeley.Edu. (
                            1.1     ; Serial
                            3600    ; Refresh
                            300     ; Retry
                            3600000 ; Expire
                            3600 )  ; Minimum
                 IN   NS    ucbarpa.Berkeley.Edu.
                 IN   NS    ucbvax.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.







6.  Domain Management

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

   6.1.  /etc/rc.local

           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.   Do  Not  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 having a cache.

   6.2.  /etc/named.pid

           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











SMM:11-22              Name Server Operations Guide for BIND


      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.

   6.3.  /etc/hosts

           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_g(_8_C) to
      configure the machines local interfaces and to  enable
      a  system manager to access the network while the sys-
      tem is in single user mode.  It is  advisable  to  put
      the local machines interface addresses and a couple 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  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 advised to use this option when the
      system is in multi user mode.


   6.4.  Signals

           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.

      6.4.1.  Reload

              SIGHUP - Causes _n_a_m_e_d to read  _n_a_m_e_d._b_o_o_t  and
         reload the database.  All previously cached data is
         lost.  This is useful when you have made  a  change
         to  a data file and you want _n_a_m_e_d's internal data-
         base to reflect the change.

      6.4.2.  Debugging

              When _n_a_m_e_d is running incorrectly, look  first
         in  /_u_s_r/_a_d_m/_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.

              SIGINT - Dumps the current data base and cache
         to  /_u_s_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
         correctly.   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.










Name Server Operations Guide for BIND              SMM:11-23


              SIGUSR1 - Turns on debugging.  Each  following
         USR1  increments  the debug level.  The output goes
         to /_u_s_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.



                      ACKNOWLEDGEMENTS

     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.

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






















SMM:11-24              Name Server Operations Guide for BIND


                         REFERENCES


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

[RFC973]  Mockapetris, P., "Domain System Changes and Obser-
          vations." _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_3 Network
          Information Center, SRI International, Menlo Park,
          California.  February 1986.

[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
          Center, 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
          Center, 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.

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






