Re: [knot-dns-users] Knot DNS 1.3.3 patch & 1.4.0 beta release

On 31. 10. 2013, at 14:42, Johan Ihrén <johani(a)johani.org> wrote: Hi Marek, So I've downloaded 1.4.0-beta and will play with it ASAP (which unfortunately will not be until next week at the earliest, due to travel). However, looking at the docs: --- Generate signing keys You have to use ISC (Bind) tools to generate the keys. Create one KSK (key signing key) and one ZSK (zone signing key) for zone example.com: $ mkdir -p /var/lib/knot/keys $ cd /var/lib/knot/keys $ dnssec-keygen -3 -f KSK example.com $ dnssec-keygen -3 example.com --- I'd like to make the following observation: I'm ok with using dnssec-keygen, that's fine. However I'm not fine with all the darn K* files that dnssec-keygen throws around. I hate the K* files with a passion, because they are left-overs of our early attempts at figuring out DNSSEC more than fifteen years ago. I'd like to think that we've learnt a thing or two since then. One of the things that OpenDNSSEC got very, very right was the decision to only go with an HSM for key storage. I care less about the security aspect (although that's important in many cases), I care about the storage abstraction. I.e. my first suggestion would be to use "softhsm" for key storage, but that implies using the PKCS#11 API, which requires some work, and a fair amount of additional code. Therefore my second suggestion is to just add a wrapper around dnssec-keygen and stuff the resulting keys into an sqlite database (or similar). I.e. I would argue that hiding the actual key generator behind a simplistic CLI tool for generating, listing, deleting, etc, keys that are stored in a DB somewhere would be a major improvement to inheriting the utterly broken interface to the K* files that BIND9 uses. No, I don't want to look inside all the K* files to be able to figure out which key is only published, which is active and which is retired. Nor do I want to delete old and retired keys with the Unix "rm" command, and high probability of erasing the wrong file. I want to be able to do something like # keymgr generate --zone bar.com --type zsk Key 68686 (ZSK) for zone "bar.com" generated. # keymgr list --zone foo.com KeyID Type State Next state transition 23456 ZSK published 2013-11-15 12:45:23 12345 ZSK active ... 45678 KSK published ... 34567 KSK active ... 56789 KSK retired ... # keymgr delete --zone foo.com --state retired or something similar. In a way this is basically me singing the same song I heard Miek sing a couple of days ago, regarding key management as a separate thing (separate both from the nameserver but also from the signer). Regards, Johan PS. I've had this discussion with the good folks at ISC several times and one response I got (a couple of years ago) was that the K* files were very useful for debugging. I don't know about you, but where I am DNSSEC is no longer in the "debugging phase", it's in the "deployment phase". That has the implication that the "user interface" should be designed for actually *USING* DNSSEC, not for debugging it. Exposing K* files to users for debugging convenience is just plain wrong. Hide the stuff out of sight, please. _______________________________________________ knot-dns-users mailing list knot-dns-users(a)lists.nic.cz https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users