Unix/Linux Go Back    

BSD 2.11 - man page for named (bsd section 8)

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:   man
Select Man Page Set:       apropos Keyword Search (sections above)

NAMED(8)										 NAMED(8)

       named - Internet domain name server

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

       Named is the Internet domain name server.  See RFC883 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 mes-
	      sages printed.

       -p     Use a different port number.  The default is the standard port number as listed  in

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

       Any additional argument is taken as the name of the boot file.	The  boot  file  contains
       information  about  where  the  name  server is to get its initial data.  If multiple boot
       files are specified, only the last is used.  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/domain

	 ; type     domain		  source host/file	    backup file

	 cache	    .						    root.cache
	 primary    Berkeley.EDU	  berkeley.edu.zone
	 primary    32.128.IN-ADDR.ARPA   ucbhosts.rev
	 secondary  CC.Berkeley.EDU cc.zone.bak
	 secondary  6.32.128.IN-ADDR.ARPA cc.rev.bak
	 primary    0.0.127.IN-ADDR.ARPA			    localhost.rev
	 ; 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  ``berkeley.edu.zone''.
       There  can  be  more  than one ``cache'' file specified.  The cache files are processed in
       such a way as to preserve the time-to-live's of data dumped out.  Data for the root  name-
       servers is kept artificially valid if necessary.

       The  first ``primary'' line states that the file ``berkeley.edu.zone'' contains authorita-
       tive 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  ``secondary''  line	specifies  that  all authoritative data under ``CC.Berke-
       ley.EDU'' is to be transferred from the name server  at	If  the  transfer
       fails it will try and continue trying 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-
       fered zone.  The name server will load the zone from this backup file if it exists when it
       boots,  providing  a complete 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.   The  second  ``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
       without 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,  unlisted  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.  This line is only acted on at initial
       startup.  When reloading the nameserver with a SIGHUP, this line will be ignored.

       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  con-
       tains  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)

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

       MB	a mailbox domain name (domain)

       MG	a mail group member (domain)

       MR	a mail rename domain name (domain)

       NULL	a null resource record (no format or data)

       WKS	a well know service description (not implemented yet)

       PTR	a domain name pointer (domain)

       HINFO	host information (cpu_type OS_type)

       MINFO	mailbox or mail list information (request_domain error_domain)

       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 con-
       tinue to the end of the line.

       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. (
			   2.89 ; serial
			   10800     ; refresh
			   3600 ; retry
			   3600000   ; expire
			   86400 )   ; minimum

       The  SOA  lists	a  serial  number,  which  should be changed each time the master file is
       changed.  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 until successful.	If a mas-
       ter server cannot be contacted 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 used by
       records in the file with no explicit time-to-live value.

       The boot file directives ``domain'' and ``suffixes'' have been obsoleted by a more  useful
       resolver  based	implementation	of  suffixing  for partially qualified domain names.  The
       prior mechanisms could fail under a number of situations, especially when then local name-
       server 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.

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

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

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

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

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

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

       /etc/named.boot		name server configuration boot file
       /var/run/named.pid	the process id
       /usr/tmp/named.run	debug output
       /usr/tmp/named_dump.db	dump of the name server database
       /usr/tmp/named.stats	nameserver statistics data

       kill(1),  gethostbyname(3),  signal(3),	resolver(3),  resolver(5),  hostname(7),  RFC882,
       RFC883, RFC973, RFC974, Name Server Operations Guide for BIND

4th Berkeley Distribution		February 28, 1988				 NAMED(8)
Unix & Linux Commands & Man Pages : ©2000 - 2018 Unix and Linux Forums

All times are GMT -4. The time now is 04:45 AM.