Hello Matthias, we are currently preparing a release of Knot DNS 1.4, which will support automatic DNSSEC signing (as an experimental feature), including DDNS support. Key rollovers and accesing the keys via PKCS#11 are not implemented yet but it is on our short term plan. Our long term plan is to provide the same comfort as OpenDNSSEC does in Knot, but with all the features OpenDNSSEC is missing. So I guess your current deployment is the best solution at the moment. Stay tuned for the next release and we will be glad if you give us some feedback. :-) Jan

On Oct 21, 2013, at 22:39 , Matthias-Christian Ott wrote: So, while I'm well aware that this is not what is currently being planned for Knot-DNS, this is my view on the topic: I like simple things. I like tools that do one thing well, rather than too many things less well. I.e. basically the "Unix tradition" of simple tools together with powerful mechanisms for combining several tools into more complex operations. For that reason I like authoritative servers that *only* provide authoritative service, without all the bells and whistles of dealing with keys, PKCS#11, rollovers, etc. The reason that I want simple things is that the alternative, i.e. "complex", always carry costs. Costs in performance, costs in bugs, costs in more potential for misconfiguration, costs in increased difficulty in maintaining the source without adding new problems, etc, etc. In fact, I prefer an authoritative servers that simply does not modify the zone, i.e. only serves the data. Full stop. I.e. the ultimate "slave server". (I also want the ultimate master server). Another thing I don't like is to have to modify an established and debugged process, especially one which involves humans, custom scripts and other stuff that breaks. Today the design with a "master" where zone changes are applied (regardless of whether it is by reloading a zone file, applying dynamic updates or generating from some other sournce) followed by zone transfer to "slaves" that don't modify contents and only serve the stuff is very well established. To switch this design to use DNSSEC the minimal change is to add a "signer" as a bump-on-the-wire between "master" and "slaves". No change to the master and the only change to the slaves are that they need to source the zone from the signer instead of the master. I.e. from my point-of-view the design that you apparently don't like IS the simplest solution, in particular as you're dependent on dynamic updates. In particular these days when the cost of a "hidden master" is basically zero, as that's just another virtual machine somewhere. That is not to say that OpenDNSSEC is simple (it is not). I'd really like to have good alternatives for the "signer" component and if NIC.CZ could be tickled to look into a separate "signer" as opposed to adding all the signer complexity into the standard authoritative server which is Knot-DNS then I'd be delighted. But right now the plan seems to be to emulate everything BIND9 does, both the good parts and the bad (except the recursive part obviously). But, this said, I really, really don't want this to be read as a complaint. I really like Knot-DNS and have great hopes for it. Everyone is obviously entitled to develop whathever they want. So, if what I want is different from what others want, the onus is basically on me to put down the hours or the money to get what I want. Which I haven't done. Regards, Johan

Hi Jan, On Oct 23, 2013, at 10:50 , Jan Včelák wrote: Thank you. Which is fine. I'm fully aware that many people want that. And some people want their own pony. And lower taxes. ;-) I'm also aware that many people would like to continue to just use BIND9 forever, because BIND9 is the ultimate all-in-one-solution... only the world has come to understand after BIND9 was designed that "all-in-one" has serious drawbacks. To some extent the primary reason that we're here, the reason why we have NSD3/4, Unbound, Yadifa, Knot-DNS, etc, is because of the drawbacks of the BIND9 all-in-one alternative, which are increasingly obvious. But ISC really cannot "fix" BIND9, in spite of being aware of the drawbacks of all-in-one, because of the installed base. I'd hate to see Knot-DNS go down the same path (and get stuck there, which happens quickly when there's adoption) when you're starting out late enough to both be aware of the arthitectural drawbacks and not be captive to a gigantic installed base. That's really the core question. Will the addition of lots of stuff that I don't want in my authoritative servers impact performance? Impact stability? Impact frequency of bugs? Obviously we don't know yet, but we all hope it'll work out. Please do. From my point-of-view an ideal solution would be one where you had all the functionality we're discussing (I think everyone is mostly in agreement about that: auth server, key mgmt, signer, rollover support, etc, etc), but designed in a sufficiently modular fashion to allow an option to either compile the separate "signer" and a "clean" authoritative server or, the BIND9-lookalike monolithic combo that apparently many people want. Of course that flexibility wouldn't come for free, there's certainly a noticeable design cost and some maintenance cost associated with it. But it would be much easier to achieve the earlier you look at that design. Regards, Johan

[ Quoting <johani(a)johani.org> in "Re: [knot-dns-users] Knot DNS, DNS ..." ] +1 (and also to the rest you wrote). What I would like to see (personal opinion, I'm not asking for these features in Knot), is a seperate key-handling entity, just like opendnssec, but without the signing part. In my theoretical and perfect world I could use something like this to make keyrollovers happen in my cron-based signing setup. I.e. the key-handling binary just drops some keys in a directory which get picked up by dnssec-signzone and then given to my nameserver binary. Grtz, -- Miek Gieben PGP 3880D0F6