Hi Johan, On 29 January 2014 16:34, Johan Ihrén <johani(a)johani.org> wrote: I know and I sort of get where this is coming from. I'd just like to say that it doesn't ring hollow. I reckon we are nearing to 'feature-complete' (as of today), not quite there but almost. So our focus is shifting from features to polishing features we already have and improving the feature testing and this is going to be a big thing for the upcoming releases. I agree that some things are made too complicated for a very little outcome, but it's a continuous effort to balance the demand for features and simplicity. I think neither extreme is good and can only hope we can find a sweet spot between those some time down the road. A good measure is the codebase size. If it gets smaller with the further releases, I'm going to be a happy man :) Makes sense, I think Jan might tell more about the plans for future? Yes, this is a regression introduced with 1.4x strain. RRSIGs caused setting TC=1, that's what's fixed now.

Hi Jan, On 29 Jan 2014, at 17:20 , Jan Včelák <jan.vcelak(a)nic.cz> wrote: Agreed ;-) I'm all in favour of separating signing policy from server config. So if you're working on something a la KASP then I fully agree that's where the resigning policy should be. Regards, Johan

Hi Olafur and Marek, On 29 Jan 2014, at 17:21 , Olafur Gudmundsson <ogud(a)ogud.com> wrote: I agree with this, I also believe there's a sweet spot somewhere in the middle. But, as we have discussed previously, I also believe that the sweet spot is a question of, let's call it "system functionality", i.e. the "Knot system" should be able to provide the functionality that is required and wanted by users. That is not necessarily the same thing as having it all in the same binary ;-) But I really don't want to make too much of this, I'm much impressed by what you guys have achieved in a very short time frame, and I'm much looking forward to the polishing phase. True that. We think alike ;-) I must admit that my memory is getting fuzzy (or perhaps fudgy?) on this issue, but I do remember that we debated this intensely some years ago. Wasn't the conclusion that the TTL should be capped to the remaining signature lifetime *by the validator* (or rather by whoever intends to cache stuff for future use)? I.e. the place for alignment of remaining sig life and TTL is in the validator, because that's when they are both converted into wall clock time (which can be compared). In the signer end, you just don't know anything about how old the data will be when it enters someone elses cache and that will force the need for "too much fudge". Look at it this way: assume 10 days of sig life, a max TTL of 3 days (just to force the issue) and a SOA expire of 8 days. Freshly signed zone transfers to slave. Connection to master is broken. Slave keeps publishing for eight days. Just before expiration validator queries for stuff, which will have remaining sig life = 2 days and TTL = 3 days. I.e. unless the validator/cache caps the TTL to remaining life it will keep data with expired sigs around, which is not good. My point is not that this is a good signing policy, but rather that you cannot fix this with the "resigning interval", because the signer may keep resigning the zone until the cows come home with no effect, because the connectivity between master and rest of the system is broken. The validator OTOH can trivially avoid problems by capping TTLs. Hence the validation failures that concern you (which are real) can not be fully mitigated by any resigning policy. Johan