Hi Marek,
thank you for reporting your troubles with Knot.
This seems like an effect of a bug. I must admit that the scenario of
transforming a slave into signing master has not been tested too much ;)
We would really appreciate if you helped us debug it.
In order to attempt to mitigate the issue, you may try purging zone
timers. Please back up the timers database first (by simply copying the
directory <storage>/timers somewhere), and then either `knotc zone-purge
example.com. +timers` or delete the directory (I assume that you have
just one zone configured at your server?).
Please let us know if that helped. In the meantime, I will try to
reproduce your issue.
Z poważaniem,
Libor
Dne 03. 02. 21 v 15:29 Marek Szuba napsal(a):
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,
--
https://lists.nic.cz/mailman/listinfo/knot-dns-users
