8 Lis
2024
8 Lis
'24
9:50
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
8 Lis
8 Lis
10:14
Hi Erik,
You shouldn't change the service type (Type=notify). That's why you don't
see knot.sock IMO.
You can enable https://www.knot-dns.cz/docs/3.4/singlehtml/index.html#async-start,
which helps with the long startup. However, Knot will still not be able to respond
from the zones until they are fully loaded!
What is your CPU? Maybe you should optimize the configuration (e.g.
https://www.knot-dns.cz/docs/3.4/singlehtml/index.html#signing-threads,
and/or https://www.knot-dns.cz/docs/3.4/singlehtml/index.html#server-background-wo…).
800 zones isn't much. Are the zones huge? Or do you use an HSM?
Daniel
On 11/8/24 09:50, Erik P. Ostlyngen via knot-dns-users wrote:
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
--
11:03
Hi Daniel,
The async-start option solved the start/stop problems. Thanks for the
help.
About the performance of the signing: I'm running 4 signer threads on
a VM with 2 CPUs, 2.70GHz each. Most of the zones are very small (< 20
signatures) but one of them has about 3.5M records and 600k
signatures. The big zone is slower than the rest but not terribly
much. Most of the time is used for signing all the small zones. I'm
using SoftHSM, so it might be part the reason.
Kind regards,
Erik Østlyngen
Norid
On 08.11.2024 10:14, Daniel Salzman wrote:
Hi Erik,
You shouldn't change the service type (Type=notify). That's why
you don't see knot.sock IMO.
You can enable
https://www.knot-dns.cz/docs/3.4/singlehtml/index.html#async-start,
which helps with the long startup. However, Knot will still not be
able to respond from the zones until they are fully
loaded!
What is your CPU? Maybe you should optimize the configuration (e.g.
https://www.knot-dns.cz/docs/3.4/singlehtml/index.html#signing-threads,
and/or
800 zones isn't much. Are the zones huge? Or do you use an HSM?
Daniel
On 11/8/24 09:50, Erik P. Ostlyngen via knot-dns-users wrote:
> 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 --
14:07
Erik,
On 11/8/24 11:03, Erik P. Ostlyngen wrote:
Hi Daniel,
The async-start option solved the start/stop problems. Thanks for the
help.
About the performance of the signing: I'm running 4 signer threads on
a VM with 2 CPUs, 2.70GHz each. Most of the zones are very small (< 20
signatures) but one of them has about 3.5M records and 600k
signatures. The big zone is slower than the rest but not terribly
much. Most of the time is used for signing all the small zones. I'm
using SoftHSM, so it might be part the reason.
In my opinion, it's not a good idea to allocate insufficient resources (CPU cores)
to a signing primary. Especially if you require regular zone re-signing.
Also, SoftHSM has no security benefit and only slows down crypto operations (signing).
At least for the big zone try setting signing-threads to 2.
Daniel
Kind regards,
Erik Østlyngen
Norid
On 08.11.2024 10:14, Daniel Salzman wrote:
Hi Erik,
You shouldn't change the service type (Type=notify). That's why
you don't see knot.sock IMO.
You can enable https://www.knot-dns.cz/docs/3.4/singlehtml/index.html#async-start,
which helps with the long startup. However, Knot will still not be
able to respond from the zones until they are
fully loaded!
What is your CPU? Maybe you should optimize the configuration (e.g.
https://www.knot-dns.cz/docs/3.4/singlehtml/index.html#signing-threads,
and/or
800 zones isn't much. Are the zones huge? Or do you use an HSM?
Daniel
On 11/8/24 09:50, Erik P. Ostlyngen via knot-dns-users wrote:
> 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 --
14:31
Just a note, the crypto performance usually differs between GnuTLS (PEM keystore) and
OpenSSL (SoftHSM).
You can test it using `keymgr keystore-bench`.
On 11/8/24 14:07, Daniel Salzman via knot-dns-users wrote:
Erik,
On 11/8/24 11:03, Erik P. Ostlyngen wrote:
Hi Daniel,
The async-start option solved the start/stop problems. Thanks for the
help.
About the performance of the signing: I'm running 4 signer threads on
a VM with 2 CPUs, 2.70GHz each. Most of the zones are very small (< 20
signatures) but one of them has about 3.5M records and 600k
signatures. The big zone is slower than the rest but not terribly
much. Most of the time is used for signing all the small zones. I'm
using SoftHSM, so it might be part the reason.
In my opinion, it's not a good idea to allocate insufficient resources (CPU cores)
to a signing primary. Especially if you require regular zone re-signing.
Also, SoftHSM has no security benefit and only slows down crypto operations (signing).
At least for the big zone try setting signing-threads to 2.
Daniel
Kind regards,
Erik Østlyngen
Norid
On 08.11.2024 10:14, Daniel Salzman wrote:
-- Hi Erik,
You shouldn't change the service type (Type=notify). That's why
you don't see knot.sock IMO.
You can enable https://www.knot-dns.cz/docs/3.4/singlehtml/index.html#async-start,
which helps with the long startup. However, Knot will still not be
able to respond from the zones until they are
fully loaded!
What is your CPU? Maybe you should optimize the configuration (e.g.
https://www.knot-dns.cz/docs/3.4/singlehtml/index.html#signing-threads,
and/or
800 zones isn't much. Are the zones huge? Or do you use an HSM?
Daniel
On 11/8/24 09:50, Erik P. Ostlyngen via knot-dns-users wrote:
> 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 --
5
days inactive
5
days old
4 comments
2 participants
participants (2)
-
Daniel Salzman -
Erik P. Ostlyngen