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 -- e...@isc.org
Internet Systems Consortium, Inc.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
