Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (OSF1-V5.1-alpha)
Apropos / Subsearch:
optional field

named(8)							     named(8)


  named	- Internet domain name server (DNS)


  named	[-d debuglevel]	[-p port#] [{-b	 | -c }	configfile] [-f] [-q] [-r]
  [-w  directory] [configfile]


  -d debuglevel
      Prints debugging information.  The debuglevel variable specifies the
      level of messages	printed.  If the value is negative, debuglevel is set
      to 1.

      This enables you to specify multiple, distinct level of debugging	for
      categories of events (for	example, queries and transfers in and out) by
      using the	logging	statement in the named.conf file.  See named.conf(4)
      for more information.

  -p port#
      Specifies	a different remote port	number.	 This is the port number to
      which named sends	queries.  The default is the standard port number for
      the domain service as listed in the /etc/services	file.

  {-b|-c} configfile
      Specifies	a configfile with a leading dash. (The -b option is not
      required unless the specified configfile begins with a dash.)

  -f  Runs this	process	in the foreground instead of executing fork(2) and
      running as a daemon.  By default,	the commands forks another process
      and runs in the background as a daemon.

  -q  Traces all incoming queries.

      The queries logging_category clause in the configuration file logging
      statement	provides the same function and is preferred over the -q

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

      The recursion clause in the configuration	file options statement pro-
      vides the	same function and is preferred over the	-r option.

  -w directory
      Sets the working directory of the	server.	The default working directory
      is the current directory.

      The directory clause of the configuration	file options statement over-
      rides any	value specified	on the command line.

  To provide compatibility with	previous versions of BIND, any additional
  argument following the options and their arguments is	considered the name
  of the configuration file.  This argument overrides any configfile speci-
  fied with the	-b or -c options.  If no argument is given, the	default	con-
  figuration file, /etc/named.conf, is used.


  The named daemon is the Internet domain name server.	See RFC	1033, RFC
  1034,	and RFC	1035 for more information on the Internet name-domain system.
  Without any arguments, named reads the default configuration file
  /etc/named.conf, reads any initial data, and listens for queries.  If	you
  specify a configfile argument	at the end of the command line,	the value
  overrides any	configuration file specified with the -b or -c options.

  The following	is an example of part of a named.conf file, created by the
  network administrator:

       options {
	  directory "/etc/namedb";
	  named-xfer "/usr/sbin/named-xfer";   // _PATH_XFER
	  dump-file "named_dump.db";	  // _PATH_DUMPFILE
	  pid-file "/var/run/named.pid";  // _PATH_PIDFILE
	  statistics-file "named.stats";  // _PATH_STATS
	  forward first;
	     forwarders	{;;
	  transfers-in 10;
	  transfer-format one-answer;
	  allow-transfer {;
       zone Berkeley.EDU {
	  type master;			  // what used to be called primary
	  file "berkeley.edu.zone";
	  check-names fail;
	  allow-update { any; };
       zone 32.128.IN-ADDR.ARPA	{
	  type master;			  // what used to be called primary
	  file "ucbhost.rev";
	  check-names fail;
	  allow-update { any; };
       zone CC.Berkeley.EDU {
	  type slave;			  // what used to be called secondary
	  file "cc.zone.bak";
	  masters {;		   // where to zone transfer from;
       zone 6.32.128.IN-ADDR.ARPA {
	  type slave;			  // what used to be called secondary
	  file "cc.rev.bak";
	  masters {;		   // where to zone transfer from;
       // load the cache data last
       zone "."	{
	  type hint;
	  file "named.ca";

  The options statement	aggregates all global options in one place.  A
  description of each option follows:

    +  The directory option 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 named-xfer option specifies the program that	executes the
       transfers from master servers.  This overrides the default program

    +  The dump-file option specifies the file or path for dump	of the name
       server database.	 This overrides	the default file name.

    +  The pid-file option specifies the file or path for Process Id of	name
       server daemon.  This overrides the default file name.

    +  The statistics-file specifies the file or path for name server statis-
       tics data.  This	overrides the default file name.

    +  The forwarders option specifies the addresses of	sitewide servers that
       will accept recursive queries from other	servers.  If the boot file
       specifies one or	more forwarders, the server sends all queries for
       data not	in the cache to	the forwarders first.  Each forwarder is
       asked in	turn until an answer is	returned or the	list is	exhausted.
       If no answer is forthcoming from	a forwarder, the server	continues as
       it would	have without the forwarders option unless it is	in forward-
       only mode.  The forwarding facility is useful to	cause a	large site-
       wide cache to be	generated on a master, and to reduce traffic over
       links to	outside	servers.

    +  The transfers-in	option specifies the number of named-xfer sub-
       processes that the server can spawn at any one time.  The default is

    +  The transfer-format option specifies the	format of outbound zone
       transfers (from us to them).  Two values	are allowed: one-answer	and
       many-answers.  If you are doing zone transfers to old servers, do not
       specify many-answers.  The default is one-answer.  You can specify the
       transfer	format on a host-by-host basis in the server statement.

    +  The allow-transfer option provides a form of simple access control. If
       you specify this	option with specific networks, your name server	only
       answers zone transfer requests from hosts that are on networks listed
       in the allow-transfer list.  To specify transfer	to any network,
       specify the option as follows:

	    allow-transfer { any; };

  The zone statement identifies	a zone and its attributes.  Different types
  of zones are identified by the type attribute; for example, master (form-
  erly called primary),	slave (formerly	called secondary), stub, and hint.  A
  description of each zone statement follows:

    +  The first zone statement	specifies 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
       RFC 883.	All domain names are relative to the origin, in	this case,
       Berkeley.EDU (see Master	File section). The allow-update	option allows
       the master server to accept dynamic updates from	new BIND clients for
       its master data file without the	intervention of	the network adminis-
       trator.	The check-names	fail option forces the zone to verify that
       all hostnames contain only valid	characters.  (The default behavior is
       to allow	any characters in the hostname.)  For more information on
       this option, see	the BIND Configuration File Guide on the Tru64 UNIX
       Documentation CD-ROM.

    +  The second zone statement specifies that	the file ucbhosts.rev con-
       tains authoritative data	for the	domain 32.128.IN-ADDR.ARPA, which is
       used to translate addresses in network 128.32 to	host names. Each mas-
       ter file	should begin with an SOA record	for the	zone (see Master File

    +  The third zone statement	specifies that all authoritative data under
       CC.Berkeley.EDU is to be	transferred from the name server at  If the transfer fails, it	tries and con-
       tinues trying the addresses, up to 10, listed in	the masters list.

       The file	cc.zone.bak is the backup for the transferred zone.  The
       secondary copy is also authoritative for	the specified domain.  The
       first non-dotted-quad address on	this line is taken as a	filename in
       which to	backup the transferred zone.  The name server loads 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 is updated.  If no file name is specified, a
       temporary file is used; the temporary file is deleted after each	suc-
       cessful zone transfer.  Be sure to specify a file name to avoid wast-
       ing bandwidth.

    +  The fourth zone statement specifies that	the address-to-hostname	map-
       ping for	the subnet 128.32.136 should be	obtained from the same list
       of master servers as the	previous zone.

       The fifth zone statement	specifies that data in named.local 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	nor-
       mal operation, but is used as hints to find the current root servers.
       The file	named.ca is in the same	format as berkeley.edu.zone. The
       named.ca	file should be updated periodically from FTP.RS.INTERNIC.NET
       since it	contains a list	of root	servers	that are changed periodi-

  The include statement	(not shown) can	be used	to process the contents	of
  some other file as though they appeared in place of the include statement.
  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 statement	is also	useful for separating information that you do
  not want in a	publicly-readable named.conf file. For example,	on IPv4
  servers, if you want to specify a private key	to use for authenticating
  dynamic updates from new BIND	clients	in your	domain,	you can	create a
  separate file	for the	key statement.	Set the	permissions on the new file
  to be	readable/writable only by superuser, then use the include statement
  to call the file into	the named.conf file.  This arrangement allows the
  named	daemon to parse	the key	configuration without revealing	the key	to

  The include statement	requires the name of the file (enclosed	by quotation
  marks) whose contents	are to be included.  For example:

       include "filename";

  The server statement (not shown) allows you to specify options specific to
  a particular server.	The bogus attribute specifies whether to listen	to
  the specific server.	If bogus is set	to yes,	the name server	does not send
  any queries to the specified name server.  This is useful when you know
  that some popular name server	has bad	data in	a zone or cache, and you do
  not want to avoid contamination while	the problem is fixed.  The transfer-
  format attribute specifies whether the one-answer or many-answer option
  should be used for zone transfers.  The default is one-answer, as it will
  work with all	name servers.  This option overrides the global	option for
  the specified	server.	 For example:

       server {
	       bogus no;
	       transfer-format one-answer;

  The key statement (not shown)	defines	a private key to use for authentica-
  tion purposes.  See the Network Administration: Services manual or
  bind_manual_setup(7) for more	information about enabling secure DNS

  Master File

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

       $INCLUDE	<&lt;filename>&gt; <&lt;opt_domain>&gt;
       $ORIGIN <&lt;domain>&gt;
       $TTL <&lt;def_ttl>&gt;
       <&lt;domain>&gt;	<&lt;opt_ttl>&gt; <&lt;opt_class>&gt; <&lt;type>&gt; <&lt;resource_record_data>&gt;

  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

  The opt_domain field defines 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

  The def_ttl field is an value	for the	default	time-to-live.  It specifies
  how long data	will be	stored in the cache.  The value	can be specified in
  seconds or in	the following format, where you	need not specify all of	the


  When the time-to-live	is specified in	the optional $TTL entry, the limit
  takes	takes effect only if no	time-to-live value is specified	for a partic-
  ular resource	record or its corresponding SOA	record.	 The def_ttl value
  must be in the range of 0 to 2147483647 seconds. The maximum in the alter-
  native format	is 3550W5D3H14M7S, or 3550 weeks, 5 days, 3 hours, 14
  minutes, 7 seconds.

  The opt_ttl field is an optional integer number for a	particular resource
  record's time-to-live.  When unspecified, the	time-to-live for a resource
  record defaults to the value specified in the	SOA record for the zone, or
  ultimately, the value	specified in the $TTL entry.

  The opt_class	field is the object address type; currently only one type is
  supported, IN, for objects connected to the 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 IP address)

  NS	  an authoritative name	server (domain)

  MX	  a mail exchanger (domain), preceded by a preference value (0-32767,
	  inclusive), with lower numeric values	representing higher logical

  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

  NULL	  a null resource record (no format or data)

  RP	  a Responsible	Person for some	domain name (mailbox, 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 intro-
  duced	by semicolons and continue to the end of the line.

  This is not a	complete list of resource record types.	 See the Network
  Administration: Services for a complete list.

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

  The boot file	directives domain and suffixes are obsolete because of a more
  useful resolver-based	implementation 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 informa-


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

  SIGHUP  Causes the server to read named.conf,	reload database, and check
	  serial numbers on secondary zones.  Typically, the serial numbers
	  are checked only at intervals	specified in the SOA record.

  SIGINT  Dumps	current	data base and cache to /var/tmp/named_dump.db or the
	  value	of _PATH_DUMPFILE.

  SIGILL  Dumps	statistics data	into /var/tmp/named.stats. Statistics data is
	  appended to the file.

  SIGSYS  Dumps	the profiling data in /var/tmp.

  SIGTERM Dumps	the primary and	secondary database files on shutdown.

  SIGUSR1 Turns	on debugging; each SIGUSR1 signal increments debug level.

  SIGUSR2 Turns	off debugging completely.

	  Enables or disables the logging of incoming queries to the system


      Specifies	the command path

      Default name server configuration	file

      Process ID (_PATH_PIDFILE)

      Debug output (file: _PATH_DEBUG)

      Dump of the name server database (_PATH_DUMPFILE)

      Nameserver statistics data (file:	_PATH_STATS)


  Commands: hostname(1), kill(1)

  Files: named.conf(4),	named.stats(4),	resolver(4)

  Routines: signal(2), gethostbyname(3)

  Specifications: RFC973, RFC974, RFC1033, RFC1034, RFC1035

  Network Administration: Services, Bind Configuration File Guide