Hi,
I'm evaluating the Knot DNS server as a DNSSEC signer engine. I'm
currently running version 3.2.6 together with SoftHSM version 2.6.1 on
an Ubuntu 20.04 linux server.
Now I have a problem with keymgr crashing with a segmentation fault
and dumping core. This happens with some of the commands of keymgr,
but not all (the command keymgr -l runs fine). The commands 'keymgr
trondheim.no list' produces the correct output, but then crashes.
/var/log/apport.log indicates that a dbus session is missing in the
environment:
ERROR: apport (pid 811054) Tue Jun 13 07:56:00 2023: called for pid
811052, signal 11, core limit 0, dump mode 2
ERROR: apport (pid 811054) Tue Jun 13 07:56:00 2023: not creating core
for pid with dump mode of 2
ERROR: apport (pid 811054) Tue Jun 13 07:56:00 2023: executable:
/usr/sbin/keymgr (command line "keymgr trondheim.no list")
ERROR: apport (pid 811054) Tue Jun 13 07:56:00 2023:
is_closing_session(): no DBUS_SESSION_BUS_ADDRESS in environment
ERROR: apport (pid 811054) Tue Jun 13 07:56:00 2023: apport: report
/var/crash/_usr_sbin_keymgr.0.crash already exists and unseen,
skipping to avoid disk usage DoS
Running the command as 'dbus-run-session keymgr trondheim.no list' gives:
ERROR: apport (pid 811174) Tue Jun 13 08:01:04 2023: called for pid
811173, signal 11, core limit 0, dump mode 2
ERROR: apport (pid 811174) Tue Jun 13 08:01:04 2023: not creating core
for pid with dump mode of 2
ERROR: apport (pid 811174) Tue Jun 13 08:01:04 2023: executable:
/usr/sbin/keymgr (command line "keymgr trondheim.no list")
ERROR: apport (pid 811174) Tue Jun 13 08:01:04 2023:
is_closing_session(): Could not determine DBUS socket.
ERROR: apport (pid 811174) Tue Jun 13 08:01:04 2023: apport: report
/var/crash/_usr_sbin_keymgr.0.crash already exists and unseen,
skipping to avoid disk usage DoS
I've tried to run the command as root and as the knot user, and I have
to admit that I'm not very familiar with how to manage dbus sessions.
I want to run the keymgr command from cron or from some other system
shell, for periodically monitoring the keys. However, I'm unsure why
keymgr wants to communicate on the dbus. Is it possible to disable this?
Regards,
Erik Østlyngen
Subject: GUI Frontends for Knot DNS Server
Good day from Singapore,
Are there any GUI frontends for configuring Knot DNS Server?
I prefer GUI configuration interface. It is more efficient than
command line interface (CLI).
Thank you.
Regards,
Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore
Blogs:
https://tdtemcerts.blogspot.comhttps://tdtemcerts.wordpress.com
Hey,
after an (unattended) upgrade to 3.2,7, one of my zones (the one that does
rapid KSK rollovers) failed to load. Trying ro reload emits these errors in
the log:
info: [83.204.91.in-addr.arpa.] zone file parsed, serial 1622013488
error: [83.204.91.in-addr.arpa.] failed to apply journal changes, serial
1622013488 -> 1686209286 (loop detected)
2023-06-23T12:11:57+0200 error: [83.204.91.in-addr.arpa.] failed to apply
journal changes, serial 1622013488 -> 1686209286 (loop detected)
warning: [83.204.91.in-addr.arpa.] failed to load journal (loop detected)
2023-06-23T12:11:57+0200 warning: [83.204.91.in-addr.arpa.] failed to load
journal (loop detected)
info: [83.204.91.in-addr.arpa.] zone not found
error: [83.204.91.in-addr.arpa.] zone event 'load' failed (not exists)
2023-06-23T12:11:57+0200 error: [83.204.91.in-addr.arpa.] zone event 'load'
failed (not exists)
Calling `kjournalprint 83.204.91.in-addr.arpa` yields 600 lines of journal
full of both additions and deletions, nothing seems particularly wrong. Is
there anything I should try before purging the journal and starting from
scratch?
There are other zones on the same server with similar config that just work
normally, so I guess this is somehow related to the size of the journal for
this zone, which rotates DNSSEC keys very often.
--
Cheers,
Ondřej Caletka
The 3.0 documentation for catalog zones says the following:
«The difference is that standard DNS queries to a catalog zone are
answered with REFUSED as though the zone doesn’t exist, unless
querying over TCP from an address with transfers enabled by ACL.»
This seems like an odd requirement, and it breaks interoperability
with other vendors' authoritative servers. BIND, for example, does
not send the SOA check for a zone transfer over TCP, and so it's
impossible to use a Knot primary and BIND secondary with catalog
zones.
Is there some way to work around this?
