1DNSSEC-SIGNZONE(8) BIND9 DNSSEC-SIGNZONE(8)
2
6 dnssec-signzone - DNSSEC zone signing tool
7
9 dnssec-signzone [-a] [-c class] [-d directory] [-D] [-E engine]
10 [-e end-time] [-f output-file] [-g] [-h] [-K directory]
11 [-k key] [-L serial] [-l domain] [-i interval]
12 [-I input-format] [-j jitter] [-N soa-serial-format]
13 [-o origin] [-O output-format] [-P] [-p] [-R]
14 [-r randomdev] [-S] [-s start-time] [-T ttl] [-t] [-u]
15 [-v level] [-X extended end-time] [-x] [-z] [-3 salt]
16 [-H iterations] [-A] {zonefile} [key...]
17
19 dnssec-signzone signs a zone. It generates NSEC and RRSIG records and
20 produces a signed version of the zone. The security status of
21 delegations from the signed zone (that is, whether the child zones are
22 secure or not) is determined by the presence or absence of a keyset
23 file for each child zone.
24
26 -a
27 Verify all generated signatures.
28 -c class
30 Specifies the DNS class of the zone.
31 -C
33 Compatibility mode: Generate a keyset-zonename file in addition to
34 dsset-zonename when signing a zone, for use by older versions of
35 dnssec-signzone.
36 -d directory
38 Look for dsset- or keyset- files in directory.
39 -D
41 Output only those record types automatically managed by
42 dnssec-signzone, i.e. RRSIG, NSEC, NSEC3 and NSEC3PARAM records. If
43 smart signing (-S) is used, DNSKEY records are also included. The
44 resulting file can be included in the original zone file with
45 $INCLUDE. This option cannot be combined with -O raw or serial
46 number updating.
47 -E engine
49 Uses a crypto hardware (OpenSSL engine) for the crypto operations
50 it supports, for instance signing with private keys from a secure
51 key store. When compiled with PKCS#11 support it defaults to
52 pkcs11; the empty name resets it to no engine.
53 -g
55 Generate DS records for child zones from dsset- or keyset- file.
56 Existing DS records will be removed.
57 -K directory
59 Key repository: Specify a directory to search for DNSSEC keys. If
60 not specified, defaults to the current directory.
61 -k key
63 Treat specified key as a key signing key ignoring any key flags.
64 This option may be specified multiple times.
65 -l domain
67 Generate a DLV set in addition to the key (DNSKEY) and DS sets. The
68 domain is appended to the name of the records.
69 -s start-time
71 Specify the date and time when the generated RRSIG records become
72 valid. This can be either an absolute or relative time. An absolute
73 start time is indicated by a number in YYYYMMDDHHMMSS notation;
74 20000530144500 denotes 14:45:00 UTC on May 30th, 2000. A relative
75 start time is indicated by +N, which is N seconds from the current
76 time. If no start-time is specified, the current time minus 1 hour
77 (to allow for clock skew) is used.
78 -e end-time
80 Specify the date and time when the generated RRSIG records expire.
81 As with start-time, an absolute time is indicated in YYYYMMDDHHMMSS
82 notation. A time relative to the start time is indicated with +N,
83 which is N seconds from the start time. A time relative to the
84 current time is indicated with now+N. If no end-time is specified,
85 30 days from the start time is used as a default. end-time must be
86 later than start-time.
87 -X extended end-time
89 Specify the date and time when the generated RRSIG records for the
90 DNSKEY RRset will expire. This is to be used in cases when the
91 DNSKEY signatures need to persist longer than signatures on other
92 records; e.g., when the private component of the KSK is kept
93 offline and the KSK signature is to be refreshed manually.
94 As with start-time, an absolute time is indicated in YYYYMMDDHHMMSS
96 notation. A time relative to the start time is indicated with +N,
97 which is N seconds from the start time. A time relative to the
98 current time is indicated with now+N. If no extended end-time is
99 specified, the value of end-time is used as the default. (end-time,
100 in turn, defaults to 30 days from the start time.) extended
101 end-time must be later than start-time.
102 -f output-file
104 The name of the output file containing the signed zone. The default
105 is to append .signed to the input filename. If output-file is set
106 to "-", then the signed zone is written to the standard output,
107 with a default output format of "full".
108 -h
110 Prints a short summary of the options and arguments to
111 dnssec-signzone.
112 -i interval
114 When a previously-signed zone is passed as input, records may be
115 resigned. The interval option specifies the cycle interval as an
116 offset from the current time (in seconds). If a RRSIG record
117 expires after the cycle interval, it is retained. Otherwise, it is
118 considered to be expiring soon, and it will be replaced.
119 The default cycle interval is one quarter of the difference between
121 the signature end and start times. So if neither end-time or
122 start-time are specified, dnssec-signzone generates signatures that
123 are valid for 30 days, with a cycle interval of 7.5 days.
124 Therefore, if any existing RRSIG records are due to expire in less
125 than 7.5 days, they would be replaced.
126 -I input-format
128 The format of the input zone file. Possible formats are "text"
129 (default) and "raw". This option is primarily intended to be used
130 for dynamic signed zones so that the dumped zone file in a non-text
131 format containing updates can be signed directly. The use of this
132 option does not make much sense for non-dynamic zones.
133 -j jitter
135 When signing a zone with a fixed signature lifetime, all RRSIG
136 records issued at the time of signing expires simultaneously. If
137 the zone is incrementally signed, i.e. a previously-signed zone is
138 passed as input to the signer, all expired signatures have to be
139 regenerated at about the same time. The jitter option specifies a
140 jitter window that will be used to randomize the signature expire
141 time, thus spreading incremental signature regeneration over time.
142 Signature lifetime jitter also to some extent benefits validators
144 and servers by spreading out cache expiration, i.e. if large
145 numbers of RRSIGs don't expire at the same time from all caches
146 there will be less congestion than if all validators need to
147 refetch at mostly the same time.
148 -L serial
150 When writing a signed zone to 'raw' format, set the "source serial"
151 value in the header to the specified serial number. (This is
152 expected to be used primarily for testing purposes.)
153 -n ncpus
155 Specifies the number of threads to use. By default, one thread is
156 started for each detected CPU.
157 -N soa-serial-format
159 The SOA serial number format of the signed zone. Possible formats
160 are "keep" (default), "increment" and "unixtime".
161 "keep"
163 Do not modify the SOA serial number.
164 "increment"
166 Increment the SOA serial number using RFC 1982 arithmetics.
167 "unixtime"
169 Set the SOA serial number to the number of seconds since
170 epoch.
171 -o origin
173 The zone origin. If not specified, the name of the zone file is
174 assumed to be the origin.
175 -O output-format
177 The format of the output file containing the signed zone. Possible
178 formats are "text" (default) "full", which is text output in a
179 format suitable for processing by external scripts, and "raw" or
180 "raw=N", which store the zone in a binary format for rapid loading
181 by named. "raw=N" specifies the format version of the raw zone
182 file: if N is 0, the raw file can be read by any version of named;
183 if N is 1, the file can be read by release 9.9.0 or higher. The
184 default is 1.
185 -p
187 Use pseudo-random data when signing the zone. This is faster, but
188 less secure, than using real random data. This option may be useful
189 when signing large zones or when the entropy source is limited.
190 -P
192 Disable post sign verification tests.
193 The post sign verification test ensures that for each algorithm in
195 use there is at least one non revoked self signed KSK key, that all
196 revoked KSK keys are self signed, and that all records in the zone
197 are signed by the algorithm. This option skips these tests.
198 -R
200 Remove signatures from keys that no longer exist.
201 Normally, when a previously-signed zone is passed as input to the
203 signer, and a DNSKEY record has been removed and replaced with a
204 new one, signatures from the old key that are still within their
205 validity period are retained. This allows the zone to continue to
206 validate with cached copies of the old DNSKEY RRset. The -R forces
207 dnssec-signzone to remove all orphaned signatures.
208 -r randomdev
210 Specifies the source of randomness. If the operating system does
211 not provide a /dev/random or equivalent device, the default source
212 of randomness is keyboard input. randomdev specifies the name of a
213 character device or file containing random data to be used instead
214 of the default. The special value keyboard indicates that keyboard
215 input should be used.
216 -S
218 Smart signing: Instructs dnssec-signzone to search the key
219 repository for keys that match the zone being signed, and to
220 include them in the zone if appropriate.
221 When a key is found, its timing metadata is examined to determine
223 how it should be used, according to the following rules. Each
224 successive rule takes priority over the prior ones:
225 If no timing metadata has been set for the key, the key is
227 published in the zone and used to sign the zone.
228 If the key's publication date is set and is in the past,
230 the key is published in the zone.
231 If the key's activation date is set and in the past, the
233 key is published (regardless of publication date) and used
234 to sign the zone.
235 If the key's revocation date is set and in the past, and
237 the key is published, then the key is revoked, and the
238 revoked key is used to sign the zone.
239 If either of the key's unpublication or deletion dates are
241 set and in the past, the key is NOT published or used to
242 sign the zone, regardless of any other metadata.
243 -T ttl
245 Specifies a TTL to be used for new DNSKEY records imported into the
246 zone from the key repository. If not specified, the default is the
247 TTL value from the zone's SOA record. This option is ignored when
248 signing without -S, since DNSKEY records are not imported from the
249 key repository in that case. It is also ignored if there are any
250 pre-existing DNSKEY records at the zone apex, in which case new
251 records' TTL values will be set to match them, or if any of the
252 imported DNSKEY records had a default TTL value. In the event of a
253 a conflict between TTL values in imported keys, the shortest one is
254 used.
255 -t
257 Print statistics at completion.
258 -u
260 Update NSEC/NSEC3 chain when re-signing a previously signed zone.
261 With this option, a zone signed with NSEC can be switched to NSEC3,
262 or a zone signed with NSEC3 can be switch to NSEC or to NSEC3 with
263 different parameters. Without this option, dnssec-signzone will
264 retain the existing chain when re-signing.
265 -v level
267 Sets the debugging level.
268 -x
270 Only sign the DNSKEY RRset with key-signing keys, and omit
271 signatures from zone-signing keys. (This is similar to the
272 dnssec-dnskey-kskonly yes; zone option in named.)
273 -z
275 Ignore KSK flag on key when determining what to sign. This causes
276 KSK-flagged keys to sign all records, not just the DNSKEY RRset.
277 (This is similar to the update-check-ksk no; zone option in named.)
278 -3 salt
280 Generate an NSEC3 chain with the given hex encoded salt. A dash
281 (salt) can be used to indicate that no salt is to be used when
282 generating the NSEC3 chain.
283 -H iterations
285 When generating an NSEC3 chain, use this many interations. The
286 default is 10.
287 -A
289 When generating an NSEC3 chain set the OPTOUT flag on all NSEC3
290 records and do not generate NSEC3 records for insecure delegations.
291 Using this option twice (i.e., -AA) turns the OPTOUT flag off for
293 all records. This is useful when using the -u option to modify an
294 NSEC3 chain which previously had OPTOUT set.
295 zonefile
297 The file containing the zone to be signed.
298 key
300 Specify which keys should be used to sign the zone. If no keys are
301 specified, then the zone will be examined for DNSKEY records at the
302 zone apex. If these are found and there are matching private keys,
303 in the current directory, then these will be used for signing.
304
306 The following command signs the example.com zone with the DSA key
307 generated by dnssec-keygen (Kexample.com.+003+17247). Because the -S
308 option is not being used, the zone's keys must be in the master file
309 (db.example.com). This invocation looks for dsset files, in the current
310 directory, so that DS records can be imported from them (-g).
311 % dnssec-signzone -g -o example.com db.example.com \
313 Kexample.com.+003+17247
314 db.example.com.signed
315 %
316 In the above example, dnssec-signzone creates the file
318 db.example.com.signed. This file should be referenced in a zone
319 statement in a named.conf file.
320 This example re-signs a previously signed zone with default parameters.
322 The private keys are assumed to be in the current directory.
323 % cp db.example.com.signed db.example.com
325 % dnssec-signzone -o example.com db.example.com
326 db.example.com.signed
327 %
328
330 dnssec-keygen(8), BIND 9 Administrator Reference Manual, RFC 4033.
331
333 Internet Systems Consortium
334
336 Copyright © 2004-2009, 2011 Internet Systems Consortium, Inc. ("ISC")
337 Copyright © 2000-2003 Internet Software Consortium.
338BIND9 June 05, 2009 DNSSEC-SIGNZONE(8)