26 Pro
2017
26 Pro
'17
9:54
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(a)nic.cz"
<libor.peltan(a)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):
that up-to-date status is logged during the startup.
re-sign when the zone content was not (externally) updated. I
am rather
wonder why this is happening than complaining.
Hi Libor,
On Friday 15 of December 2017 10:26:09 libor.peltan(a)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
> 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 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