*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->IRIX man pages -> named (1)              


named(1M)							     named(1M)

NAME    [Toc]    [Back]

     named, named-xfer - internet domain name server (DNS)

SYNOPSIS    [Toc]    [Back]

     named [-d debuglevel] [-q]	[-r] [-p remote/local] [{-b} bootfile]

DESCRIPTION    [Toc]    [Back]

     named is the Internet domain name server.	It replaces the	original host
     table lookup of information in the	network	hosts file /etc/hosts.	(See
     RFC1034 for more information on the Internet name-domain system.)
     named-xfer	is invoked by named to transfer	zone data from primary

     named is started at system	initialization if the configuration flag named
     is	set on with chkconfig(1M).  Without any	arguments, named reads the
     default boot file /etc/named.boot,	read any initial data and listen for

     Site-dependent options and	arguments to named belong in the file
     /etc/config/named.options.	 Options are:

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

     -q	  Print	all sorts of query log information.  Used only for debugging.

     -p	  Use a	different port number.	The default is the standard port
	  number as listed in /etc/services, number 53.	 The first port	number
	  given	is the one to which we send queries.  The second port number
	  (after the slash) is the one on which	we listen.  If only one	is
	  given	without	a slash, that number is	used for both sending and

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

     -r	  Turns	recursion off in the server.  Answers can come only from local
	  (primary or secondary) zones.	 This can be used on root servers.
	  NOTE:	this option is deprecated in favour of the boot	file directive
	  ``options no-recursion''.

     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:
     directory /var/named
     ; type	 domain			source host/file	    backup file

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

									Page 1

named(1M)							     named(1M)

     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
     limit	 transfers-in 10
     limit	 datasize 64M
     options	 forward-only query-log	fake-iquery
     check-names primary fail
     check-names secondary warn
     check-names response ignore

     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 ``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 RFC 883.  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  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 transferred 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.  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 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.

									Page 2

named(1M)							     named(1M)

     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 ``forwardonly''
 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 direct access	to the Internet, but wish to look up exterior names

     The ``slave'' line	(deprecated) is	allowed	for backward compatibility.
     Its meaning is identical to ``options forward-only''.

     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

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

     The ``include'' directive (not shown) can be used to process 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 people.  The
     ``include'' directive takes one argument, that being the name of the file
     whose contents are	to be 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 ``limit'' directive can be used to change BIND's internal limits,
     some of which (datasize, for example) are implemented by the system and
     others (like transfers-in)	by BIND	itself.	 The number following the
     limit name	can be scaled by postfixing a ``k,'' ``m,'' or ``g'' for
     kilobytes,	megabytes, and gigabytes respectively.	datasize's argument
     sets the process data size	enforced by the	kernel.	 Note: not all systems
     provide a call to implement this -- on such systems, the use of the
     datasize parameter	of ``limit'' will result in a warning message.
     transfers-in's argument is	the number of named-xfer subprocesses which
     BIND will spawn at	any one	time.  transfers-per-ns's argument is the

									Page 3

named(1M)							     named(1M)

     maximum number of zone transfers to be simultaneously initiated to	any
     given remote name server.

     The ``options'' directive introduces a boolean specifier that changes the
     behaviour of BIND.	 More than one option can be specified in a single
     directive.	 The currently defined options are as follows:	no-recursion,
     which will	cause BIND to answer with a referral rather than actual	data
     whenever it receives a query for a	name it	is not authoritative for --
     don't set this on a server	that is	listed in any host's resolv.conf file;
     no-fetch-glue, which keeps	BIND from fetching missing glue	when
     constructing the ``additional data'' section of a response; this can be
     used in conjunction with no-recursion to prevent BIND's cache from	ever
     growing in	size or	becoming corrupted; query-log, which causes all
     queries to	be logged via syslog(@SYS_OPS_EXT@) -- this is a lot of	data,
     don't turn	it on lightly; forward-only, which causes the server to	query
     only its forwarders -- this option	is normally used on machine that
     wishes to run a server but	for physical or	administrative reasons cannot
     be	given access to	the Internet; and fake-iquery, which tells BIND	to
     send back a useless and bogus reply to ``inverse queries''	rather than
     responding	with an	error.

     The ``check-names'' directive tells BIND to check names in	either
     ``primary'' or ``secondary'' zone files, or in messages (``response'')
     received during recursion (for example, those which would be forwarded
     back to a firewalled requestor).  For each	type of	name, BIND can be told
     to	``fail'', such that a zone would not be	loaded or a response would not
     be	cached or forwarded, or	merely ``warn''	which would cause a message to
     be	emitted	in the system operations logs, or to ``ignore''	the badness of
     a name and	process	it in the traditional fashion.	Names are considered
     good if they match	RFC 952's expectations (if they	are host names), or if
     they consist only of printable ASCII characters (if they are not host

     The ``max-fetch'' directive (not shown) is	allowed	for backward
     compatibility; its	meaning	is identical to	``limit	transfers-in''.

     The ``transfer'' directive	(not shown) defines a alternate	transfer
     program (other than named-xfer) to	be used	for a specific domain.	This
     directive implements RFC1794.   Use of the	transfer directive disables
     ALL record	reordering for all domains being serviced by (this) named.
     Use of this option	should be used with care.  To use transfer, named.boot
     will have a transfer and secondary	pair of	directives for each effected
     domain.  Syntax of	the paired transfer and	secondary directives looks

	  transfer <domain> <xfer-program>
	  secondary <domain> <filename>

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

									Page 4

named(1M)							     named(1M)

	  $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 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
	      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 RFC 883)).

     NULL     a	null resource record (no format	or data)

     RP	      a	Responsible Person for some domain name	(mailbox, TXTreferral)

     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.

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

									Page 5

named(1M)							     named(1M)

	  @    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 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-tolive
 used by records in the file with	no explicit time-to-live

NOTES    [Toc]    [Back]

     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 nameserver did not have
     complete information.

     The following signals have	the specified effect when sent to the server
     process using the kill(1) or killall(1M) commands.

     SIGHUP    Causes server to	read named.boot	and reload the database.

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

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

     SIGUSR1   Turns on	debugging; each	SIGUSR1	increments debug level.

     SIGUSR2   Turns off debugging completely.

     The shell script /usr/sbin/named.reload sends a SIGHUP to the server.
     /usr/sbin/named.restart kills and restarts	the server.

									Page 6

named(1M)							     named(1M)

FILES    [Toc]    [Back]

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

SEE ALSO    [Toc]    [Back]

     kill(1), gethostbyname(3N), resolver(3N), resolv.conf(4), hostname(5).

     IRIX Admin: Networking and	Mail

     RFC1032, RFC1033, RFC1034,	RFC1035, RFC974	This version is	based on the
     BIND 4.9.4	patchlevel 1 release from Paul Vixie.

									PPPPaaaaggggeeee 7777
[ Back ]
 Similar pages
Name OS Title
named OpenBSD Internet domain name server
named HP-UX Internet domain name server
res_init Tru64 Search for a default domain name and Internet address
bind_intro Tru64 Introduction to the Berkeley Internet Name Domain (BIND) service
whois FreeBSD Internet domain name and network number directory service
whois OpenBSD Internet domain name and network number directory service
bind_manual_setup Tru64 Describes how to manually set up the Berkeley Internet Name Domain (BIND) service on your network.
sig_named HP-UX send signals to the domain name server
host FreeBSD look up host names using domain server
res_query Tru64 Query a domain server and check the response
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service