dnssec-keymgr fails to apply policy
Lefteris Tsintjelis
lefty at spes.gr
Sun Jun 23 18:22:09 UTC 2019
On 23/6/2019 20:28, Evan Hunt wrote:
> 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;
> };
Overriding a subset of the default and keeping everything else is
exactly what I had in mind actually. Works great now, thank you!
> 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;
> };
>
More information about the bind-users
mailing list