is a high level Python wrapper to facilitate the key rollover process for zones handled by BIND\&. It uses the BIND commands for manipulating DNSSEC key metadata:
\fBdnssec\-keygen\fR
and
\fBdnssec\-settime\fR\&.
.PP
DNSSEC policy can be read from a configuration file (default
/etc/dnssec\-policy\&.conf), from which the key parameters, publication and rollover schedule, and desired coverage duration for any given zone can be determined\&. This file may be used to define individual DNSSEC policies on a per\-zone basis, or to set a "default" policy used for all zones\&.
runs, it examines the DNSSEC keys for one or more zones, comparing their timing metadata against the policies for those zones\&. If key settings do not conform to the DNSSEC policy (for example, because the policy has been changed), they are automatically corrected\&.
.PP
A zone policy can specify a duration for which we want to ensure the key correctness (\fBcoverage\fR)\&. It can also specify a rollover period (\fBroll\-period\fR)\&. If policy indicates that a key should roll over before the coverage period ends, then a successor key will automatically be created and added to the end of the key series\&.
.PP
If zones are specified on the command line,
\fBdnssec\-keymgr\fR
will examine only those zones\&. If a specified zone does not already have keys in place, then keys will be generated for it according to policy\&.
.PP
If zones are
\fInot\fR
specified on the command line, then
\fBdnssec\-keymgr\fR
will search the key directory (either the current working directory or the directory set by the
\fB\-K\fR
option), and check the keys for all the zones represented in the directory\&.
Force: allow updating of key events even if they are already in the past\&. This is not recommended for use with zones in which keys have already been published\&. However, if a set of keys has been generated all of which have publication and activation dates in the past, but the keys have not been published in a zone as yet, then this option can be used to clean them up and turn them into a proper series of keys with appropriate rollover intervals\&.
(\fBpolicy \fR\fB\fIname\fR\fR\fB { \&.\&.\&. };\fR) can be inherited by zone policies or other policy classes; these can be used to create sets of different security profiles\&. For example, a policy class
\fBnormal\fR
might specify 1024\-bit key sizes, but a class
\fBextra\fR
might specify 2048 bits instead;
\fBextra\fR
would be used for zones that had unusually high security needs\&.
) override default per\-algorithm settings\&. For example, by default, RSASHA256 keys use 2048\-bit key sizes for both KSK and ZSK\&. This can be modified using
\fBalgorithm\-policy\fR, and the new key sizes would then be used for any key of type RSASHA256\&.
option\&. Zone names beginning with digits (i\&.e\&., 0\-9) must be quoted\&. If a zone does not have its own policy then the "default" policy applies\&.
The length of time to ensure that keys will be correct; no action will be taken to create new keys to be activated after this time\&. This can be represented as a number of seconds, or as a duration using human\-readable units (examples: "1y" or "6 months")\&. A default value for this option can be set in algorithm policies as well as in policy classes or zone policies\&. If no policy is configured, the default is six months\&.
Specifies the number of bits to use in creating keys\&. The keytype is either "zsk" or "ksk"\&. A default value for this option can be set in algorithm policies as well as in policy classes or zone policies\&. If no policy is configured, the default is 2048 bits for RSA keys\&.
is not set, this value is ignored\&. The keytype is either "zsk" or "ksk"\&. A default duration for this option can be set in algorithm policies as well as in policy classes or zone policies\&. The default is one month\&.
is not set, this value is ignored\&. The keytype is either "zsk" or "ksk"\&. A default duration for this option can be set in algorithm policies as well as in policy classes or zone policies\&. The default is one month\&.
How frequently keys should be rolled over\&. The keytype is either "zsk" or "ksk"\&. A default duration for this option can be set in algorithm policies as well as in policy classes or zone policies\&. If no policy is configured, the default is one year for ZSKs\&. KSKs do not roll over by default\&.