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
_______________________________________________
knot-dns-users mailing list
[email protected]
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

Reply via email to