1nsd.conf(5) BSD File Formats Manual nsd.conf(5)
2
4 nsd.conf — NSD configuration file.
5
7 nsd.conf
8
10 nsd.conf is used to configure nsd(8). The file format has attributes and
11 values. Some attributes have attributes inside them. The notation is:
12 attribute: value.
13
14 Comments start with # and last to the end of line. Empty lines are
15 ignored as is whitespace at the beginning of a line.
16
17 nsd.conf specifies options for the nsd server, zone files, primaries and
18 secondaries.
19
21 An example of a short nsd.conf file is below.
22
23 # Example.com nsd.conf file
24 # This is a comment.
25 server:
26 database: "/etc/nsd/nsd.db"
27 username: nsd
28 logfile: "/var/log/nsd.log"
29 pidfile: "/var/run/nsd.pid"
30 difffile: "/var/nsd/ixfr.db"
31 xfrdfile: "/var/nsd/xfrd.state"
32
33 zone:
34 name: example.com
35 # note that quotes are optional on the value
36 zonefile: /etc/nsd/example.com.zone
37
38
40 There must be whitespace between keywords. Attribute keywords end with a
41 colon ':'. An attribute is followed by its containing attributes, or a
42 value.
43
44 At the top level only server: or zone: or key: are allowed. These are
45 followed by their attributes or the start of a new server: or zone: or
46 key: clause. The zone: attribute is followed by zone options. The
47 server: attribute is followed by global options for the NSD server. A
48 key: attribute is used to define keys for authentication.
49
50
51 Files can be included using the include: directive. It can appear any‐
52 where, and takes a single filename as an argument. Processing continues
53 as if the text from the included file was copied into the config file at
54 that point.
55
56
57 Server Options
58 The global options (if not overridden from the NSD commandline) are taken
59 from the server: clause. There may only be one server: clause.
60
61
62 ip-address: <ip4 or ip6>
63 NSD will bind to the listed ip-address. Can be give multiple
64 times to bind multiple ip-addresses. If none are given NSD lis‐
65 tens to all IP addresses. Same as commandline option -a.
66
67 debug-mode: <yes or no>
68 Turns on debugging mode for nsd, does not fork a daemon process.
69 Default is no. Same as commandline option -d.
70
71 ip4-only: <yes or no>
72 If yes, NSD only listens to IPv4 connections. Same as commandline
73 option -4.
74
75 ip6-only: <yes or no>
76 If yes, NSD only listens to IPv6 connections. Same as commandline
77 option -6.
78
79 database: <filename>
80 By default '/etc/nsd/nsd.db' is used. The specified file is used
81 to store the compiled zone information. Same as commandline
82 option -f.
83
84 identity: <string>
85 Returns the specified identity when asked for CH TXT ID.SERVER.
86 Default is the name as returned by gethostname(3). Same as com‐
87 mandline option -i.
88
89 logfile: <filename>
90 Log messages to the logfile. The default is to log to stderr and
91 syslog. Same as commandline option -l.
92
93 server-count: <number>
94 Start this many NSD servers. Default is 1. Same as commandline
95 option -N.
96
97 tcp-count: <number>
98 The maximum number of concurrent TCP connections by each server.
99 Default is 10. Same as commandline option -n.
100
101 pidfile: <filename>
102 Use the pid file instead of the platform specific default, usu‐
103 ally /var/run/nsd.pid. Same as commandline option -P.
104
105 port: <number>
106 Answer queries on the specified port. Default is 53. Same as com‐
107 mandline option -p.
108
109 statistics: <number>
110 If not present no statistics are dumped. Statistics are produced
111 every number seconds. Same as commandline option -s.
112
113 chroot: <directory>
114 NSD will chroot on startup to the specified directory. Same as
115 commandline option -t.
116
117 username: <username>
118 After binding the socket, drop user privileges and assume the
119 username. Can be username, id or id.gid. Same as commandline
120 option -u.
121
122 zonesdir: <directory>
123 Change the working directory to the specified directory before
124 accessing zone files. Same as commandline option -d for
125 zonec(8). Also nsd(8) will access files (pid file, database
126 file, log file) relative to this directory. Set the value to ""
127 (the empty string) to disable the change of working directory.
128
129 difffile: <filename>
130 When NSD receives IXFR updates it will store them in this file.
131 This file contains the differences between the database file and
132 the latest zone version. Default is /etc/nsd/ixfr.db.
133
134 xfrdfile: <filename>
135 The soa timeout and zone transfer daemon in NSD will save its
136 state to this file. State is read back after a restart. The state
137 file can be deleted without too much harm, but timestamps of
138 zones will be gone. For more details see the section on zone
139 expiry behavior of NSD. Default is /etc/nsd/xfrd.state.
140
141 xfrd-reload-timeout: <number>
142 If this value is -1 xfrd will not trigger a reload after a zone
143 transfer. If positive xfrd will trigger a reload after a zone
144 transfer, and then wait for the number of seconds before it will
145 trigger a new reload. Setting this value throttles the reloads
146 to once per the number of seconds. The default is 10 seconds.
147
148 verbosity: <level>
149 This value specifies the verbosity level for (non-debug) logging.
150 Default is 0.
151
152
153 Zone Options
154 For every zone the options need to be specified in one zone: clause. The
155 access control list elements can be given multiple times to add multiple
156 servers.
157
158 name: <string>
159 The name of the zone. This is the domain name of the apex of the
160 zone. May end with a '.' (in FQDN notation). For example "exam‐
161 ple.com", "sub.example.net.". This attribute must be present in
162 each zone.
163
164 zonefile: <filename>
165 The file containing the zone information. This file is used by
166 zonec(8). This attribute must be present in each zone.
167
168 allow-notify: <ip-spec> <key-name | NOKEY | BLOCKED>
169 Access control list. The listed (primary) address is allowed to
170 send notifies to this (secondary) server. Notifies from unlisted
171 or specifically BLOCKED addresses are discarded. If NOKEY is
172 given no TSIG signature is required.
173
174 The ip-spec is either a plain IP address (IPv4 or IPv6), or can
175 be a subnet of the form 1.2.3.4/24, or masked like
176 1.2.3.4&255.255.255.0 or a range of the form 1.2.3.4-1.2.3.25. A
177 port number can be added using a suffix of @number, for example
178 1.2.3.4@5300 or 1.2.3.4/24@5300 for port 5300. Note the ip-spec
179 ranges do not use spaces around the /, &, @ and - symbols.
180
181 request-xfr: [AXFR] <ip-address> <key-name | NOKEY>
182 Access control list. The listed address (the master) is queried
183 for AXFR/IXFR on update. The specified key is used during
184 AXFR/IXFR.
185
186 If the AXFR option is given, the server will not be contacted
187 with IXFR queries but only AXFR requests will be made to the
188 server. This allows an NSD secondary to have a master server that
189 runs NSD. If the AXFR option is left out then both IXFR and AXFR
190 requests are made to the master server.
191
192 notify: <ip-address> <key-name | NOKEY>
193 Access control list. The listed address (a secondary) is notified
194 of updates to this zone. The specified key is used to sign the
195 notify. Only on secondary configurations will NSD be able to
196 detect zone updates (as it gets notified itself, or refreshes
197 after a time).
198
199 provide-xfr: <ip-spec> <key-name | NOKEY | BLOCKED>
200 Access control list. The listed address (a secondary) is allowed
201 to request AXFR from this server. Zone data will be provided to
202 the address. The specified key is used during AXFR. For
203 unlisted or BLOCKED addresses no data is provided, requests are
204 discarded.
205
206 The ip-spec is either a plain IP address (IPv4 or IPv6), or can
207 be a subnet of the form 1.2.3.4/24, or masked like
208 1.2.3.4&255.255.255.0 or a range of the form 1.2.3.4-1.2.3.25. A
209 port number can be added using a suffix of @number, for example
210 1.2.3.4@5300 or 1.2.3.4/24@5300 for port 5300. Note the ip-spec
211 ranges do not use spaces around the /, &, @ and - symbols.
212
213 Key Declarations
214 The key: clause establishes a key for use in access control lists. It
215 has the following attributes.
216
217 name: <string>
218 The key name. Used to refer to this key in the access control
219 list.
220
221 algorithm: <string>
222 Authentication algorithm for this key.
223
224 secret: <base64 blob>
225 The base64 encoded shared secret. It is possible to put the
226 secret: declaration (and base64 blob) into a different file, and
227 then to include: that file. In this way the key secret and the
228 rest of the configuration file, which may have different security
229 policies, can be split apart.
230
232 BIND9 is a name server implementation with its own configuration file
233 format, named.conf(5). BIND9 types zones as 'Master' or 'Slave'.
234
235
236 Slave zones
237 For a slave zone, the master servers are listed. The master servers are
238 queried for zone data, and are listened to for update notifications. In
239 NSD these two properties need to be configured seperately, by listing the
240 master address in allow-notify and request-xfr statements.
241
242 In BIND9 you only need to provide allow-notify elements for any extra
243 sources of notifications (i.e. the operators), NSD needs to have allow-
244 notify for both masters and operators. BIND9 allows additional transfer
245 sources, in NSD you list those as request-xfr.
246
247 Here is an example of a slave zone in BIND9 syntax.
248
249 # Config file for example.org
250 options {
251 dnssec-enable yes;
252 };
253
254 key tsig.example.org. {
255 algorithm hmac-md5;
256 secret "aaaaaabbbbbbccccccdddddd";
257 };
258
259 server 162.0.4.49 {
260 keys { tsig.example.org. ; };
261 };
262
263 zone "example.org" {
264 type slave;
265 file "secondary/example.org.signed";
266 masters { 162.0.4.49; };
267 };
268
269 For NSD, DNSSEC is enabled automatically for zones that are signed. The
270 dnssec-enable statement in the options clause is not needed. In NSD keys
271 are associated with an IP address in the access control list statement,
272 therefore the server{} statement is not needed. Below is the same example
273 in an NSD config file.
274
275 # Config file for example.org
276 key:
277 name: tsig.example.org.
278 algorithm: hmac-md5
279 secret: "aaaaaabbbbbbccccccdddddd"
280
281 zone:
282 name: "example.org"
283 zonefile: "secondary/example.org.signed"
284 # the master is allowed to notify and will provide zone data.
285 allow-notify: 162.0.4.49 NOKEY
286 request-xfr: 162.0.4.49 tsig.example.org.
287
288 Notice that the master is listed twice, once to allow it to send notifies
289 to this slave server and once to tell the slave server where to look for
290 updates zone data. More allow-notify and request-xfr lines can be added
291 to specify more masters.
292
293 It is possible to specify extra allow-notify lines for addresses that are
294 also allowed to send notifications to this slave server.
295
296
297 Master zones
298 For a master zone in BIND9, the slave servers are listed. These slave
299 servers are sent notifications of updated and are allowed to request
300 transfer of the zone data. In NSD these two properties need to be config‐
301 ured seperately.
302
303 Here is an example of a master zone in BIND9 syntax.
304
305 zone "example.nl" {
306 type master;
307 file "example.nl";
308 };
309
310 In NSD syntax this becomes:
311
312 zone:
313 name: "example.nl"
314 zonefile: "example.nl"
315 # allow anybody to request xfr.
316 provide-xfr: 0/0 NOKEY
317
318 # to list a slave server you would in general give
319 # provide-xfr: 1.2.3.4 tsig-key.name.
320 # notify: 1.2.3.4 NOKEY
321
322
323 Other
324 NSD is an authoritative only DNS server. This means that it is meant as a
325 primary or secondary server for zones, providing DNS data to DNS
326 resolvers and caches. BIND9 can function as an authoritative DNS server,
327 the configuration options for that are compared with those for NSD in
328 this section. However, BIND9 can also function as a resolver or cache.
329 The configuration options that BIND9 has for the resolver or caching thus
330 have no equivalents for NSD.
331
332
334 /etc/nsd/nsd.db
335 default NSD database
336
337 /etc/nsd/nsd.conf
338 default NSD configuration file
339
341 nsd(8), nsd-checkconf(8), nsd-notify(8), nsd-patch(8), nsd-xfer(8),
342 nsdc(8), zonec(8)
343
345 NSD was written by NLnet Labs and RIPE NCC joint team. Please see CREDITS
346 file in the distribution for further details.
347
349 nsd.conf is parsed by a primitive parser, error messages may not be to
350 the point.
351
352FreeBSD Sep 7, 2007 FreeBSD