1NAMED(8) System Manager's Manual NAMED(8)
2
6 named - Internet domain name server
7
9 named [ -d debuglevel ] [ -p port# ] [{-b} bootfile ]
10
12 Named is the Internet domain name server. See RFC883 for more informa‐
13 tion on the Internet name-domain system. Without any arguments, named
14 will read the default boot file /etc/named.boot, read any initial data
15 and listen for queries.
16 Options are:
18 -d Print debugging information. A number after the ``d'' deter‐
20 mines the level of messages printed.
21 -p Use a different port number. The default is the standard port
23 number as listed in /etc/services.
24 -b Use an alternate boot file. This is optional and allows you to
26 specify a file with a leading dash.
27 Any additional argument is taken as the name of the boot file. The
29 boot file contains information about where the name server is to get
30 its initial data. If multiple boot files are specified, only the last
31 is used. Lines in the boot file cannot be continued on subsequent
32 lines. The following is a small example:
33 ;
35 ; boot file for name server
36 ;
37 directory /usr/local/domain
38 ; type domain source host/file backup file
40 cache . root.cache
42 primary Berkeley.EDU berkeley.edu.zone
43 primary 32.128.IN-ADDR.ARPA ucbhosts.rev
44 secondary CC.Berkeley.EDU 128.32.137.8 128.32.137.3 cc.zone.bak
45 secondary 6.32.128.IN-ADDR.ARPA 128.32.137.8 128.32.137.3 cc.rev.bak
46 primary 0.0.127.IN-ADDR.ARPA localhost.rev
47 forwarders 10.0.0.78 10.2.0.78
48 ; slave
49 The ``directory'' line causes the server to change its working direc‐
51 tory to the directory specified. This can be important for the correct
52 processing of $INCLUDE files in primary zone files.
53 The ``cache'' line specifies that data in ``root.cache'' is to be
55 placed in the backup cache. Its main use is to specify data such as
56 locations of root domain servers. This cache is not used during normal
57 operation, but is used as ``hints'' to find the current root servers.
58 The file ``root.cache'' is in the same format as ``berkeley.edu.zone''.
59 There can be more than one ``cache'' file specified. The cache files
60 are processed in such a way as to preserve the time-to-live's of data
61 dumped out. Data for the root nameservers is kept artificially valid
62 if necessary.
63 The first ``primary'' line states that the file ``berkeley.edu.zone''
65 contains authoritative data for the ``Berkeley.EDU'' zone. The file
66 ``berkeley.edu.zone'' contains data in the master file format described
67 in RFC883. All domain names are relative to the origin, in this case,
68 ``Berkeley.EDU'' (see below for a more detailed description). The sec‐
69 ond ``primary'' line states that the file ``ucbhosts.rev'' contains
70 authoritative data for the domain ``32.128.IN-ADDR.ARPA,'' which is
71 used to translate addresses in network 128.32 to hostnames. Each mas‐
72 ter file should begin with an SOA record for the zone (see below).
73 The first ``secondary'' line specifies that all authoritative data
75 under ``CC.Berkeley.EDU'' is to be transferred from the name server at
76 128.32.137.8. If the transfer fails it will try 128.32.137.3 and con‐
77 tinue trying the addresses, up to 10, listed on this line. The sec‐
78 ondary copy is also authoritative for the specified domain. The first
79 non-dotted-quad address on this line will be taken as a filename in
80 which to backup the transfered zone. The name server will load the
81 zone from this backup file if it exists when it boots, providing a com‐
82 plete copy even if the master servers are unreachable. Whenever a new
83 copy of the domain is received by automatic zone transfer from one of
84 the master servers, this file will be updated. The second ``sec‐
85 ondary'' line states that the address-to-hostname mapping for the sub‐
86 net 128.32.136 should be obtained from the same list of master servers
87 as the previous zone.
88 The ``forwarders'' line specifies the addresses of sitewide servers
90 that will accept recursive queries from other servers. If the boot
91 file specifies one or more forwarders, then the server will send all
92 queries for data not in the cache to the forwarders first. Each for‐
93 warder will be asked in turn until an answer is returned or the list is
94 exhausted. If no answer is forthcoming from a forwarder, the server
95 will continue as it would have without the forwarders line unless it is
96 in ``slave'' mode. The forwarding facility is useful to cause a large
97 sitewide cache to be generated on a master, and to reduce traffic over
98 links to outside servers. It can also be used to allow servers to run
99 that do not have access directly to the Internet, but wish to act as
100 though they do.
101 The ``slave'' line (shown commented out) is used to put the server in
103 slave mode. In this mode, the server will only make queries to for‐
104 warders. This option is normally used on machine that wish to run a
105 server but for physical or administrative reasons cannot be given
106 access to the Internet, but have access to a host that does have
107 access.
108 The ``sortlist'' line can be used to indicate networks that are to be
110 preferred over other, unlisted networks. Queries for host addresses
111 from hosts on the same network as the server will receive responses
112 with local network addresses listed first, then addresses on the sort
113 list, then other addresses. This line is only acted on at initial
114 startup. When reloading the nameserver with a SIGHUP, this line will
115 be ignored.
116 The master file consists of control information and a list of resource
118 records for objects in the zone of the forms:
119 $INCLUDE <filename> <opt_domain>
121 $ORIGIN <domain>
122 <domain> <opt_ttl> <opt_class> <type> <resource_record_data>
123 where domain is "." for root, "@" for the current origin, or a standard
125 domain name. If domain is a standard domain name that does not end with
126 ``.'', the current origin is appended to the domain. Domain names end‐
127 ing with ``.'' are unmodified. The opt_domain field is used to define
128 an origin for the data in an included file. It is equivalent to plac‐
129 ing a $ORIGIN statement before the first line of the included file.
130 The field is optional. Neither the opt_domain field nor $ORIGIN state‐
131 ments in the included file modify the current origin for this file.
132 The opt_ttl field is an optional integer number for the time-to-live
133 field. It defaults to zero, meaning the minimum value specified in the
134 SOA record for the zone. The opt_class field is the object address
135 type; currently only one type is supported, IN, for objects connected
136 to the DARPA Internet. The type field contains one of the following
137 tokens; the data expected in the resource_record_data field is in
138 parentheses.
139 A a host address (dotted quad)
141 NS an authoritative name server (domain)
143 MX a mail exchanger (domain)
145 CNAME the canonical name for an alias (domain)
147 SOA marks the start of a zone of authority (domain of originating
149 host, domain address of maintainer, a serial number and the
150 following parameters in seconds: refresh, retry, expire and
151 minimum TTL (see RFC883))
152 MB a mailbox domain name (domain)
154 MG a mail group member (domain)
156 MR a mail rename domain name (domain)
158 NULL a null resource record (no format or data)
160 WKS a well know service description (not implemented yet)
162 PTR a domain name pointer (domain)
164 HINFO host information (cpu_type OS_type)
166 MINFO mailbox or mail list information (request_domain error_domain)
168 Resource records normally end at the end of a line, but may be contin‐
170 ued across lines between opening and closing parentheses. Comments are
171 introduced by semicolons and continue to the end of the line.
172 Each master zone file should begin with an SOA record for the zone. An
174 example SOA record is as follows:
175 @ IN SOA ucbvax.Berkeley.EDU. rwh.ucbvax.Berkeley.EDU. (
177 2.89 ; serial
178 10800 ; refresh
179 3600 ; retry
180 3600000 ; expire
181 86400 ) ; minimum
182 The SOA lists a serial number, which should be changed each time the
184 master file is changed. Secondary servers check the serial number at
185 intervals specified by the refresh time in seconds; if the serial num‐
186 ber changes, a zone transfer will be done to load the new data. If a
187 master server cannot be contacted when a refresh is due, the retry time
188 specifies the interval at which refreshes should be attempted until
189 successful. If a master server cannot be contacted within the interval
190 given by the expire time, all data from the zone is discarded by sec‐
191 ondary servers. The minimum value is the time-to-live used by records
192 in the file with no explicit time-to-live value.
193
195 The boot file directives ``domain'' and ``suffixes'' have been obso‐
196 leted by a more useful resolver based implementation of suffixing for
197 partially qualified domain names. The prior mechanisms could fail
198 under a number of situations, especially when then local nameserver did
199 not have complete information.
200 The following signals have the specified effect when sent to the server
202 process using the kill(1) command.
203 SIGHUP Causes server to read named.boot and reload database.
205 SIGINT Dumps current data base and cache to /usr/tmp/named_dump.db
207 SIGIOT Dumps statistics data into /usr/tmp/named.stats if the server is
209 compiled -DSTATS. Statistics data is appended to the file.
210 SIGSYS Dumps the profiling data in /usr/tmp if the server is compiled
212 with profiling (server forks, chdirs and exits).
213 SIGTERM
215 Dumps the primary and secondary database files. Used to save
216 modified data on shutdown if the server is compiled with dynamic
217 updating enabled.
218 SIGUSR1
220 Turns on debugging; each SIGUSR1 increments debug level.
221 (SIGEMT on older systems without SIGUSR1)
222 SIGUSR2
224 Turns off debugging completely. (SIGFPE on older systems with‐
225 out SIGUSR2)
226
228 /etc/named.boot name server configuration boot file
229 /var/run/named.pid the process id
230 /usr/tmp/named.run debug output
231 /usr/tmp/named_dump.db dump of the name server database
232 /usr/tmp/named.stats nameserver statistics data
233
235 kill(1), gethostbyname(3), signal(3), resolver(3), resolver(5), host‐
236 name(7), RFC882, RFC883, RFC973, RFC974, Name Server Operations Guide
237 for BIND
2384th Berkeley Distribution February 28, 1988 NAMED(8)