Re: [knot-dns-users] knot-3.0.4 continuously re-signing DNSSEC zone

Hello, I have just run into a weird problem and since I have failed to look this up on the Web myself, I wonder if anyone here could give me a pointer regarding what to do with it. I run a Linux/arm DNS server based on knot-3.0.4. It used to serve as a slave in a zone whose master was a knot-2.9, with automatic DNSSEC signing _on master only_ set up and working. The zone configuration (minus "master" and "acl" keywords) looked as follows:     zonefile-load: difference-no-serial     journal-content: all     semantic-checks: on #    dnssec-signing: on #    dnssec-policy: nsec3 where "nsec3" is a policy also defined in Knot configuration, identical to the one used on the master. In this role everything worked fine. Recently it has been decided to retire the original master server and replace it with the erstwhile slave. I removed the "master" line from the zone configuration in knot.conf (yes, I did leave the DNSSEC line commented out) in addition to setting up replication to a new slave server, copied the key files + the KASP dump from the old master and installed them in the right places, then restarted knot. Again, so far so good. I then attempted to re-enable DNSSEC by uncommenting those two lines - and immediately after I'd run 'knotc reload' Knot began spamming the system log with lines like info: [example.com.] zone file parsed, serial corrected 2021020301 -> 2021020303 info: [example.com.] DNSSEC, key, tag  4533, algorithm RSASHA1_NSEC3_SHA1, KSK, public, active info: [example.com.] DNSSEC, key, tag 10532, algorithm RSASHA1_NSEC3_SHA1, public, active info: [example.com.] DNSSEC, signing started info: [example.com.] DNSSEC, successfully signed info: [example.com.] loaded, serial 2021020302 -> 2021020303 -> 2021020302, 113233 bytes info: [example.com.] DNSSEC, next signing at 2021-02-10T13:21:14+0000 info: [example.com.] zone file parsed, serial corrected 2021020301 -> 2021020303 info: [example.com.] DNSSEC, key, tag  4533, algorithm RSASHA1_NSEC3_SHA1, KSK, public, active info: [example.com.] DNSSEC, key, tag 10532, algorithm RSASHA1_NSEC3_SHA1, public, active info: [example.com.] DNSSEC, signing started info: [example.com.] DNSSEC, successfully signed info: [example.com.] loaded, serial 2021020302 -> 2021020303 -> 2021020302, 113233 bytes info: [example.com.] DNSSEC, next signing at 2021-02-10T13:21:14+0000 info: [example.com.] zone file parsed, serial corrected 2021020301 -> 2021020303 [...and so on...] This was accompanied by knot consistently requiring much more CPU power than usual. I also noticed that unlike before, running 'knotc zone-flush' or shutting Knot down does NOT update the plain-text zone files. From what I could see by removing old DNSSEC signatures and the NSEC3 chain from the zone file, restarting Knot and then querying the server with dig, the server does indeed sign the zone. Therefore, my current working hypothesis is that somehow Knot does not update its internal zone state following the successful signing, thus continuing to think the outdated zone file found on the file system is the latest available version. The problem is, I do not know why it does it or how I could make it stop. Any and all suggestions will be very much appreciated! Cheers,