Hi Libor,
On 1 Dec 2025, at 11:32, Libor Peltan
<libor.peltan(a)nic.cz> wrote:
Anyway, it would be useful if you provide us with more complete information, mostly (at
least) about the server where you do observe the issue (which is, I assume, the backup
signer where the keys are being restored to):
- Knot DNS version
Initially seen on 3.5.0, but tried upgrarding to 3.5.2 and I still get the error there.
Both running on FreeBSD 14.3-RELEASE
- configuration file (or at least relevant parts;
don't forget to remove any TSIG secrets or sensitive IPs)
Attached config files.
- longer log snippets around the time the issue was
observed
Complete log file attached. Key sync runs every hour, 8 mins. past the hour.
- the script that you use for the backup (or at least
relevant parts; unless it is somehow sensitive)
Scripts attached. sync_keys.sh is run on the active signer every hour,
sync_keys_wrapper.sh is on the
backup and used so authorized_keys can allow only allowed operations.
- maybe also the directory with the backup whose
"restore" triggers the issue (don't forget to delete the contents of all the
PEM files in it!!, and note that data.mdb only contains public keys)
I will do that once I’ve triggered the error again.
I'd also have some more questions to make a
complete picture about the situation:
1) Is it possible that the issue is not really triggered by algorithm rollover, but by
Knot DNS version upgrade? Have you upgraded Knot DNS recently?
Last upgrade before the errors appeared was October 2nd 3.4.8 -> 3.5.0. The errors
start on November 24th,
when we started doing algorithm rollovers.
2) Do you use PKCS#11 is any way (either a HSM or
SoftHSM), or just PKCS#8 (PEM files directly accessed by Knot)?
Just PKCS#8.
3) Do you somehow clean up the destination Knot's
directories before calling zone-restore?
Yes, see attached scripts.
4) Do you somehow clean up the target directory on the
active signer before performing zone-backup into that directory (or you always create
fresh empty directory for the purpose)?
We run rsync with ‘—delete’ but do not clean the directory before syncing.
5) When manipulating with the backup directory, do you
somehow write its content into an existing directory with an older version of the backup
in it?
On the primary, the backup directory is cleaned completely before performing the backup.
Without doing anything to the backup directories, If I remove the /var/db/knot/keys
directory
on the secondary, and run sync, the problem goes away.
.einar