unixdev.net


Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (4.4BSD-Lite2)
Page:
Section:
Apropos / Subsearch:
optional field



NAMED(8)           BSD System Manager's Manual           NAMED(8)


NAME
       named - Internet domain name server

SYNOPSIS
       named [ -d debuglevel ] [ -p port# ] [{-b} bootfile ] [ -q
       ] [ -r ]

DESCRIPTION
       Named is the Internet domain name server.  See RFC's 1033,
       1034,  and 1035 for more information on the Internet name-
       domain system.  Without any arguments, named will read the
       default  boot  file /etc/named.boot, read any initial data
       and listen for queries.

       Options are:

       -d     Print debugging information.  A  number  after  the
              ``d'' determines the level of messages printed.

       -p     Use  a  different  port number.  The default is the
              standard port  number  as  returned  by  getservby-
              name(3) for service ``domain''.

       -b     Use  an  alternate boot file.  This is optional and
              allows you to specify a file with a leading dash.

       -q     Trace all incoming queries if named has  been  com-
              piled with QRYLOG defined.

       -r     Turns  recursion  off  in  the server.  Answers can
              come only from local (primary or secondary)  zones.
              This can be used on root servers.

       Any  additional  argument is taken as the name of the boot
       file.  If multiple boot files are specified, only the last
       is used.

       The  boot  file  contains information about where the name
       server is to get its initial data.  Lines in the boot file
       cannot be continued on subsequent lines.  The following is
       a small example:

         ;
         ;    boot file for name server
         ;
         directory /usr/local/adm/named

         ; type     domain                source host/file          backup file

         cache      .                                               root.cache
         primary    Berkeley.EDU          berkeley.edu.zone



4th Berkeley Distribution April 17, 1993                        1








NAMED(8)           BSD System Manager's Manual           NAMED(8)


         primary    32.128.IN-ADDR.ARPA   ucbhosts.rev
         secondary  CC.Berkeley.EDU       128.32.137.8 128.32.137.3 cc.zone.bak
         secondary  6.32.128.IN-ADDR.ARPA 128.32.137.8 128.32.137.3 cc.rev.bak
         primary    0.0.127.IN-ADDR.ARPA                            localhost.rev
         forwarders 10.0.0.78 10.2.0.78
         ; slave

       The ``directory'' line causes the  server  to  change  its
       working directory to the directory specified.  This can be
       important for the correct processing of $INCLUDE files  in
       primary zone files.

       The  ``cache''  line specifies that data in ``root.cache''
       is to be placed in the backup cache.  Its main use  is  to
       specify  data  such  as  locations of root domain servers.
       This cache is not used during  normal  operation,  but  is
       used  as  ``hints'' to find the current root servers.  The
       file ``root.cache'' is in  the  same  format  as  ``berke-
       ley.edu.zone''.  There can be more than one ``cache'' file
       specified.  The ``root.cache'' file  should  be  retrieved
       periodically  from FTP.RS.INTERNIC.NET since it contains a
       list of root servers, and this list changes  periodically.

       The  first  example  ``primary'' line states that the file
       ``berkeley.edu.zone'' contains authoritative data for  the
       ``Berkeley.EDU''  zone.   The  file  ``berkeley.edu.zone''
       contains data in  the  master  file  format  described  in
       RFC883.   All  domain names are relative to the origin, in
       this case, ``Berkeley.EDU'' (see below for a more detailed
       description).  The second ``primary'' line states that the
       file ``ucbhosts.rev'' contains authoritative data for  the
       domain ``32.128.IN-ADDR.ARPA,'' which is used to translate
       addresses in network 128.32  to  hostnames.   Each  master
       file  should  begin  with  an SOA record for the zone (see
       below).

       The first example ``secondary'' line  specifies  that  all
       authoritative  data  under  ``CC.Berkeley.EDU''  is  to be
       transferred from the name server at 128.32.137.8.  If  the
       transfer  fails it will try 128.32.137.3 and continue try-
       ing the addresses, up to 10, listed  on  this  line.   The
       secondary  copy  is  also  authoritative for the specified
       domain.  The first non-dotted-quad address  on  this  line
       will  be taken as a filename in which to backup the trans-
       ferred zone.  The name server will load the zone from this
       backup  file  if it exists when it boots, providing a com-
       plete copy even if the  master  servers  are  unreachable.
       Whenever a new copy of the domain is received by automatic
       zone transfer from one of the master  servers,  this  file
       will  be  updated.   If no file name is given, a temporary
       file  will  be  used,  and  will  be  deleted  after  each



4th Berkeley Distribution April 17, 1993                        2








