1nsd.conf(5) nsd 3.2.8 nsd.conf(5)
2
6 nsd.conf - NSD configuration file
7
9 nsd.conf
10
12 Nsd.conf is used to configure nsd(8). The file format has attributes
13 and values. Some attributes have attributes inside them. The notation
14 is: attribute: value.
15 Comments start with # and last to the end of line. Empty lines are
17 ignored as is whitespace at the beginning of a line.
18 Nsd.conf specifies options for the nsd server, zone files, primaries
20 and secondaries.
21
23 An example of a short nsd.conf file is below.
24 # Example.com nsd.conf file
26 # This is a comment.
27 server:
29 database: "/var/lib/nsd/nsd.db"
30 username: nsd
31 logfile: "/var/log/nsd.log"
32 pidfile: "/var/run/nsd/nsd.pid"
33 difffile: "/var/lib/nsd/ixfr.db"
34 xfrdfile: "/var/lib/nsd/ixfr.state"
35 zone:
37 name: example.com
38 # note that quotes are optional on the value
39 zonefile: /etc/nsd/example.com.zone
40
42 There must be whitespace between keywords. Attribute keywords end with
43 a colon ':'. An attribute is followed by its containing attributes, or
44 a value.
45 At the top level only server: or zone: or key: are allowed. These are
47 followed by their attributes or the start of a new server: or zone: or
48 key: clause. The zone: attribute is followed by zone options. The
49 server: attribute is followed by global options for the NSD server. A
50 key: attribute is used to define keys for authentication.
51 Files can be included using the include: directive. It can appear any‐
53 where, and takes a single filename as an argument. Processing continues
54 as if the text from the included file was copied into the config file
55 at that point. .LP The global options (if not overridden from the NSD
56 commandline) are taken from the server: clause. There may only be one
57 server: clause.
58 ip-address: <ip4 or ip6>[@port]
60 NSD will bind to the listed ip-address. Can be give multiple
61 times to bind multiple ip-addresses. Optionally, a port number
62 can be given. If none are given NSD listens to the wildcard
63 interface. Same as commandline option -a.
64 debug-mode: <yes or no>
66 Turns on debugging mode for nsd, does not fork a daemon process.
67 Default is no. Same as commandline option -d.
68 ip4-only: <yes or no>
70 If yes, NSD only listens to IPv4 connections. Same as command‐
71 line option -4.
72 ip6-only: <yes or no>
74 If yes, NSD only listens to IPv6 connections. Same as command‐
75 line option -6.
76 database: <filename>
78 By default /var/lib/nsd/nsd.db is used. The specified file is
79 used to store the compiled zone information. Same as commandline
80 option -f.
81 identity: <string>
83 Returns the specified identity when asked for CH TXT ID.SERVER.
84 Default is the name as returned by gethostname(3). Same as com‐
85 mandline option -i.
86 nsid: <string>
88 Add the specified nsid to the EDNS section of the answer when
89 queried with an NSID EDNS enabled packet. Same as commandline
90 option -I.
91 logfile: <filename>
93 Log messages to the logfile. The default is to log to stderr and
94 syslog (with facility LOG_DAEMON). Same as commandline option
95 -l.
96 server-count: <number>
98 Start this many NSD servers. Default is 1. Same as commandline
99 option -N.
100 tcp-count: <number>
102 The maximum number of concurrent, active TCP connections by each
103 server. Default is 10. This option should have a value below
104 1000. Same as commandline option -n.
105 tcp-query-count: <number>
107 The maximum number of queries served on a single TCP connection.
108 Default is 0, meaning there is no maximum.
109 tcp-timeout: <number>
111 Overrides the default TCP timeout. This also affects zone trans‐
112 fers over TCP.
113 ipv4-edns-size: <number>
115 Preferred EDNS buffer size for IPv4.
116 ipv6-edns-size: <number>
118 Preferred EDNS buffer size for IPv6.
119 pidfile: <filename>
121 Use the pid file instead of the platform specific default, usu‐
122 ally /var/run/nsd/nsd.pid. Same as commandline option -P.
123 port: <number>
125 Answer queries on the specified port. Default is 53. Same as
126 commandline option -p.
127 statistics: <number>
129 If not present no statistics are dumped. Statistics are produced
130 every number seconds. Same as commandline option -s.
131 chroot: <directory>
133 NSD will chroot on startup to the specified directory. Same as
134 commandline option -t.
135 username: <username>
137 After binding the socket, drop user privileges and assume the
138 username. Can be username, id or id.gid. Same as commandline
139 option -u.
140 zonesdir: <directory>
142 Change the working directory to the specified directory before
143 accessing zone files. Same as commandline option -d for
144 zonec(8). Also nsd(8) will access files (pid file, database
145 file, log file) relative to this directory. Set the value to ""
146 (the empty string) to disable the change of working directory.
147 difffile: <filename>
149 When NSD receives IXFR updates it will store them in this file.
150 This file contains the differences between the database file and
151 the latest zone version. Default is /var/lib/nsd/ixfr.db.
152 xfrdfile: <filename>
154 The soa timeout and zone transfer daemon in NSD will save its
155 state to this file. State is read back after a restart. The
156 state file can be deleted without too much harm, but timestamps
157 of zones will be gone. For more details see the section on zone
158 expiry behavior of NSD. Default is /var/lib/nsd/ixfr.state.
159 xrfd-reload-timeout: <number>
161 If this value is -1, xfrd will not trigger a reload after a zone
162 transfer. If positive xfrd will trigger a reload after a zone
163 transfer, then it will wait for the number of seconds before it
164 will trigger a new reload. Setting this value throttles the
165 reloads to once per the number of seconds. The default is 10
166 seconds.
167 verbosity: <level>
169 This value specifies the verbosity level for (non-debug) log‐
170 ging. Default is 0. 1 gives more information about incoming
171 notifies and zone transfers. 2 lists soft warnings that are
172 encountered.
173 hide-version: <yes or no>
175 Prevent NSD from replying with the version string on CHAOS class
176 queries.
177 Zone Options
179 For every zone the options need to be specified in one zone: clause.
180 The access control list elements can be given multiple times to add
181 multiple servers. These elements need to be added explicitly.
182 name: <string>
184 The name of the zone. This is the domain name of the apex of the
185 zone. May end with a '.' (in FQDN notation). For example "exam‐
186 ple.com", "sub.example.net.". This attribute must be present in
187 each zone.
188 zonefile: <filename>
190 The file containing the zone information. This file is used by
191 zonec(8). This attribute must be present in each zone.
192 allow-notify: <ip-spec> <key-name | NOKEY | BLOCKED>
194 Access control list. The listed (primary) address is allowed to
195 send notifies to this (secondary) server. Notifies from unlisted
196 or specifically BLOCKED addresses are discarded. If NOKEY is
197 given no TSIG signature is required.
198 The ip-spec is either a plain IP address (IPv4 or IPv6), or can
200 be a subnet of the form 1.2.3.4/24, or masked like
201 1.2.3.4&255.255.255.0 or a range of the form 1.2.3.4-1.2.3.25.
202 A port number can be added using a suffix of @number, for exam‐
203 ple 1.2.3.4@5300 or 1.2.3.4/24@5300 for port 5300. Note the
204 ip-spec ranges do not use spaces around the /, &, @ and - sym‐
205 bols.
206 request-xfr: [AXFR|UDP] <ip-address> <key-name | NOKEY>
208 Access control list. The listed address (the master) is queried
209 for AXFR/IXFR on update. A port number can be added using a suf‐
210 fix of @number, for example 1.2.3.4@5300. The specified key is
211 used during AXFR/IXFR.
212 If the AXFR option is given, the server will not be contacted
214 with IXFR queries but only AXFR requests will be made to the
215 server. This allows an NSD secondary to have a master server
216 that runs NSD. If the AXFR option is left out then both IXFR and
217 AXFR requests are made to the master server.
218 If the UDP option is given, the secondary will use UDP to trans‐
220 mit the IXFR requests. You should deploy TSIG when allowing UDP
221 transport, to authenticate notifies and zone transfers. Other‐
222 wise, NSD is more vulnerable for Kaminsky-style attacks. If the
223 UDP option is left out then IXFR will be transmitted using TCP.
224 allow-axfr-fallback: <yes or no>
226 This option should be accompanied by request-xfr. It (dis)allows
227 NSD (as secondary) to fallback to AXFR if the primary name
228 server does not support IXFR. Default is yes.
229 notify: <ip-address> <key-name | NOKEY>
231 Access control list. The listed address (a secondary) is noti‐
232 fied of updates to this zone. A port number can be added using a
233 suffix of @number, for example 1.2.3.4@5300. The specified key
234 is used to sign the notify. Only on secondary configurations
235 will NSD be able to detect zone updates (as it gets notified
236 itself, or refreshes after a time).
237 notify-retry: <number>
239 This option should be accompanied by notify. It sets the number
240 of retries when sending notifies.
241 provide-xfr: <ip-spec> <key-name | NOKEY | BLOCKED>
243 Access control list. The listed address (a secondary) is allowed
244 to request AXFR from this server. Zone data will be provided to
245 the address. The specified key is used during AXFR. For unlisted
246 or BLOCKED addresses no data is provided, requests are dis‐
247 carded.
248 The ip-spec is either a plain IP address (IPv4 or IPv6), or can
250 be a subnet of the form 1.2.3.4/24, or masked like
251 1.2.3.4&255.255.255.0 or a range of the form 1.2.3.4-1.2.3.25.
252 A port number can be added using a suffix of @number, for exam‐
253 ple 1.2.3.4@5300 or 1.2.3.4/24@5300 for port 5300. Note the
254 ip-spec ranges do not use spaces around the /, &, @ and - sym‐
255 bols.
256 outgoing-interface: <ip-address>
258 Access control list. The listed address is used to request
259 AXFR|IXFR (in case of a secondary) or used to send notifies (in
260 case of a primary).
261 The ip-address is a plain IP address (IPv4 or IPv6). A port
263 number can be added using a suffix of @number, for example
264 1.2.3.4@5300.
265 Key Declarations
267 The key: clause establishes a key for use in access control lists. It
268 has the following attributes.
269 name: <string>
271 The key name. Used to refer to this key in the access control
272 list.
273 algorithm: <string>
275 Authentication algorithm for this key.
276 secret: <base64 blob>
278 The base64 encoded shared secret. It is possible to put the
279 secret: declaration (and base64 blob) into a different file, and
280 then to include: that file. In this way the key secret and the
281 rest of the configuration file, which may have different secu‐
282 rity policies, can be split apart.
283
285 BIND9 is a name server implementation with its own configuration file
286 format, named.conf(5). BIND9 types zones as 'Master' or 'Slave'.
287 Slave zones
289 For a slave zone, the master servers are listed. The master servers are
290 queried for zone data, and are listened to for update notifications.
291 In NSD these two properties need to be configured seperately, by list‐
292 ing the master address in allow-notify and request-xfr statements.
293 In BIND9 you only need to provide allow-notify elements for any extra
295 sources of notifications (i.e. the operators), NSD needs to have
296 allow-notify for both masters and operators. BIND9 allows additional
297 transfer sources, in NSD you list those as request-xfr.
298 Here is an example of a slave zone in BIND9 syntax.
300 # Config file for example.org options {
302 dnssec-enable yes;
303 };
304 key tsig.example.org. {
306 algorithm hmac-md5;
307 secret "aaaaaabbbbbbccccccdddddd";
308 };
309 server 162.0.4.49 {
311 keys { tsig.example.org. ; };
312 };
313 zone "example.org" {
315 type slave;
316 file "secondary/example.org.signed";
317 masters { 162.0.4.49; };
318 };
319 For NSD, DNSSEC is enabled automatically for zones that are signed. The
321 dnssec-enable statement in the options clause is not needed. In NSD
322 keys are associated with an IP address in the access control list
323 statement, therefore the server{} statement is not needed. Below is the
324 same example in an NSD config file.
325 # Config file for example.org
327 key:
328 name: tsig.example.org.
329 algorithm: hmac-md5
330 secret: "aaaaaabbbbbbccccccdddddd"
331 zone:
333 name: "example.org"
334 zonefile: "secondary/example.org.signed"
335 # the master is allowed to notify and will provide zone data.
336 allow-notify: 162.0.4.49 NOKEY
337 request-xfr: 162.0.4.49 tsig.example.org.
338 Notice that the master is listed twice, once to allow it to send noti‐
340 fies to this slave server and once to tell the slave server where to
341 look for updates zone data. More allow-notify and request-xfr lines can
342 be added to specify more masters.
343 It is possible to specify extra allow-notify lines for addresses that
345 are also allowed to send notifications to this slave server.
346 Master zones
348 For a master zone in BIND9, the slave servers are listed. These slave
349 servers are sent notifications of updated and are allowed to request
350 transfer of the zone data. In NSD these two properties need to be con‐
351 figured seperately.
352 Here is an example of a master zone in BIND9 syntax.
354 zone "example.nl" {
356 type master;
357 file "example.nl";
358 };
359 In NSD syntax this becomes:
361 zone:
363 name: "example.nl"
364 zonefile: "example.nl"
365 # allow anybody to request xfr.
366 provide-xfr: 0.0.0.0/0 NOKEY
367 provide-xfr: ::0/0 NOKEY
368 # to list a slave server you would in general give
370 # provide-xfr: 1.2.3.4 tsig-key.name.
371 # notify: 1.2.3.4 NOKEY
372 Other
374 NSD is an authoritative only DNS server. This means that it is meant as
375 a primary or secondary server for zones, providing DNS data to DNS
376 resolvers and caches. BIND9 can function as an authoritative DNS
377 server, the configuration options for that are compared with those for
378 NSD in this section. However, BIND9 can also function as a resolver or
379 cache. The configuration options that BIND9 has for the resolver or
380 caching thus have no equivalents for NSD.
381
383 /var/lib/nsd/nsd.db
384 default NSD database
385 /etc/nsd/nsd.conf
387 default NSD configuration file
388
390 nsd(8), nsdc(8), nsd-checkconf(8), nsd-notify(8), nsd-patch(8), nsd-
391 xfer(8), zonec(8)
392
394 NSD was written by NLnet Labs and RIPE NCC joint team. Please see CRED‐
395 ITS file in the distribution for further details.
396
398 nsd.conf is parsed by a primitive parser, error messages may not be to
399 the point.
400NLnet Labs Mar 22, 2011 nsd.conf(5)