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

Hi, On Oct 31, 2013, at 20:18 , Ondřej Surý wrote: I agree. As long as the user interface is sufficiently abstract, and has suitable safe guards ("no, you don't want to delete the active KSK") I'm happy. The existence of files in a filesystem behind the scenes is not the issue, as long as that isn't the suggested interface. There's always a behind-the-scenes interface where you can mess stuff up if you set your mind to it. That said, I'll comment a bit on the consequences of keeping the keys in separate files in the file system below. I used to think this too. But I've come to change my mind. So, just going with this line of thought: * Your zone is example.com and the name of the KSK files are KSK_example.com.private (and .key). Sofar, simple and predictable, just two files to be aware of. * In most cases you want to add a ZSK. That's four files for one zone. * Only having one single zone is actually quite rare. Without going into the professional hosting environments that have tens of thousands of zones, but just looking at myself and fellow geeks (not all of them DNS geeks, mind you), I find that ususally there are around ten zones or so. There's the v4 reverse zone, the v6 reverse and if you have stuff in more than one place then there's multiple v4 and v6 reverses. And for the sake of argument perhaps there are five forward zones, i.e. nine zones in total. (5 forward + 4 reverses) * 4 = 36 files. * Time for rollovers. Here you have two alternatives. Either the files are *renamed* as the state of the key inside changes (generated-->published-->ready-->active-->retired) or they are not. If the names are changed then that's a risk by itself, because you get the potential for locking issues where the contents of the file you think you're doing something to is not the same as it was some time ago. If, on the other hand you never rename files then you need to keep the metadata (state, etc) somewhere else than in the filename, i.e. inside the file or a database somewhere. Furthermore, with static filenames, what should be the name of the *new* KSK that is generated? It cannot be KSK_example.com.{key,private} obviously. So it has to be KSK_example.[id of some sort].{key,private}. And now we've reinvented the K* files. And, BTW, when dealing with multiple keys during rollovers there will be at least 3, possibly 5 keys per zone. Both KSK and ZSK. So that's at least: 3 states * 2 keys * 2 files * 9 zones = 108 files that because of the need for a unique id for each key will all have unpredictable names that are difficult to script. * And the final nit: time. Because DNSSEC rollovers take a lot of time (months typically) you will not be able to just figure out which key is in which file once and take care of what needs to be done, you'll get half way and then you need to continue with the next phase in two weeks time. At this point you will have forgotten which key was which so you need to start over looking inside all the files again, etc. Unless, of course, you cheat and have a little file on the side with metadata about which key is which, etc. Regardless of method it is messy. And this is why I argue that exposing the key files to the users are, umm, not the way to go in 2013. It's just like the english story telling idiom: "...it seemed like a good idea at the time". It's just that "the time" was around 1996, and at that time we had not figured out the KSK/ZSK split, we had not figured out all the different states during rollovers and we had not figured out all the complexity and pain we'd get from algorithm rollovers (that I didn't even include above). So here we are, seventeen years later, and it no longer seems like a good idea ;-) Regards, Johan