1DNSSEC-KEYMGR(8) BIND 9 DNSSEC-KEYMGR(8)
2
6 dnssec-keymgr - ensure correct DNSKEY coverage based on a defined pol‐
7 icy
8
10 dnssec-keymgr [-Kdirectory] [-cfile] [-f] [-k] [-q] [-v] [-z] [-gpath]
11 [-spath] [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 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 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 exam‐
28 ple, because the policy has been changed), they are automatically cor‐
29 rected.
30 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 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 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 Key times that are in the past will not be updated unless the -f is
47 used (see below). Key inactivation and deletion times that are less
48 than five minutes in the future will be delayed by five minutes.
49 It is expected that this tool will be run automatically and unattended
51 (for example, by cron).
52
54 -c file
55 If -c is specified, then the DNSSEC policy is read from file. (If
56 not specified, then the policy is read from /etc/dnssec-policy.conf;
57 if that file doesnt exist, a built-in global default policy is
58 used.)
59 -f
61 Force: allow updating of key events even if they are already in the
62 past. This is not recommended for use with zones in which keys have
63 already been published. However, if a set of keys has been generated
64 all of which have publication and activation dates in the past, but
65 the keys have not been published in a zone as yet, then this option
66 can be used to clean them up and turn them into a proper series of
67 keys with appropriate rollover intervals.
68 -g keygen-path
70 Specifies a path to a dnssec-keygen binary. Used for testing. See
71 also the -s option.
72 -h
74 Print the dnssec-keymgr help summary and exit.
75 -K directory
77 Sets the directory in which keys can be found. Defaults to the cur‐
78 rent working directory.
79 -k
81 Only apply policies to KSK keys. See also the -z option.
82 -q
84 Quiet: suppress printing of dnssec-keygen and dnssec-settime.
85 -s settime-path
87 Specifies a path to a dnssec-settime binary. Used for testing. See
88 also the -g option.
89 -v
91 Print the dnssec-keymgr version and exit.
92 -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 · Policy classes (policyname{ ... };) can be inherited by zone poli‐
99 cies or other policy classes; these can be used to create sets of
100 different security profiles. For example, a policy class normal
101 might specify 1024-bit key sizes, but a class extra might specify
102 2048 bits instead; extra would be used for zones that had unusually
103 high security needs.
104 · Algorithm policies: (algorithm-policyalgorithm{ ... }; ) override
105 default per-algorithm settings. For example, by default, RSASHA256
106 keys use 2048-bit key sizes for both KSK and ZSK. This can be modi‐
107 fied using algorithm-policy, and the new key sizes would then be
108 used for any key of type RSASHA256.
109 · Zone policies: (zonename{ ... }; ) set policy for a single zone by
111 name. A zone policy can inherit a policy class by including a policy
112 option. Zone names beginning with digits (i.e., 0-9) must be quoted.
113 If a zone does not have its own policy then the "default" policy ap‐
114 plies.
115 Options that can be specified in policies:
117 algorithm name;
119 The key algorithm. If no policy is defined, the default is
120 RSASHA256.
121 coverage duration;
123 The length of time to ensure that keys will be correct; no action
124 will be taken to create new keys to be activated after this time.
125 This can be represented as a number of seconds, or as a duration us‐
126 ing human-readable units (examples: "1y" or "6 months"). A default
127 value for this option can be set in algorithm policies as well as in
128 policy classes or zone policies. If no policy is configured, the de‐
129 fault is six months.
130 directory path;
132 Specifies the directory in which keys should be stored.
133 key-size keytype size;
135 Specifies the number of bits to use in creating keys. The keytype is
136 either "zsk" or "ksk". A default value for this option can be set in
137 algorithm policies as well as in policy classes or zone policies. If
138 no policy is configured, the default is 2048 bits for RSA keys.
139 keyttl duration;
141 The key TTL. If no policy is defined, the default is one hour.
142 post-publish keytype duration;
144 How long after inactivation a key should be deleted from the zone.
145 Note: If roll-period is not set, this value is ignored. The keytype
146 is either "zsk" or "ksk". A default duration for this option can be
147 set in algorithm policies as well as in policy classes or zone poli‐
148 cies. The default is one month.
149 pre-publish keytype duration;
151 How long before activation a key should be published. Note: If
152 roll-period is not set, this value is ignored. The keytype is either
153 "zsk" or "ksk". A default duration for this option can be set in al‐
154 gorithm policies as well as in policy classes or zone policies. The
155 default is one month.
156 roll-period keytype duration;
158 How frequently keys should be rolled over. The keytype is either
159 "zsk" or "ksk". A default duration for this option can be set in al‐
160 gorithm policies as well as in policy classes or zone policies. If
161 no policy is configured, the default is one year for ZSKs. KSKs do
162 not roll over by default.
163 standby keytype number;
165 Not yet implemented.
166
168 · Enable scheduling of KSK rollovers using the -P sync and -D sync
169 options to dnssec-keygen and dnssec-settime. Check the parent zone
170 (as in dnssec-checkds) to determine when its safe for the key to
171 roll.
172 · Allow configuration of standby keys and use of the REVOKE bit, for
173 keys that use RFC 5011 semantics.
174
176 dnssec-coverage(8), dnssec-keygen(8), dnssec-settime(8),
177 dnssec-checkds(8)
178
180 Internet Systems Consortium
181
183 2021, Internet Systems Consortium
1849.16.23-RH DNSSEC-KEYMGR(8)