Hi Thomas,
thank you very much for your cooperation. Actually, when reading the
issue description carefully, this is something I expected a little bit
that can happen. A shared KSK is taken from the policy, while the
algorithm changed in the meantime.
However, it wasn't the exact same thing that you were describing
earlier. For example, the key tags weren't matching in the logs you
provided (or maybe I've mistaken them?) and some ZSKs with the old
algorithm appeared as well, which seemed far more weird than this issue :)
Additionally, you said that your issues persisted after making the
policy not shared. This still puzzles me.
Thanks anyway, so far we can focus on fixing this well-described bug and
we'll see if any issues remain after that.
BR,
Libor
Dne 18. 03. 21 v 14:44 Thomas E. napsal(a):
Hi Libor,
hi Daniel,
today we were finally able to isolate and to reproduce the problem.
We made an issue in gitlab because it's much easier to read when
everything is formatted.
https://gitlab.nic.cz/knot/knot-dns/-/issues/721
BR,
Thomas
On 18.03.21 10:32, libor.peltan wrote:
Hi Thomas,
do you please have any updates to your issue?
Could you perhaps try to somehow clone your environment so that you had
the issue reproduced in a non-production setup ready for some more
experiments?
First of all, I wonder if after you add a new zone to your configuration
and instead of re-configuring the server, sign the zone first with
`kzonesign -r`, the same behavior would be observed...
Sorry for not helping you yet, but we are struggling understanding
what's going on at your setup :(
BR,
Libor
Dne 14. 03. 21 v 8:53 Daniel Salzman napsal(a):
Hi Thomas,
You could try purging possibly orphaned data:
# knotc -f zone-purge -- +orphan
Please make a backup of the defective situation first!
Do you think that you could prepare and share (just with us) a minimal
reproducer of the issue?
It would help a lot with the debugging.
Best,
Daniel
On 3/14/21 12:14 AM, Thomas wrote:
Hi Libor,
we experience the same behavior after changing the config. Still 2 KSK
(and 2 ZSK) are being created after signing a zone. One with Alg 8 and
one with Alg 10. The one with Alg 8 is being used for signing and a
rollover is started immediately after signing.
Don't now how to get out of the situation. Somehow there must be a
reference to the old Alg 8 somewhere. No idea why a new zone is singed
with Alg 8.
Is there a way to clean up all the DNSSEC related data somehow? Actually
I would be able to un-sign and purge all zones, we are only signing a
few until now. But I don't know if this will solve the issue.
Thanks,
Thomas
On 09.03.21 13:40, libor.peltan wrote:
Hi Thomas,
yes, it shall be very smooth to simply remove the 'share' option from
configuration and continue as before.
The idea of shared KSK was generally good and a surprising enhancement,
but you might have fallen to a random bug in rarely deployed
configuration combo.
I'm curious to hear if your issue disappears once you change the
config.
Please let me know,
Libor
Dne 09. 03. 21 v 13:15 Thomas E. napsal(a):
Thanks for the hint with the "cds-cdnskey-publish: always" issue.
We are using shared ksk policy beause we thought it might be a good
idea
to reduce the amount of keys in the database. We are going to sing
more
than 10K zones and thought it might be a good thing to use shared keys
to speed up backups and restores.
But if this causes the actual problem I will change it of course.
Do you
know if it's safe to remove the shared policy attribute from the
config?
Thanks,
Thomas
On 08.03.21 17:55, Tuomo Soini wrote:
On Mon, 8 Mar 2021 17:09:54 +0100
"Thomas E." <[email protected]> wrote:
A KSK and ZSK with Alg RSASHA256 have been created and the zone was
signed. An algorithm rollover is triggered right after signing. I
don't understand why RSASHA256 is still being used.
This is a very wild guess but I'd suspect this has something to do
with
ksk-shared: true, note the config below.
policy:
- id: shared
algorithm: RSASHA512
ksk-size: 2048
zsk-size: 1024
zsk-lifetime: 30d
ksk-lifetime: 365d
ksk-shared: true
ksk-submission: resolver
nsec3: true
cds-cdnskey-publish: always
Btw. cds-cdnskey-publish: always is against instructions in rfc.
those
should only be published for rollover only.
Is there some reason for using shared ksk?
--
https://lists.nic.cz/mailman/listinfo/knot-dns-users
