1nsd.conf(5)                 BSD File Formats Manual                nsd.conf(5)
2

NAME

4     nsd.conf — NSD configuration file.
5

SYNOPSIS

7     nsd.conf
8

DESCRIPTION

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

EXAMPLE

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

FILE FORMAT

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

NSD CONFIGURATION FOR BIND9 HACKERS

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

FILES

334     /etc/nsd/nsd.db
335             default NSD database
336
337     /etc/nsd/nsd.conf
338             default NSD configuration file
339

SEE ALSO

341     nsd(8), nsd-checkconf(8), nsd-notify(8), nsd-patch(8), nsd-xfer(8),
342     nsdc(8), zonec(8)
343

AUTHORS

345     NSD was written by NLnet Labs and RIPE NCC joint team. Please see CREDITS
346     file in the distribution for further details.
347

BUGS

349     nsd.conf is parsed by a primitive parser, error messages may not be to
350     the point.
351
352FreeBSD                           Sep 7, 2007                          FreeBSD
Impressum