Re: [knot-dns-users] Old key is being used

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." <list(a)crashcom.info> 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? >>>>>>