Hello,
Recently, my hidden master has had two upgrades: one from 3.6.0 to
3.6.1, and another from 3.6.1 to 3.6.2.
I found that the time between "Knot DNS 3.X.Y starting" and "server
started answering" has increased significantly for versions 3.6.1 and 3.6.2.
I have a large DNSSEC-signed zone with about 2,700,000 records, and I
have set |dnssec-validation|to |on|. For versions 3.5.8 and 3.6.0, it
took about 4 minutes to restart; after 3.6.1, it took 47–48 minutes.
Best Regards,
SUN Guonian
Hi,
I'm seeking some clarity over the semantics of 'knotc conf-import'. I'm using
v3.6.1, specifically. When using the +nopurge filter with an existing
configuration database, the operation fails without the use of the -f (force)
option. I'm unclear on the intended semantics. Does +nopurge merge
configuration in the database with settings imported from the file, or does it
just skip the import altogether? Why is the force option required?
$ knotc -f conf-import /usr/local/etc/knot/knot.conf +nopurge
error: use force option to modify/overwrite the existing destination and ensure
the server is not running!
Thanks,
B.C.
Hello,
For a little while, I often see these kind of messages in knot:
oct. 18 06:49:12 arrakeen knotd[1636735]: error: [geekwu.org.] DNSSEC, failed to initialize signing context (PKCS #11 token not available)
When this happens, signature stops, and I only get notified by my monitoring when they're expired :/
Restarting knot is sufficent to get signing running again - no intervention needed on the HSM, the pkcs interface or anything like that.
Do you have an idea of what could happening? How to debug this? (I surely can monitor logs for this message, but it's kind of a pain)
Best regards,
BTW, here's my HSM:
# sudo -u knot pkcs11-tool --module /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so --list-slots
Available slots:
Slot 0 (0x0): Nitrokey Nitrokey HSM (DENK01067960000 ) 00 00
token label : knot
token manufacturer : www.CardContact.dehttp://www.cardcontact.de/
token model : PKCS#15 emulated
token flags : login required, rng, token initialized, PIN initialized
hardware version : 24.13
firmware version : 3.4
serial num : DENK0106796
pin min/max : 6/15
uri : pkcs11:model=PKCS%2315%20emulated;manufacturer=www.CardContact.de;serial=DENK0106796;token=knot http://www.cardcontact.de;serial=denk0106796;token=knot/
Dear Knot developers,
Our Knot DNS systemd unit files do not currently have a "Type"
attribute, so it defaults to "simple". This works quite well. However,
we can set "Type" to one of "notify" or "notify-reload" for better
systemd integration.
For this, Knot DNS needs to support the READY=1, STOPPING=1, RELOADING=1
messages using sd_notify.
Could you please clarify which messages Knot DNS sends?
Regards,
Anand Buddhdev
RIPE NCC
Hello,
I see in the directory with zones and journal I see directories journal.<timestamp>.bak (same for keys and timers) and files journal.<timestamp>.export
time stamp and file date are the moment of upgrade from a knot compiled with lmdb0 to a knot compiled with lmdb1
Can I remove those files or directory ? (I suspect they are used during conversion of mdb files)
--
Erwan David
Since upgrade to knot 3.6, when I restart the knot server, a new serial is generated for the secondary zones,
putting them out of sync with the primary.
Logs in 3.5
Aug 25 10:31:50 ns knot[45038]: info: [domain.] zone will be loaded
Aug 25 10:31:51 ns knot[45038]: info: [domain.] zone loaded from journal, serial 2026023115
Aug 25 10:31:51 ns knot[45038]: info: [domain.] zone file loaded, serial updated 2026023115 -> 2026082500
Aug 25 10:31:51 ns knot[45038]: info: [domain.] loaded, serial none -> 2026082500 -> 2026023115, 21088 bytes, expires in 2137390 seconds
Last line show the serial is set back to the serial of the journal loaded zone
When starting 3.6
Sep 24 07:49:14 ns knot[23114]: info: [domain.] zone will be loaded
Sep 24 07:49:14 ns knot[23114]: info: [domain.] zone loaded from journal, serial 2026023175
Sep 24 07:49:14 ns knot[23114]: info: [domain.] zone file loaded, serial updated 2026023175 -> 2026092400
Sep 24 07:49:14 ns knot[23114]: info: [domain.] loaded, serial none -> 2026092400, 21088 bytes, expires in 2158298 seconds
The serial is not set back to the serail from the journal. As you can see in this case the primary does not use a date based serial number,
thus the secondary is then out of sync and refuses the notifications
--
Erwan David
