20 Pro
2015
20 Pro
'15
11:11
Hello again.
- DNSSEC newly implements an interface to access
cryptographic tokens
via the PKCS #11. This means, that you can store the private key
material for DNSSEC keys more securely than before.
I want to give you some additional information about the changes related
to DNSSEC. We were forced to do some incompatible changes in the KASP
database. And the rc1 version cannot handle these changes transparently.
So if you are using a KASP database initialized with keymgr from Knot
DNS 2.0, you might observe a lot of 'invalid parmeter' errors in the
server log. This should give you an idea how to fix it:
- As we now support multiple key stores (PKCS #8 PEM files in
a directory and PKCS #11 tokens), the key stores have to be configured
in the database as well:
$ cd /your/kasp/db
$ keymgr keystore add default backend pkcs8 config keys
$ keymgr policy set default keystore default
(This will create a configuration for the default key store which was
implicit in the 2.0. And it will assign this keystore to the default
policy.)
- If you are manually generating the keys for a zone, you currently use
the 'none' policy. In the new version, each zone has to have a policy
assigned because the policy also controls signing parameters (e.g.
signature life time which was hardcoded in 2.0). So you will have to
execute:
$ keymgr policy add manual manual true
$ keymgr zone set example.com policy manual
(The first command will create a new signing policy named 'manual'
with the default parameters but disabled automatic key management.
The second command will assign the policy to the zone.)
- In some situations, running 'keymgr init' in the already initialized
database will fix the problem. The command won't rewrite any of your
configuration. It will just create the default policy (if missing) and
the default keystore (if missing). But the existing entities have to
be linked (the 'keymgr ... set ...' above).
Let me know if you encounter any problem. Thank you!
Jan