Hi Aleš,

Dan told me a Debian package is ready in our repo, see https://www.knot-dns.cz/download/

Please check the fix.

Thanks,

Libor


Dne 26.12.2017 v 09:54 Aleš Rygl napsal(a):
Hi Libor,

Good news! If you would not mind providing me with a Debian Stretch 64bit package, it would be great. I am ready to test it.

Regards
Ales


22. prosince 2017 13:44:04 SEČ, "libor.peltan@nic.cz" <libor.peltan@nic.cz> napsal:
Hi Aleš,

thanks for the kjournalprint output! It led strightforwardly to finding 
the bug in Knot. The bug is always re-creating and re-signing NSEC3PARAM 
record. We have fixed it.

Would you be able and willing to check the bugfix for us before we 
release a package? You could either build Knot from current sources 
(branch 2.6), or we could send you a newly-built binaries for your 
architecture (actually, the fix is probably in libknot shared library).

BR,

Libor


Dne 19.12.2017 v 20:38 Aleš Rygl napsal(a):
Hi Libor, On Friday 15 of December 2017 10:26:09 libor.peltan@nic.cz wrote:
Hi all, first, we must distinguish two things: 1) on every reload, every zone is attempted to be re-signed. This takes some CPU time, as the NSEC(3) chain is re-constructed and RRSIGs validated. Anyway, if we perform reload "often", it "usually" ends up with the messages "DNSSEC, zone is up-to-date". This is a design feature of Knot. Is it a problem for you?
This is perfectly clear to me and it is not an issue for me. I like that up-to-date status is logged during the startup.
2) when anything in the zone changes, or the zone would re-sign itself anyway in the meantime, the re-signing ends up with "DNSSEC, successfully signed". This happens e.g. if zone contents changed, NSEC3 salt updated, some RRSIG nearing its end of validity... If this happens on "clear" zone, it's a bug. We have de-bugged this behavior in the past and we also have got a test case covering this. But still it may happen that there is a bug. The best point to start at is journal contents. In the changesets it should be visible what changed. You can explore the journal with "kjournalprint" utility.
This is also clear to me. I am just trying to find the reason for re-sign when the zone content was not (externally) updated. I am rather wonder why this is happening than complaining. Thanks for reminding me of kjournalprint. When checking the journal I can see (last three changes): ;; Changes between zone versions: 1513694442 -> 1513707970 ;;Removed rozjezdy.cz. 3600 SOA idunn.t-mobile.cz. dss-system.t-mobile.cz. 1513694442 7200 600 1209600 3600 rozjezdy.cz. 3600 RRSIG SOA 13 2 3600 20180102144042 20171219131042 53957 rozjezdy.cz. Vnzp8R5bJk3sOybu9WoJzf/1ABNuIz3d0WHhbyQ3VDiIzmZwJ13OOUjsqYuD18OqsFO9eFMNJrPccKjMHsDBLw== rozjezdy.cz. 0 RRSIG NSEC3PARAM 13 2 0 20180102144042 20171219131042 53957 rozjezdy.cz. 9lv+D3biq8FHB2PyTXa98J/31Lf7rdv6KNJNILlm7jsimi0ylSslK6uisLdt5h13jXFRLePs3yWqWMfdBLG8FA== ;;Added rozjezdy.cz. 3600 SOA idunn.t-mobile.cz. dss-system.t-mobile.cz. 1513707970 7200 600 1209600 3600 rozjezdy.cz. 3600 RRSIG SOA 13 2 3600 20180102182610 20171219165610 53957 rozjezdy.cz. zG1o9Rc5zeiO2+JDntbkjrs3Cv+LbKgxvyCYB4tnkT8U/5874YPZlX8OGfDhXAo+QjYk8+RMEf3DReIN/gcbOA== rozjezdy.cz. 0 RRSIG NSEC3PARAM 13 2 0 20180102182610 20171219165610 53957 rozjezdy.cz. xLDqFtMLVWF8Rwjaq84qj5GATN8ozFKEn1sGUNm4rPvPomChkhpz3z6jAC+jTTawTsCbzfMYkAINIeQpMkLJeA== ;; Changes between zone versions: 1513707970 -> 1513708136 ;;Removed rozjezdy.cz. 3600 SOA idunn.t-mobile.cz. dss-system.t-mobile.cz. 1513707970 7200 600 1209600 3600 rozjezdy.cz. 3600 RRSIG SOA 13 2 3600 20180102182610 20171219165610 53957 rozjezdy.cz. zG1o9Rc5zeiO2+JDntbkjrs3Cv+LbKgxvyCYB4tnkT8U/5874YPZlX8OGfDhXAo+QjYk8+RMEf3DReIN/gcbOA== rozjezdy.cz. 0 RRSIG NSEC3PARAM 13 2 0 20180102182610 20171219165610 53957 rozjezdy.cz. xLDqFtMLVWF8Rwjaq84qj5GATN8ozFKEn1sGUNm4rPvPomChkhpz3z6jAC+jTTawTsCbzfMYkAINIeQpMkLJeA== ;;Added rozjezdy.cz. 3600 SOA idunn.t-mobile.cz. dss-system.t-mobile.cz. 1513708136 7200 600 1209600 3600 rozjezdy.cz. 3600 RRSIG SOA 13 2 3600 20180102182856 20171219165856 53957 rozjezdy.cz. GId9nFX7W6zDuhDkXSEoYHL7P2A3tQpr0mlAlJCpGrW2VnxBXlnmMqfVm376PbfN9jijSt3wKHagzz3eS+22DA== rozjezdy.cz. 0 RRSIG NSEC3PARAM 13 2 0 20180102182856 20171219165856 53957 rozjezdy.cz. nYEne/00rSqUQtS5p3Lvi7KbeKQvrlPrdiz31WlQoBwMj+Pg5wZdTu1rbacF4vQCjGfdCYgvuU4M1noAlCfZdg== ;; Changes between zone versions: 1513708136 -> 1513708291 ;;Removed rozjezdy.cz. 3600 SOA idunn.t-mobile.cz. dss-system.t-mobile.cz. 1513708136 7200 600 1209600 3600 rozjezdy.cz. 3600 RRSIG SOA 13 2 3600 20180102182856 20171219165856 53957 rozjezdy.cz. GId9nFX7W6zDuhDkXSEoYHL7P2A3tQpr0mlAlJCpGrW2VnxBXlnmMqfVm376PbfN9jijSt3wKHagzz3eS+22DA== rozjezdy.cz. 0 RRSIG NSEC3PARAM 13 2 0 20180102182856 20171219165856 53957 rozjezdy.cz. nYEne/00rSqUQtS5p3Lvi7KbeKQvrlPrdiz31WlQoBwMj+Pg5wZdTu1rbacF4vQCjGfdCYgvuU4M1noAlCfZdg== ;;Added rozjezdy.cz. 3600 SOA idunn.t-mobile.cz. dss-system.t-mobile.cz. 1513708291 7200 600 1209600 3600 rozjezdy.cz. 3600 RRSIG SOA 13 2 3600 20180102183131 20171219170131 53957 rozjezdy.cz. KklZfsp8Ztzih04/Weedt1aP5Qa9oxsnj72KuGeeqI1szSvL/l6uGC6Rf6ZZJjrN/A/TQMcJzbkgwIMe6YetYA== rozjezdy.cz. 0 RRSIG NSEC3PARAM 13 2 0 20180102183131 20171219170131 53957 rozjezdy.cz. FfE9FhQgr8NWCfKf9d1aA0I8h4cd7CCSRbp0Nkq+BXmLOpRMs862lRSWCNHPxRPqufQvjo34AlroRrTYpevwEg== I do not understand it: are the changes listed above the cause or the consequenceof re-sign? Regards Ales