NAMED man page on 4.4BSD

Man page or keyword search:  
man Server   1065 pages
apropos Keyword Search (all sections)
Output format
4.4BSD logo
[printable version]

NAMED(8)							      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''	deter‐
	      mines the level of messages printed.

       -p     Use  a  different port number.  The default is the standard port
	      number as returned by getservbyname(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 compiled with QRY‐
	      LOG 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 mul‐
       tiple 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
	 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 direc‐
       tory 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
       ``root.cache'' file should be retrieved periodically from FTP.RS.INTER‐
       NIC.NET since it contains a list of root servers, and this list changes
       periodically.

       The  first  example  ``primary''	 line  states  that  the file ``berke‐
       ley.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  ori‐
       gin,  in	 this  case,  ``Berkeley.EDU''	(see below for a more detailed
       description).  The second ``primary'' line states that the file	``ucb‐
       hosts.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 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 transferred 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
       successful zone transfer.  This is not recommended since it is a	 need‐
       less  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  for‐
       warder 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 for‐
       warders.	 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 net‐
       work addresses listed first, then addresses  on	the  sort  list,  then
       other addresses.

       The  ``xfrnets''	 directive (not shown) can be used to implement prima‐
       tive access control.  If this directive is given, then your name server
       will  only  answer  zone transfer requests from hosts which are on net‐
       works listed in your ``xfrnets'' directives.  This directive  may  also
       be given as ``tcplist'' for compatibility with older, interrim servers.

       The  ``include''	 directive (not shown) can be used to process the con‐
       tents 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
       people.	 The  ``include'' directive takes one argument, that being the
       name of the file whose contents are to be included.  No quotes are nec‐
       essary 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  end‐
       ing  with ``.'' are unmodified.	The opt_domain field is used to define
       an origin for the data in an included file.  It is equivalent to	 plac‐
       ing  a  $ORIGIN	statement  before the first line of the included file.
       The field is optional.  Neither the opt_domain field nor $ORIGIN state‐
       ments  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  preference	 value
		(0..32767), with lower numeric values representing higher log‐
		ical 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)).

       NULL	a null resource record (no format or data)

       RP	a Responsible Person for some domain name (mailbox, TXT-refer‐
		ral)

       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  contin‐
       ued 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 multi‐
       plication 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.  Sec‐
       ondary 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  con‐
       tacted  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.

NOTES
       The boot file directives ``domain'' and ``suffixes''  have  been	 obso‐
       leted  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 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	 with‐
	      out SIGUSR2)

       SIGWINCH
	      Toggles  logging of all incoming queries via syslog(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
       /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), host‐
       name(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			      NAMED(8)
[top]

List of man pages available for 4.4BSD

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net