16 Úno
2015
16 Úno
'15
12:40
Hello Andreas,
On Sunday 15 of February 2015 17:20:36 Andreas Olsson wrote:
First of all, let me say that I really the koncept of
the KASP. It's
definitely the way I want my DNS Master to handle DNSSEC.
We love to hear that! :-)
While the signing appear to work, there appear to be
something odd with
the policy handing. The default policy I have was created by running:
keymgr policy add default
Note the difference between the json file and the parsed output.
Yes, I can confirm this problem. It is a bug. I will fix it soon.
At least based on the created RRSIGs it appear to be
the values returned
by "keymgr policy show default" which are the ones actually used by
knotd.
Right, the values of keymgr output are the ones used.
On the topic of policy, what is the reason for going
with algoritm 10 by
default? I have really no opinion whatever it's right or wrong, just
curious, since most of the world appear to be using algoritm 8 today?
Well, we don't have any specific reasons for that. We are probably fine with
anything using SHA-2. So algorithm 8 would work as well.
The size of the RSA signature depends on the size of the key, so the size is
not a concern. The difference in computational complexity is insignificant.
And the only reason to use SHA-256 instead of SHA-512 could be a compatibility
with legacy devices. And I'm not sure if there are any legacy devices
supporting SHA-256 and not SHA-512.
There is still a time to change the default. :-)
I'm also wondering if I'm really doing things
right in regards to the
zone file. Based on the following part of knot.conf
Your config is correct.
I have ended up in a situation where both me and knot
edits the same
file /usr/local/etc/knot/master/f13g.se.zone. First I edit a regular
None-DNSSEC record, and upon reload knot updates RRSIGS, etc. While it
kind of works, it feels a bit messy/unstable.
If you are editing an up-to-date zone file (with changes from journal flushed)
and update SOA serial correctly, Knot will preserve valid signatures and fix
the void ones. And everything will work just fine.
As a comparison I'm used to BIND's Inline
Signing[1] where one edits a
regular plain zone file, and BIND keeps all the DNSSECy regards in its
journal files.
We currently don't support that. But we are looking in a way how to separate
the unsigned zones from the automatically generated signatures.
Thank you for the ideas!
Best regards,
Jan