1DNSSEC-KEYMGR(8) BIND9 DNSSEC-KEYMGR(8)
2
3
4
6 dnssec-keymgr - Ensures correct DNSKEY coverage for a zone based on a
7 defined policy
8
10 dnssec-keymgr [-K directory] [-c file] [-f] [-k] [-q] [-v] [-z]
11 [-g path] [-r path] [-s path] [zone...]
12
14 dnssec-keymgr is a high level Python wrapper to facilitate the key
15 rollover process for zones handled by BIND. It uses the BIND commands
16 for manipulating DNSSEC key metadata: dnssec-keygen and dnssec-settime.
17
18 DNSSEC policy can be read from a configuration file (default
19 /etc/dnssec-policy.conf), from which the key parameters, publication
20 and rollover schedule, and desired coverage duration for any given zone
21 can be determined. This file may be used to define individual DNSSEC
22 policies on a per-zone basis, or to set a default policy used for all
23 zones.
24
25 When dnssec-keymgr runs, it examines the DNSSEC keys for one or more
26 zones, comparing their timing metadata against the policies for those
27 zones. If key settings do not conform to the DNSSEC policy (for
28 example, because the policy has been changed), they are automatically
29 corrected.
30
31 A zone policy can specify a duration for which we want to ensure the
32 key correctness (coverage). It can also specify a rollover period
33 (roll-period). If policy indicates that a key should roll over before
34 the coverage period ends, then a successor key will automatically be
35 created and added to the end of the key series.
36
37 If zones are specified on the command line, dnssec-keymgr will examine
38 only those zones. If a specified zone does not already have keys in
39 place, then keys will be generated for it according to policy.
40
41 If zones are not specified on the command line, then dnssec-keymgr will
42 search the key directory (either the current working directory or the
43 directory set by the -K option), and check the keys for all the zones
44 represented in the directory.
45
46 It is expected that this tool will be run automatically and unattended
47 (for example, by cron).
48
50 -c file
51 If -c is specified, then the DNSSEC policy is read from file. (If
52 not specified, then the policy is read from
53 /etc/dnssec-policy.conf; if that file doesn't exist, a built-in
54 global default policy is used.)
55
56 -f
57 Force: allow updating of key events even if they are already in the
58 past. This is not recommended for use with zones in which keys have
59 already been published. However, if a set of keys has been
60 generated all of which have publication and activation dates in the
61 past, but the keys have not been published in a zone as yet, then
62 this option can be used to clean them up and turn them into a
63 proper series of keys with appropriate rollover intervals.
64
65 -g keygen-path
66 Specifies a path to a dnssec-keygen binary. Used for testing. See
67 also the -s option.
68
69 -h
70 Print the dnssec-keymgr help summary and exit.
71
72 -K directory
73 Sets the directory in which keys can be found. Defaults to the
74 current working directory.
75
76 -k
77 Only apply policies to KSK keys. See also the -z option.
78
79 -q
80 Quiet: suppress printing of dnssec-keygen and dnssec-settime.
81
82 -r randomdev
83 Specifies a path to a file containing random data. This is passed
84 to the dnssec-keygen binary using its -r option.
85
86 -s settime-path
87 Specifies a path to a dnssec-settime binary. Used for testing. See
88 also the -g option.
89
90 -v
91 Print the dnssec-keymgr version and exit.
92
93 -z
94 Only apply policies to ZSK keys. See also the -k option.
95
97 The dnssec-policy.conf file can specify three kinds of policies:
98
99 · Policy classes (policy name { ... };) can be inherited by zone
100 policies or other policy classes; these can be used to create sets
101 of different security profiles. For example, a policy class normal
102 might specify 1024-bit key sizes, but a class extra might specify
103 2048 bits instead; extra would be used for zones that had unusually
104 high security needs.
105
106 · Algorithm policies: (algorithm-policy algorithm { ... }; ) override
107 default per-algorithm settings. For example, by default, RSASHA256
108 keys use 2048-bit key sizes for both KSK and ZSK. This can be
109 modified using algorithm-policy, and the new key sizes would then
110 be used for any key of type RSASHA256.
111
112 · Zone policies: (zone name { ... }; ) set policy for a single zone
113 by name. A zone policy can inherit a policy class by including a
114 policy option. Zone names beginning with digits (i.e., 0-9) must be
115 quoted.
116
117 Options that can be specified in policies:
118
119 algorithm
120 The key algorithm. If no policy is defined, the default is
121 RSASHA256.
122
123 coverage
124 The length of time to ensure that keys will be correct; no action
125 will be taken to create new keys to be activated after this time.
126 This can be represented as a number of seconds, or as a duration
127 using human-readable units (examples: "1y" or "6 months"). A
128 default value for this option can be set in algorithm policies as
129 well as in policy classes or zone policies. If no policy is
130 configured, the default is six months.
131
132 directory
133 Specifies the directory in which keys should be stored.
134
135 key-size
136 Specifies the number of bits to use in creating keys. Takes two
137 arguments: keytype (eihter "zsk" or "ksk") and size. A default
138 value for this option can be set in algorithm policies as well as
139 in policy classes or zone policies. If no policy is configured, the
140 default is 1024 bits for DSA keys and 2048 for RSA.
141
142 keyttl
143 The key TTL. If no policy is defined, the default is one hour.
144
145 post-publish
146 How long after inactivation a key should be deleted from the zone.
147 Note: If roll-period is not set, this value is ignored. Takes two
148 arguments: keytype (eihter "zsk" or "ksk") and a duration. A
149 default value for this option can be set in algorithm policies as
150 well as in policy classes or zone policies. The default is one
151 month.
152
153 pre-publish
154 How long before activation a key should be published. Note: If
155 roll-period is not set, this value is ignored. Takes two arguments:
156 keytype (either "zsk" or "ksk") and a duration. A default value for
157 this option can be set in algorithm policies as well as in policy
158 classes or zone policies. The default is one month.
159
160 roll-period
161 How frequently keys should be rolled over. Takes two arguments:
162 keytype (eihter "zsk" or "ksk") and a duration. A default value for
163 this option can be set in algorithm policies as well as in policy
164 classes or zone policies. If no policy is configured, the default
165 is one year for ZSK's. KSK's do not roll over by default.
166
167 standby
168 Not yet implemented.
169
171 · Enable scheduling of KSK rollovers using the -P sync and -D sync
172 options to dnssec-keygen and dnssec-settime. Check the parent zone
173 (as in dnssec-checkds) to determine when it's safe for the key to
174 roll.
175
176 · Allow configuration of standby keys and use of the REVOKE bit, for
177 keys that use RFC 5011 semantics.
178
180 dnssec-coverage(8), dnssec-keygen(8), dnssec-settime(8), dnssec-
181 checkds(8)
182
184 Internet Systems Consortium, Inc.
185
187 Copyright © 2016-2018 Internet Systems Consortium, Inc. ("ISC")
188
189
190
191ISC 2016-06-03 DNSSEC-KEYMGR(8)