NAMED(8)           BSD System Manager's Manual           NAMED(8)


       successful  zone  transfer.  This is not recommended since
       it is a needless waste of bandwidth.  The  second  example
       ``secondary''  line  states  that  the address-to-hostname
       mapping for the subnet 128.32.136 should be obtained  from
       the same list of master servers as the previous zone.

       The   ``forwarders''   line  specifies  the  addresses  of
       sitewide servers that will accept recursive  queries  from
       other  servers.   If  the  boot file specifies one or more
       forwarders, then the server will send all queries for data
       not  in the cache to the forwarders first.  Each forwarder
       will be asked in turn until an answer is returned  or  the
       list  is  exhausted.   If  no answer is forthcoming from a
       forwarder, the server will continue as it would have with-
       out  the  forwarders  line unless it is in ``slave'' mode.
       The  forwarding  facility  is  useful  to  cause  a  large
       sitewide  cache to be generated on a master, and to reduce
       traffic over links to outside servers.   It  can  also  be
       used  to  allow  servers  to  run  that do not have access
       directly to the Internet, but wish to act as  though  they
       do.

       The  ``slave''  line  (shown commented out) is used to put
       the server in slave mode.  In this mode, the  server  will
       only  make queries to forwarders.  This option is normally
       used on machine that wish to run a server but for physical
       or  administrative  reasons  cannot be given access to the
       Internet, but have access to a host that does have access.

       The  ``sortlist''  line  can  be used to indicate networks
       that are to be preferred over other networks  Queries  for
       host  addresses  from  hosts  on  the  same network as the
       server will receive responses with local network addresses
       listed  first, then addresses on the sort list, then other
       addresses.

       The ``xfrnets'' directive  (not  shown)  can  be  used  to
       implement  primative access control.  If this directive is
       given, then your name server will only answer zone  trans-
       fer  requests  from  hosts which are on networks listed in
       your ``xfrnets'' directives.  This directive may  also  be
       given  as ``tcplist'' for compatibility with older, inter-
       rim servers.

       The ``include'' directive (not shown) can be used to  pro-
       cess  the  contents  of  some  other  file  as though they
       appeared in place of the ``include'' directive.   This  is
       useful  if  you have a lot of zones or if you have logical
       groupings of zones which are maintained by different  peo-
       ple.   The  ``include'' directive takes one argument, that
       being the name of  the  file  whose  contents  are  to  be



4th Berkeley Distribution April 17, 1993                        3








NAMED(8)           BSD System Manager's Manual           NAMED(8)


       included.  No quotes are necessary around the file name.

       The  ``bogusns''  directive (not shown) tells BIND that no
       queries are to  be  sent  to  the  specified  name  server
       addresses  (which  are  specified  as dotted quads, not as
       domain names).  This is useful when  you  know  that  some
       popular  server  has  bad data in a zone or cache, and you
       want to avoid contamination while  the  problem  is  being
       fixed.

       The master file consists of control information and a list
       of resource records for objects in the zone of the forms:

              $INCLUDE <filename> <opt_domain>
              $ORIGIN <domain>
              <domain> <opt_ttl> <opt_class> <type> <resource_record_data>

       where domain is "." for root, "@" for the current  origin,
       or  a standard domain name. If domain is a standard domain
       name that does not end with ``.'', the current  origin  is
       appended to the domain. Domain names ending with ``.'' are
       unmodified.  The opt_domain field is  used  to  define  an
       origin for the data in an included file.  It is equivalent
       to placing a $ORIGIN statement before the  first  line  of
       the  included  file.   The field is optional.  Neither the
       opt_domain field nor $ORIGIN statements  in  the  included
       file modify the current origin for this file.  The opt_ttl
       field is an optional integer number for  the  time-to-live
       field.   It  defaults  to  zero, meaning the minimum value
       specified in the SOA record for the zone.   The  opt_class
       field  is the object address type; currently only one type
       is supported, IN,  for  objects  connected  to  the  DARPA
       Internet.   The  type  field contains one of the following
       tokens; the  data  expected  in  the  resource_record_data
       field is in parentheses.

       A        a host address (dotted quad)

       NS       an authoritative name server (domain)

       MX       a  mail exchanger (domain), preceded by a prefer-
                ence value (0..32767), with lower numeric  values
                representing higher logical preferences.

       CNAME    the canonical name for an alias (domain)

       SOA      marks the start of a zone of authority (domain of
                originating host, domain address of maintainer, a
                serial  number  and  the  following parameters in
                seconds: refresh, retry, expire and  minimum  TTL
                (see RFC883)).



4th Berkeley Distribution April 17, 1993                        4








