dnssec-keymgr fails to apply policy

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

dnssec-keymgr fails to apply policy

Bind-Users forum mailing list
I am using FreeBSD with bind v9.11.8. v9.11.6P1 also had the same problem.

I am using ECDSAP256SHA256 for ZSK and KSK. I have made a very simple
policy that I am trying to automate by using dnssec-keymgr in crontab.

policy default {
         directory "/usr/local/etc/namedb/keys";
         algorithm ECDSAP256SHA256;
         pre-publish zsk 1w;
         post-publish zsk 1w;
         roll-period zsk 2mo;
};

zone example.com {
         policy default;
};

However, every time I run:

dnssec-keymgr -K /usr/local/etc/namedb/keys -r /dev/random

I always get this message:

Unable to apply policy: example.com/ECDSAP256SHA256: unsupported operand
type(s) for +: 'float' and 'NoneType'

Any ideas what this may be?
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: dnssec-keymgr fails to apply policy

Evan Hunt
On Sun, Jun 23, 2019 at 03:48:21AM +0300, Lefteris Tsintjelis via bind-users wrote:
> I always get this message:
>
> Unable to apply policy: example.com/ECDSAP256SHA256: unsupported operand
> type(s) for +: 'float' and 'NoneType'
>
> Any ideas what this may be?

It's a bug. I see the same result. Thanks for pointing it out, I'm
looking into it.

--
Evan Hunt -- [hidden email]
Internet Systems Consortium, Inc.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: dnssec-keymgr fails to apply policy

Evan Hunt
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 -- [hidden email]
Internet Systems Consortium, Inc.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: dnssec-keymgr fails to apply policy

Bind-Users forum mailing list
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;
>      };
>

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users