Greetings,
One thing I’m not sure about is exactly what happens when we run `knotc zone-ksk-submitted`?
Our parent zones don’t support CDS/CDNSKEY, so we manually update DS records and then
run `knotc zone-ksk-submitted`. It seems to me that as soon as we run it, the retiring of the outgoing
KSK key starts and it’s removed from the DNSKEY RRset. Is that correct?
I’d like to be sure, because as it is, I wait at least the TTL of the DS record before running zone-ksk-submitted,
if I run it right away and knot removes the key immediately from the DNSKEY RRset, then caching resolvers
will invalidate the zone.
The docs for knotc say:
Use when the zone's KSK rollover is in submission phase. By calling this command the user confirms manually that the parent zone contains DS record for the new KSK in submission phase and the old KSK can be retired. (#)
Reading the docs, I would think I should run zone-ksk-submitted as soon as the new DS record has been
published in the parent, but then knot would need to know to wait for the TTL of the DS record before
removing the key.
Should I wait before running zone-ksk-submitted, or is there a config option I’m missing to tell knot
the ds ttl?
.einar
Hi, I'm having issues with ACL's and DNS updates and multiple DNS servers.
I use DNS-01 for TLS letsencrypt and AXFR between the servers, but for some reason acme.sh is not working for a new server with "NOTAUTH" failures.
(I give acme.sh export KNOT_SERVER='souseiseki.middlendian.com' so that it uses the master and that works fine on the master and another server, but for some reason on the new one there is an ACL
related failure?);
[Thu 04 Dec 2025 21:53:49 AEDT] Adding _acme-challenge.middlendian.com. 60 TXT "<snip>"
;; ->>HEADER<<- opcode: UPDATE; status: NOTAUTH; id: 42945
;; Flags: qr; ZONE: 1; PREREQ: 0; UPDATE: 0; ADDITIONAL: 1
;; ZONE SECTION:
;; middlendian.com. IN SOA
;; ADDITIONAL DATA:
;; TSIG PSEUDOSECTION:
acme_key. 0 ANY TSIG hmac-sha512. 1764845629 300 64 <snip> 42945 NOERROR 0
;; ERROR: update failed with error 'NOTAUTH'
knsupdate works with the set key to the master;
knsupdate
knsupdate> server souseiseki.middlendian.com
knsupdate> key hmac-sha512:acme_key:<snip>
knsupdate> zone middlendian.com.
knsupdate> add test.middlendian.com. 300 TXT test
knsupdate> send
knsupdate> answer
But, the ACL seems to have problems, as DNS updates fail if attempted via any secondary server?;
knsupdate
knsupdate> server hinaichigo.middlendian.com
knsupdate> key hmac-sha512:acme_key:<snip>
knsupdate> zone middlendian.com.
knsupdate> del test.middlendian.com TXT
knsupdate> send
;; ->>HEADER<<- opcode: UPDATE; status: NOTAUTH; id: 14970
;; Flags: qr; ZONE: 1; PREREQ: 0; UPDATE: 0; ADDITIONAL: 1
;; ZONE SECTION:
;; middlendian.com. IN SOA
;; ADDITIONAL DATA:
;; TSIG PSEUDOSECTION:
acme_key. 0 ANY TSIG hmac-sha512. 1764844872 300 64 <snip> 14970 NOERROR 0
;; ERROR: update failed with error 'NOTAUTH'
Knot on souseiseki outputs an error to syslog; "ACL, denied, action update, remote 125.63.60.124@38966 TCP"
but that isn't helpful debug output, as it does not say why the ACL was denied.
IP address related matching could be a problem, but reviewing the documentation, it seems to state that IP addresses are not considered in ACL's unless listed in the ACL?
Does anyone know what the issue is and otherwise how do I debug it?
All the servers have the same ACL key set;
/etc/knot/acme.key;
key:
- id: acme_key
algorithm: hmac-sha512
secret: <snip>
souseiseki (master);
remote:
- id: suigintou
address: [ 180.150.27.133@53, 2403:5806:e8d0::dead:beef:cafe@53 ]
- id: hinaichigo
address: 125.63.60.124@53
include: "/etc/knot/acme.key"
acl:
- id: acme_acl
key: acme_key
action: update
zone:
- domain: middlendian.com
dnssec-signing: on
acl: acme_acl
notify: [ suigintou, hinaichigo ]
hinaichigo (secondary);
remote:
- id: master
address: 144.6.197.157@53
acl:
- id: acme_acl
key: acme_key
action: [update, notify]
zone:
- domain: middlendian.com
master: master
acl: acme_acl
--
Kind Regards, DiffieHellman
Hi,
In our setup, we have one active signer and one backup signer. Both use
softhsm, but only the active signer does automatic key management.
There is an hourly cron job that syncs keys from active to backup signer.
It runs knotc zone-backup on the active signer, only backing up the kaspdb.
It then syncs the files over to the secondary and runs knotc zone-restore.
This has been running for a few years now without problems.
These last two weeks we’ve been performing algorithm rollovers for
some of our zones, and after we run `knotc zone-ksk-submitted nic.is`
we start seeing these errors when the zone-restore is run on the backup:
error: [nic.is.] zone event 'backup/restore' failed (already exists)
warning: [nic.is.] zone restore failed (already exists)
warning: [nic.is.] restore, key copy failed (already exists)
I searched the knot dns source code, but couldn't find where these
errors are output. Like I said, we’ve been running like this for a few
years, doing regular ZSK rollovers, and a few KSK rollovers, without
problems. There’s something about the algorithm rollover that
causes this problem with our setup.
I assume I can just delete the keys on the secondary and sync again,
but I want to understand what causes these errors so we can avoid them
or at best document them in our process.
.einar
debian 12
knot 5
so i believe i have a server with antique data in cache. the net of a
million lies says use `kresctl clear foo` but i can not find kresctl.
clue bat please
randy
Hello,
I upgraded my signing server to Debian 13, but I have a problem with my HSM :
Oct 15 21:09:18 arrakeen knotd[29552]: error: [durel.org.] zone event 'load' failed (PKCS #11 token not available)
Oct 15 21:09:18 arrakeen knotd[29552]: error: [geekwu.org.] zone event 'load' failed (PKCS #11 token not available)
keymgr gives me the same error :
# keymgr geekwu.org list
error: failed to initialize KASP (PKCS #11 token not available)
despite hsmwiz being able to access the key :
# hsmwiz identify
Using reader with a card: Nitrokey Nitrokey HSM (DENK01067960000 ) 00 00
Version : 3.4
Config options :
User PIN reset with SO-PIN enabled
SO-PIN tries left : 15
User PIN tries left : 3
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Default SO-PIN: 3537363231383830 Default PIN: 648219
Now executing: pkcs15-tool --dump
Using reader with a card: Nitrokey Nitrokey HSM (DENK01067960000 ) 00 00
PKCS#15 Card [knot]:
Version : 0
Serial number : DENK0106796
Manufacturer ID: www.CardContact.de
Flags : PRN generation[...]
Public EC Key [Private Key]
Object Flags : [0x00]
Usage : [0x140], verify, derive
Access Flags : [0x02], extract
FieldLength : 384
Key ref : 0 (0x00)
Native : no
ID : 74f59bc17317bfccc5806108d84df1abd275faef
DirectValue : <present>
Knot is using this keystore :
keystore:
- id: nitrokey
backend: pkcs11
config: "pkcs11:pin-value=*** /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so"
I verified /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so still exists, and ldd doesn't report any missing dependency
strace let me see communication with pcscd, whose logs have these :
Oct 15 21:20:14 arrakeen systemd[1]: Started pcscd.service - PC/SC Smart Card Daemon.
Oct 15 21:20:20 arrakeen pcscd[33186]: 00000000 ../src/auth.c:166:IsClientAuthorized() Process 33204 (user: 134) is NOT authorized for action: access_pcsc
Oct 15 21:20:20 arrakeen pcscd[33186]: 00000071 ../src/winscard_svc.c:357:ContextThread() Rejected unauthorized PC/SC client
After a bit of digging, I found it's controlled by polkit, and added a brutal rule :
cat /etc/polkit-1/rules.d/pcsc.rules
/* -*- mode: js; js-indent-level: 4; indent-tabs-mode: nil -*- */
polkit.addRule(function(action, subject) { if (subject.isInGroup("pcsc")) { return polkit.Result.YES; } })
with knot added to the pcsc group, it can access the HSM again.
Do you know of a better way to configure ?
NB: I'm using another account, as I began to write this with no DNS server running
Regards,
--
Bastien Durel
Hi
We recently tried to upgrade to knot 3.5.0, but ran into a problem. It appears zones added via `conf-set include` are not working until knot is reloaded.
So to reduce calls to knotc when inserting a number of domains, we build a config fragment and then use `knotc conf-set include fragment.conf` to load it
With 3.4.8 this worked fine. For example:
# /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock status version
3.4.8
# dig +short foo.com @10.37.129.215 SOA
# cat > /local/knot_dns/zones/foo.com.zone <<EOF
foo.com. 3600 IN SOA ( ns1.fastmaildev.com.
postmaster.fastmaildev.com.
2025091802 ;serial
86133 ;refresh
600 ;retry
1209600 ;expire
3600 ;minimum
)
foo.com. 3600 IN NS ns1.fastmaildev.com.
foo.com. 3600 IN NS ns2.fastmaildev.com.
EOF
# cat > /tmp/zone.conf <<EOF
zone:
- domain: foo.com
template: "default"
EOF
# /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock conf-begin
OK
# /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock conf-set include /tmp/zone.conf
OK
# /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock conf-commit
OK
# dig +short foo.com @10.37.129.215 SOA
ns1.fastmaildev.com. postmaster.fastmaildev.com. 2025091802 86133 600 1209600 3600
As you can see, immediately after the `conf-commit`, the zone can be queried via dig.
However this doesn't work in 3.5.0.
# /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock status version
3.5.0
# dig +short foo2.com @10.37.129.215 SOA
# cat > /local/knot_dns/zones/foo2.com.zone <<EOF
foo2.com. 3600 IN SOA ( ns1.fastmaildev.com.
postmaster.fastmaildev.com.
2025091802 ;serial
86133 ;refresh
600 ;retry
1209600 ;expire
3600 ;minimum
)
foo2.com. 3600 IN NS ns1.fastmaildev.com.
foo2.com. 3600 IN NS ns2.fastmaildev.com.
EOF
# cat > /tmp/zone.conf <<EOF
zone:
- domain: foo2.com
template: "default"
EOF
# /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock conf-begin
OK
# /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock conf-set include /tmp/zone.conf
OK
# /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock conf-commit
OK
# dig +short foo2.com @10.37.129.215 SOA
# /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock zone-status foo2.com
error: [foo2.com] (no such zone found)
# /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock zone-reload foo2.com
error: [foo2.com] (no such zone found)
# /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock zone-check foo2.com
# /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock reload
Reloaded
# dig +short foo2.com @10.37.129.215 SOA
ns1.fastmaildev.com. postmaster.fastmaildev.com. 2025091802 86133 600 1209600 3600
# /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock zone-status foo2.com
[foo2.com.] role: master | serial: 2025091802
As you can see, after the `conf-commit` the zone isn't visible in knot at all, either via dig or even via knotc commands `zone-status` or `zone-reload`. However immediately after a knot server `reload`, it does become visible.
This feels like a bug and regression in 3.5.0 to me, or am I holding something wrong?
Rob Mueller
robm(a)fastmail.com
I am definitely interested in examples!
Reading up on groups, is it that 'group A' may represent 'customer A'
and have a specific set of Primary/Master nameservers, Group B ==
Customer B, different Primary, and so on?
(also fixed to be plain text - hope this is more legible in the archives)
--Chris