NAMED(8)           BSD System Manager's Manual           NAMED(8)


       NULL     a null resource record (no format or data)

       RP       a  Responsible Person for some domain name (mail-
                box, TXT-referral)

       PTR      a domain name pointer (domain)

       HINFO    host information (cpu_type OS_type)

       Resource records normally end at the end of  a  line,  but
       may  be continued across lines between opening and closing
       parentheses.  Comments are introduced  by  semicolons  and
       continue to the end of the line.

       Note that there are other resource record types, not shown
       here.   You  should  consult  the  BIND  Operations  Guide
       (``BOG'')  for  the  complete  list.  Some resource record
       types may have been standardized in newer  RFC's  but  not
       yet implemented in this version of BIND.

       Each  master zone file should begin with an SOA record for
       the zone.  An example SOA record is as follows:

       @    IN   SOA  ucbvax.Berkeley.EDU. rwh.ucbvax.Berkeley.EDU. (
                           1989020501     ; serial
                           10800     ; refresh
                           3600 ; retry
                           3600000   ; expire
                           86400 )   ; minimum

       The SOA specifies a serial number, which should be changed
       each  time  the  master  file  is  changed.  Note that the
       serial number can be given as a dotted number, but this is
       a  very unwise thing to do since the translation to normal
       integers is via concatenation rather  than  multiplication
       and  addition.   You can spell out the year, month, day of
       month, and 0..99 version number and still fit  inside  the
       unsigned  32-bit  size  of  this field.  It's true that we
       will have to  rethink  this  strategy  in  the  year  4294
       (Greg.) but we're not worried about it.  Secondary servers
       check the serial number  at  intervals  specified  by  the
       refresh  time  in seconds; if the serial number changes, a
       zone transfer will be done to load the  new  data.   If  a
       master  server  cannot be contacted when a refresh is due,
       the retry time specifies the interval at  which  refreshes
       should  be  attempted.   If a master server cannot be con-
       tacted within the interval given by the expire  time,  all
       data from the zone is discarded by secondary servers.  The
       minimum  value  is  the  time-to-live  (``TTL'')  used  by
       records in the file with no explicit time-to-live value.




4th Berkeley Distribution April 17, 1993                        5








NAMED(8)           BSD System Manager's Manual           NAMED(8)


NOTES
       The  boot file directives ``domain'' and ``suffixes'' have
       been obsoleted by a more useful resolver-based implementa-
       tion  of  suffixing  for partially qualified domain names.
       The prior mechanisms could fail under a number  of  situa-
       tions,  especially when then local nameserver did not have
       complete information.

       The following signals have the specified effect when  sent
       to the server process using the kill(1) command.

       SIGHUP Causes   server   to  read  named.boot  and  reload
              database.   If  the  server  is  built   with   the
              FORCED_RELOAD compile-time option, then SIGHUP will
              also cause the server to check the serial number on
              all  secondary  zones.  Normally the serial numbers
              are only checked at the SOA-specified intervals.

       SIGINT Dumps   current   data   base    and    cache    to
              /var/tmp/named_dump.db

       SIGIOT Dumps  statistics data into /var/tmp/named.stats if
              the server is compiled -DSTATS.  Statistics data is
              appended to the file.

       SIGSYS Dumps  the profiling data in /var/tmp if the server
              is compiled with profiling  (server  forks,  chdirs
              and exits).

       SIGTERM
              Dumps  the  primary  and  secondary database files.
              Used to save  modified  data  on  shutdown  if  the
              server is compiled with dynamic updating enabled.

       SIGUSR1
              Turns  on  debugging; each SIGUSR1 increments debug
              level.  (SIGEMT on older systems without SIGUSR1)

       SIGUSR2
              Turns off debugging completely.  (SIGFPE  on  older
              systems without SIGUSR2)

       SIGWINCH
              Toggles  logging  of  all incoming queries via sys-
              log(8) (requires server to have been built with the
              QRYLOG option).

FILES
       /etc/named.boot          name server configuration boot file
       /etc/named.pid           the process id (/var/run/named.pid on newer systems)
       /var/tmp/named.run       debug output



4th Berkeley Distribution April 17, 1993                        6








NAMED(8)           BSD System Manager's Manual           NAMED(8)


       /var/tmp/named_dump.db   dump of the name server database
       /var/tmp/named.stats     nameserver statistics data

SEE ALSO
       kill(1),   gethostbyname(3N),   signal(3c),   resolver(3),
       resolver(5), hostname(7), RFC 882, RFC 883, RFC  973,  RFC
       974,  RFC  1033, RFC 1034, RFC 1035, RFC 1123, Name Server
       Operations Guide for BIND














































4th Berkeley Distribution April 17, 1993                        7