named(1M) DG/UX R4.11MU05 named(1M)
NAME
named - Internet domain name server
SYNOPSIS
named [ -d debuglevel ] [ -p port#[/localport#] ] [{-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''
determines the level of messages printed.
-p Use nonstandard port numbers. The default is the standard
port number as returned by getservbyname(3N) for service
``domain''. The argument can specify two port numbers
separated by a slash (``/'') in which case the first port is
that used when contacting the remote server and the second one
is the service port bound by the local instance of named.
This is used mostly for debugging purposes.
-b Use an alternate boot file. If bootfile is unspecified,
/etc/named.boot is used by default. Note, the '-b' must be
specified only if the alternate bootfile contains a leading
dash. Otherwise, an alternate bootfile may be specified
without the '-b'.
-q Trace all incoming queries. NOTE: we recommend using the boot
file directive ``options query-log'' instead.
-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: we recommend using the boot file directive
``options no-recursion''instead.
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:
;
; boot file for name server
;
directory /etc/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 128.32.137.8 128.32.137.3 cc.zone.bak
secondary 136.32.128.IN-ADDR.ARPA 128.32.137.8 128.32.137.3cc.rev.bak
primary 0.0.127.IN-ADDR.ARPA localhost.rev
forwarders 10.0.0.78 10.2.0.78
limit transfers-in 10
limit datasize 64M
options forward-only query-log
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 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 field after the IP address(s) 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.
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 ``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. 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 anyway.
The ``slave'' line (deprecated) is allowed for backward
compatability. Its meaning is identical to ``options forward-only''.
The ``sortlist'' line (not shown) 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 addresses.
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 that 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 that are maintained by
different people. The ``include'' directive takes one argument,
which is the name of the file whose contents are to be included. No
quotation marks are necessary around the file name.
The ``bogusns'' directive (not shown) tells the server 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 the server's internal
limits, some of which (datasize, for example) are implemented by the
system and others (like transfers-in) by the server 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. transfers-in's argument is the number of named-xfer
subprocesses that the server will spawn at any one time. transfers-
per-ns's argument is the 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 behavior of the server. More than one option can be specified in
a single directive. The currently defined options are as follows:
no-recursion, which will cause the server 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 resolve.conf file; no-fetch-glue, which keeps the server
from fetching missing glue when constructing the ``additional data''
section of a response; this can be used in conjunction with no-
recursion to prevent the server's cache from ever growing in size or
becoming corrupted; query-log, which causes all queries to be logged
via syslogd(1M) -- 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 a machine that wishes to run a server
but for physical or administrative reasons cannot be given access to
the Internet.
The ``max-fetch'' directive (not shown) is allowed for backward
comparibility; its meaning is identical to ``limit transfers-in''.
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 optttl optclass 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 optdomain 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 optdomain
field nor $ORIGIN statements in the included file modify the current
origin for this file. The optttl 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
optclass 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 resourcerecorddata 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, 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 introduced by semicolons and continue to the end of the
line.
Note that there are other resource record types, not shown here.
Consult the DNS RFC's listed in SEE ALSO section for the 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 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. 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-to-
live (``TTL'') used by records in the file with no explicit time-to-
live value.
NOTES
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.boot and reload the database.
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 the current database and cache to
/var/tmp/nameddump.db.
SIGIOT Statistics data is created (or appended) to
/var/tmp/named.stats.
SIGTERM
Terminates the server.
SIGUSR1
Turns on debugging; each SIGUSR1 increments debug level.
SIGUSR2
Turns off debugging completely.
SIGWINCH
Toggles logging of all incoming queries via syslogd(1M)
FILES
/etc/named.boot name server configuration boot file
/etc/named.pid the process id
/var/tmp/named.run debug output
/var/tmp/nameddump.db dump of the name server database
/var/tmp/named.stats nameserver statistics data
SEE ALSO
kill(1), gethostbyname(3N), signal(3C), resolver(3C),resolv.conf(4M),
hostname(1C), nslookup(1M),
RFC 882, RFC 883, RFC 973, RFC 974, RFC 1033, RFC 1034, RFC 1035, RFC
1123
Licensed material--property of copyright holder(s)