Hi folks,
Is it possible to chain multiple upstream catalog zones into one downstream one?
I do have the following topology:
Multiple DNS hidden masters <-> DNS signer / DNS master for public facing slaves <-> public facing slaves
Can I define catalog zones on hidden masters and use them on public-facing signer/master to compose a catalog zone for the slaves?
Best Regards,
Martin Hunek
Freenet Liberec, z.s.
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
Daniel Salzman wrote:
> Hello Knot DNS users,
>
> CZ.NIC has released Knot DNS 3.3.2!
>
> This version fixes various issues and introduces some features regarding IXFR.
> Users of PKCS #11 keystore might appreciate improved signing performance using more thread.
>
> Note that the offline KSK mode requires explicit setting of `rrsig-refresh` on the KSK side!
>
> Changelog:
> https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.3.2/NEWS
Hi,
I'm interested in this change:
- knotd: failed to sign RRSet that fits to 64k only if compressed
Which seems to be this commit:
https://gitlab.nic.cz/knot/knot-dns/-/commit/f55037f6f39d0ddf6debac47fe168d…
"libknot/knot: allow uncompressed wire conversion of rrset that fits to
64k only when compressed"
It's not totally clear to me, but it seems like this would allow an
RRset (or individual RR, if the number of RRs in the RRset is 1?) that,
exceeds 64K, if name compression would reduce the size on the wire to
<64K? (And the 64K isn't measured by just the RDATA/RDLEN fields, but
rather the whole wire serialization of the record set, including owner
name, type, class, TTL, etc.)
If so, is this a safe and/or interoperable thing to do? DNS
implementations are required to implement decompression, but compression
is optional (RFC 1035 § 4.1.4). So a resolver might receive a compressed
RRset, decompress it, and then be unable to represent that RRset to
clients if it doesn't implement compression, or, more likely, implements
compression but uses an algorithm that generates less optimal
compression targets than the one used by the original nameserver.
Or am I misunderstanding what this commit is doing?
Thanks!
--
Robert Edmonds
edmonds(a)debian.org
