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
