named man page on DigitalUNIX

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

named(8)							      named(8)

NAME
       named - Internet domain name server (DNS)

SYNOPSIS
       /usr/sbin/named	[-c config-file] [-d debug-level] [-f] [-g] [-n #cpus]
       [-p port] [-s] [-t directory] [-u] [-v] [-x cache-file]

OPTIONS
       Use config-file as the  configuration  file  instead  of	 the  default,
       /etc/named.conf.	 To  ensure that reloading the configuration file con‐
       tinues to work after the server has changed its working	directory  due
       to  a  possible directory option in the configuration file, config-file
       should be an absolute pathname.	Set the daemon's debug level to debug-
       level.	Debugging  traces  from named become more verbose as the debug
       level increases.	 Run the server in the foreground  (that  is,  do  not
       daemonize).   Run the server in the foreground and force all logging to
       stderr.	Create #cpus worker threads  to	 take  advantage  of  multiple
       CPUs.  If not specified, named will try to determine the number of CPUs
       present and create one thread per CPU.  If it is	 unable	 to  determine
       the  number  of	 CPUs, a single worker thread will be created.	Listen
       for queries on port port. If not specified, the	default	 is  port  53.
       Write memory usage statistics to stdout on exit.

					    Note

	      This  option  is mainly of interest to BIND 9 developers and may
	      be removed or changed in a future release.  chroot()  to	direc‐
	      tory  after  processing  the  command line arguments, but before
	      reading the configuration file.

					    Note

	      This option should be used in conjunction with the -u option, as
	      chrooting a process running as root does not enhance security on
	      most systems; the way chroot() is defined allows a process  with
	      root privileges to escape a chroot jail.	setuid() to user after
	      completing privileged operations, such as creating sockets  that
	      listen on privileged ports.  Report the version number and exit.
	      Load data from cache-file into the cache of the default view.

					    Note

	      This option must not be used. It is only	of  interest  to  BIND
	      9 developers and may be removed or changed in a future release.

DESCRIPTION
       The named daemon is a Domain Name System (DNS) server, part of the BIND
       9 distribution  from Internet Systems Consortium	 (ISC).	  Without  any
       arguments,  named reads the default configuration file /etc/named.conf,
       reads any initial data, and listens for queries.

       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 {      10.0.0.78;      10.2.0.78;
	  };
	  transfers-in 10;
	  transfer-format one-answer;
	  allow-transfer {	16.0.0.0;
	  }; }; 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 {
	      128.32.137.8;		   // where to zone transfer from
	      128.32.137.3;
	  }; }; zone 6.32.128.IN-ADDR.ARPA {
	  type slave;			  // what used to be called secondary
	  file "cc.rev.bak";
	  masters {
	      128.32.137.8;		   // where to zone transfer from
	      128.32.137.3;
	  }; }; // // 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 name.  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 statistics 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 sitewide 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 subprocesses	that  the  server  can
       spawn  at any one time.	The default is 10.  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 spec‐
       ify 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, mas‐
       ter (formerly 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 authorita‐
       tive  data  for the Berkeley.EDU zone.  The file berkeley.edu.zone con‐
       tains data in the master file format described in RFC 883.  All	domain
       names  are relative to the origin, in this case, Berkeley.EDU (see Mas‐
       ter 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 administrator.  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 Con‐
       figuration File Guide on the Tru64 UNIX Documentation CD-ROM.  The sec‐
       ond  zone  statement  specifies	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 host names. Each master file
       should begin with an SOA record for the zone (see Master File section).
       The  third  zone	 statement 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 tries 128.32.137.3 and contin‐
       ues 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 successful
	      zone transfer.  Be sure to specify a file name to avoid  wasting
	      bandwidth.    The	 fourth	 zone  statement  specifies  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 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 normal operation, but is used as hints to find
	      the current root servers. The file named.ca is in the same  for‐
	      mat  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 periodically.

       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 authenti‐
       cating  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 users.

       The include statement requires the name of the file (enclosed by quota‐
       tion 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  lis‐
       ten  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 1.2.3.4 {
	       bogus no;
	       transfer-format one-answer; };

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

   Master Files
       The  BIND  master  database files contain the resource records that the
       named daemon uses to respond to queries.

       When you configure a master server with the SysMan  Menu,  the  utility
       optionally  creates  two	 master	 database  files  from	your  existing
       /etc/hosts database -- /etc/namedb/hosts.db, for forward	 lookups,  and
       /etc/namedb/hosts.rev, for reverse lookups. However, you can assign any
       names to these files, or create additional  database  files  for	 other
       domains, provided that you update the zone statements in the named.conf
       file appropriately.

       Database filenames conventionally include  a  prefix  with  descriptive
       information  about  the	domain followed by the or suffix. For example,
       the master database files for the redwood.forest.com  domain  might  be
       called  redwood.db and redwood.rev to differentiate them from files for
       other domains.

       The master database consists of	control	 information  and  a  list  of
       resource	 records for objects in the zone of the forms: $INCLUDE <file‐
       name> <opt_domain> $ORIGIN <domain> $TTL <def_ttl>  <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
       origin  is appended to the domain. Domain names ending with are unmodi‐
       fied.

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

       The def_ttl field is an value for the default time-to-live.  It	speci‐
       fies how long data will be stored in the cache.	The value can be spec‐
       ified in seconds or in the following format, where you need not specify
       all of the fields: weeksWdaysDhoursHminutesMsecondsS

       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  particular  resource	record	or  its corresponding SOA record.  The
       def_ttl value must be in the range of 0 to 2147483647 seconds. The max‐
       imum  in	 the  alternative  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 host address
       (dotted quad IP address) an authoritative name server (domain)  a  mail
       exchanger  (domain),  preceded  by  a preference value (0-32767, inclu‐
       sive), with lower numeric values representing  higher  logical  prefer‐
       ences.	the  canonical name for an alias (domain) marks the start of a
       zone of authority (domain of originating host, domain address of	 main‐
       tainer,	a  serial  number,  and	 the  following parameters in seconds:
       refresh, retry, expire and minimum TTL (see RFC883))  a	null  resource
       record  (no  format  or data) a Responsible Person for some domain name
       (mailbox, TXT-referral) a domain name pointer (domain) 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.

       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 num‐
       ber 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  sec‐
       ondary  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 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  situations, especially when then local nameserver did not have com‐
       plete information.

   Signals
       In routine operation, signals should not be used to control  the	 name‐
       server;	rndc  should  be  used instead.	 Force a reload of the server.
       Shut down the server.  The result of sending any other signals  to  the
       server is undefined.

SEE ALSO
       rndc(8), lwresd(1),

       Specifications: RFC 1033, RFC 1034, RFC 1035

       Network	Administration: Services, BIND 9 Administrator	Reference Man‐
       ual

								      named(8)
[top]

List of man pages available for DigitalUNIX

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