Hello,
I have an issue with a behaviour change in knot 3.4.1.
Before 3.4.1, trying to send a conf-abort command using knotc to knot when there was no pending transaction properly returned an error, but since 3.4.1, instead of receiving an error, the connection hangs, and failed after a timeout.
Some digging shows that this is due to a change in commit 69328dd7799253978605f7dac29175945971e63f
Instead of returning and error as it should, ctl_process skip the command processing when it does not expect a conf-abort command.
Is this a bug, or is this behaviour intended ?
Just to give you some context about my use case, I wrote a daemon that is using libknot to sync the dns configuration, and as knot does not supports multiple transaction, it has to make sure there is no dangling transaction before trying to apply changes (in case the daemon did crash while applying a previous change). Until 3.4.1, it did that by simply sending a conf-abort before starting the new transaction.
Thanks
Hi Guys,
a happy new year to all of you!
Due to policy reasons we need to make knot use a HSM in the future. Is
anybody successfully using some cloud based HSM services like Google
Cloud HSM for DNSSEC signing?
Any information is helpful, thanks!
BR
Thomas
Hello,
My knot 3.4.3 gives me following notice :
notice: config, policy 'rail_policy' depends on default nsec3-salt-length=8, since version 3.5 the default becomes 0
In order to avoid problems when .5 will arrive, I see 2 possibilities:
* add an explicit nsec3-salt-length=8 to my policy
* add an explicit nsec3-salt-length=0 to my policy and resign the
zone.
From https://www.ietf.org/archive/id/draft-ietf-dnsop-nsec3-guidance-10.html#nam…
I understand that 0 should be the new configuration, but what are the
risks (considering eg. DNS caches) if I change the policy of the zone?
I only have small zones, with very few dynamic changes, which I can
delay for the time of the TTL if needed.
--
Erwan David
Hi,
I'm running an instance of knotd for testing. It is installed with the
official ubuntu debian package from kont-dns.cz. When I start the knot
service, using systemctl, it takes a very long time to start up
(sometimes 30 min). This seems to be related to the systemd unit which
is set to type 'notify', and the fact that knot after starting up
wants to re-sign all the zones which needs that before notifying. If I
change the type to 'simple' or 'forked' (together with the knotd -d
option), the start command returns more immediately. My test system
has about 800 zonefiles in it. A large number of them want to be
re-signed after each startup.
My question is, what is the recommended way to start, stop and restart
the server? Also, after starting I cannot find the /run/knot/knot.sock
file, which is needed when stopping the service with 'knotc stop'.
Knot version: 3.4.1-cznic.1~focal (debian package from knot-dns.cz)
OS: Linux 5.4.0/Ubuntu 20.04 Focal amd64.
Kind regards,
Erik Østlyngen
Norid
Hello Daniel,
Are the EPEL packages no longer available (?), I'm stuck at 3.3.9. There have
been no updates since then. Or can you download the .rpm from somewhere else
now?
--
mit freundlichen Grüßen / best regards
Günther J. Niederwimmer
