dnssec-keymgr fails to apply policy
Evan Hunt
each at isc.org
Sun Jun 23 17:28:18 UTC 2019
On Sun, Jun 23, 2019 at 05:01:11PM +0000, Evan Hunt wrote:
> It's a bug. I see the same result. Thanks for pointing it out, I'm
> looking into it.
Ah, I see the problem. You overrode the default policy by using the name
"default", but you didn't set a "coverage" value in your new defaults, so
it choked because it didn't know how far into the future you wanted it to
generate keys. This definitely needs a clearer error message.
Here are three ways to write the policy file that would do what you want:
1) Explicitly add a "coverage" value to the "default" policy.
policy default {
directory "/usr/local/etc/namedb/keys";
algorithm ECDSAP256SHA256;
pre-publish zsk 1w;
post-publish zsk 1w;
roll-period zsk 2mo;
coverage 6mo;
};
(Side note: the zone policy for example.com in your policy file was
unnecessary, since you were setting defaults that would have been used
anyway.)
2) Explicitly inherit built-in global defaults when setting up the
"default" policy. This way you're overriding a subset of the defaults
rather than setting up a whole new set from scratch.
policy default {
policy global;
directory "/usr/local/etc/namedb/keys";
algorithm ECDSAP256SHA256;
pre-publish zsk 1w;
post-publish zsk 1w;
roll-period zsk 2mo;
};
3) Don't reset "default", just set up a zone policy statement for the
particular zone you're interested in. This will inherit the existing
defaults, it doesn't need to be told to do so.
zone example.com {
directory "/usr/local/etc/namedb/keys";
algorithm ECDSAP256SHA256;
pre-publish zsk 1w;
post-publish zsk 1w;
roll-period zsk 2mo;
};
--
Evan Hunt -- each at isc.org
Internet Systems Consortium, Inc.
More information about the bind-users
mailing list