22 Říj
2026
22 Říj
'26
12:31
Hello,
Recently, my hidden master has had two upgrades: one from 3.6.0 to
3.6.1, and another from 3.6.1 to 3.6.2.
I found that the time between "Knot DNS 3.X.Y starting" and "server
started answering" has increased significantly for versions 3.6.1 and 3.6.2.
I have a large DNSSEC-signed zone with about 2,700,000 records, and I
have set |dnssec-validation|to |on|. For versions 3.5.8 and 3.6.0, it
took about 4 minutes to restart; after 3.6.1, it took 47–48 minutes.
Best Regards,
SUN Guonian
22 Říj
22 Říj
13:52
Hello!
Thank you for the report. We will investigate the cause.
Daniel
On 10/22/26 12:31, SUN Guonian via knot-dns-users wrote:
Hello,
Recently, my hidden master has had two upgrades: one from 3.6.0 to 3.6.1, and another
from 3.6.1 to 3.6.2.
I found that the time between "Knot DNS 3.X.Y starting" and "server
started answering" has increased significantly for versions 3.6.1 and 3.6.2.
I have a large DNSSEC-signed zone with about 2,700,000 records, and I have set
|dnssec-validation|to |on|. For versions 3.5.8 and 3.6.0, it took about 4 minutes to
restart; after 3.6.1, it took 47–48 minutes.
Best Regards,
SUN Guonian
--
14:35
Hello,
on first sight, the issue doesn't seem so obvious. Could you please
share more information?
1) does incremental validation take place in your case, or full zone
validation? You can see this in the log file, either there is "DNSSEC,
incremental validation successful, checked RRSIGs XY" or the word
"incremental" is missing
2) does the zone use NSEC, NSEC3 or NSEC3 with opt-out? Which DNSSEC
algorithm?
3) any other particular specifics
Thank you!
Libor
On 22. 10. 26 13:52, Daniel Salzman via knot-dns-users wrote:
Hello!
Thank you for the report. We will investigate the cause.
Daniel
On 10/22/26 12:31, SUN Guonian via knot-dns-users wrote:
Hello,
Recently, my hidden master has had two upgrades: one from 3.6.0 to
3.6.1, and another from 3.6.1 to 3.6.2.
I found that the time between "Knot DNS 3.X.Y starting" and "server
started answering" has increased significantly for versions 3.6.1 and
3.6.2.
I have a large DNSSEC-signed zone with about 2,700,000 records, and I
have set |dnssec-validation|to |on|. For versions 3.5.8 and 3.6.0, it
took about 4 minutes to restart; after 3.6.1, it took 47–48 minutes.
Best Regards,
SUN Guonian
--
--
23 Říj
23 Říj
3:28
Hello,
The answers are:
1) incremental validation.
2) NSEC3, ecdsap256sha256 (algorithm 13).
3) It does not sign zones, just validate zones. It's a slave of the
signature server. For this large zone, I enlarge the |journal-max-usage|
to |8G|.
Thank you!
Best Regards,
SUN Guonian
在 2026/10/22 20:35, Libor Peltan via knot-dns-users 写道:
Hello,
on first sight, the issue doesn't seem so obvious. Could you please
share more information?
1) does incremental validation take place in your case, or full zone
validation? You can see this in the log file, either there is "DNSSEC,
incremental validation successful, checked RRSIGs XY" or the word
"incremental" is missing
2) does the zone use NSEC, NSEC3 or NSEC3 with opt-out? Which DNSSEC
algorithm?
3) any other particular specifics
Thank you!
Libor
On 22. 10. 26 13:52, Daniel Salzman via knot-dns-users wrote:
--
运维部 孙国念（电话：13501330206 QQ/微信：17355924）
===================================================
互联网域名系统北京市工程研究中心有限公司（ZDNS.CN）
北京市朝阳区望京东园四区7号楼绿地中心B座21层
【使命】让网络根基更安全、更高效、更智能
【愿景】成为互联网关键基础资源服务领域的全球领先者
===================================================
Hello!
Thank you for the report. We will investigate the cause.
Daniel
On 10/22/26 12:31, SUN Guonian via knot-dns-users wrote:
-- Hello,
Recently, my hidden master has had two upgrades: one from 3.6.0 to
3.6.1, and another from 3.6.1 to 3.6.2.
I found that the time between "Knot DNS 3.X.Y starting" and "server
started answering" has increased significantly for versions 3.6.1
and 3.6.2.
I have a large DNSSEC-signed zone with about 2,700,000 records, and
I have set |dnssec-validation|to |on|. For versions 3.5.8 and 3.6.0,
it took about 4 minutes to restart; after 3.6.1, it took 47–48 minutes.
Best Regards,
SUN Guonian
--
--
11:14
Hello,
thank you for the info. However, we were still not able to see such
issue. Could you please clarify more?
ad 1) in fact, I haven't seen a setup where "incremental validation"
takes place at server startup, before "server started answering". Are
you sure?
4) could you please provide some log snippet from the server starting,
highlighting the affected zone?
5) could you also provide the zone-relevant configuration, such as
zonefile-load, zonefile-sync, journal-content ?
6) if we don't succeed to replicate your setup and your issue, would you
be willing to self-investigate the validation speed, using some profiler?
Thank you,
Libor
On 23. 10. 26 3:28, SUN Guonian via knot-dns-users wrote:
Hello,
The answers are:
1) incremental validation.
2) NSEC3, ecdsap256sha256 (algorithm 13).
3) It does not sign zones, just validate zones. It's a slave of the
signature server. For this large zone, I enlarge the
|journal-max-usage| to |8G|.
Thank you!
Best Regards,
SUN Guonian
在 2026/10/22 20:35, Libor Peltan via knot-dns-users 写道:
Hello,
on first sight, the issue doesn't seem so obvious. Could you please
share more information?
1) does incremental validation take place in your case, or full zone
validation? You can see this in the log file, either there is
"DNSSEC, incremental validation successful, checked RRSIGs XY" or the
word "incremental" is missing
2) does the zone use NSEC, NSEC3 or NSEC3 with opt-out? Which DNSSEC
algorithm?
3) any other particular specifics
Thank you!
Libor
On 22. 10. 26 13:52, Daniel Salzman via knot-dns-users wrote:
Hello!
Thank you for the report. We will investigate the cause.
Daniel
On 10/22/26 12:31, SUN Guonian via knot-dns-users wrote:
-- Hello,
Recently, my hidden master has had two upgrades: one from 3.6.0 to
3.6.1, and another from 3.6.1 to 3.6.2.
I found that the time between "Knot DNS 3.X.Y starting" and "server
started answering" has increased significantly for versions 3.6.1
and 3.6.2.
I have a large DNSSEC-signed zone with about 2,700,000 records, and
I have set |dnssec-validation|to |on|. For versions 3.5.8 and
3.6.0, it took about 4 minutes to restart; after 3.6.1, it took
47–48 minutes.
Best Regards,
SUN Guonian
--
--
26 Říj
26 Říj
11:46
Hello,
Sorry to reply lately. I tried to replicate the case, but failed.
1) I see "incrementtal validation successful" and "validation
successful" both, the former was behind the string "server started
answering", and the latter was before the "answering" string.
4) I could only find some history log. The system is rockylinux x86_64
8.10.
2026-01-21T13:31:19+0800 info: Knot DNS 3.5.3 starting
2026-01-21T13:34:51+0800 info: server started answering # 3:32
2026-04-06T18:23:51+0800 info: Knot DNS 3.5.4 starting
2026-04-06T18:23:51+0800 info: server started answering # Maybe I clean
the data
2026-05-12T16:11:37+0800 info: Knot DNS 3.5.4 starting
2026-05-12T16:16:04+0800 info: server started answering # 4:27
(* about 2026/06/25 11:01:44, reboot the system *)
2026-06-25T11:15:53+0800 info: Knot DNS 3.5.5 starting
2026-06-25T11:19:57+0800 info: server started answering # 4:04
2026-07-21T10:55:48+0800 info: Knot DNS 3.5.6 starting
2026-07-21T10:59:45+0800 info: server started answering # 3:57
2026-08-19T11:01:27+0800 info: Knot DNS 3.5.7 starting
2026-08-19T11:05:22+0800 info: server started answering # 3:55
2026-09-07T11:40:40+0800 info: Knot DNS 3.5.8 starting
2026-09-07T11:44:34+0800 info: server started answering # 3:54
2026-09-16T10:52:23.685+08:00 info: Knot DNS 3.6.0 starting
2026-09-16T10:56:18.302+08:00 info: server started answering # 3:55
2026-10-10T17:15:58.143+08:00 info: Knot DNS 3.6.1 starting # wait
about 10 minutes, kill it
2026-10-10T18:20:32.966+08:00 info: Knot DNS 3.6.0 starting #
downgrade and clean the data
2026-10-10T18:20:33.011+08:00 info: server started answering
2026-10-22T16:18:55.595+08:00 info: Knot DNS 3.6.1 starting
2026-10-22T17:06:18.750+08:00 info: server started answering # 47:23
2026-10-22T17:09:19.809+08:00 info: Knot DNS 3.6.2 starting
2026-10-22T17:56:41.011+08:00 info: server started answering # 47:22
===========
2026-09-16T10:51:50+0800 info: control, received command 'stop'
2026-09-16T10:51:50+0800 info: stopping server
2026-09-16T10:51:52+0800 info: updated persistent timer DB
2026-09-16T10:52:09+0800 info: shutting down
2026-09-16T10:52:23.685+08:00 info: Knot DNS 3.6.0 starting
2026-09-16T10:52:23.685+08:00 info: loaded configuration file
'/home/knot/etc/knot.conf', mapsize 500 MiB
2026-09-16T10:52:23.685+08:00 info: using UDP reuseport, socket affinity
2026-09-16T10:52:23.686+08:00 info: binding to interface 192.168.8.164@5353
2026-09-16T10:52:23.690+08:00 info: changing GID to 1000
2026-09-16T10:52:23.690+08:00 info: changing UID to 1000
2026-09-16T10:52:23.691+08:00 info: process not allowed to set
capabilities, skipping
2026-09-16T10:52:23.697+08:00 info: changed directory to /
2026-09-16T10:52:23.697+08:00 info: loading 7 zones
2026-09-16T10:52:23.698+08:00 info: [DOMAIN.] zone will be loaded
2026-09-16T10:52:23.727+08:00 info: control, binding to
'/home/knot/var/run/knot.sock'
2026-09-16T10:52:23.727+08:00 info: starting server as a daemon, PID 3096545
2026-09-16T10:53:36.882+08:00 info: [DOMAIN.] zone file loaded, serial
1789526408
2026-09-16T10:53:36.894+08:00 info: [DOMAIN.] changes from journal
applied, serial 1789526408 -> 1789527023
2026-09-16T10:56:18.196+08:00 info: [DOMAIN.] DNSSEC, validation
successful, checked RRSIGs 13197105
2026-09-16T10:56:18.196+08:00 info: [DOMAIN.] loaded, serial none ->
1789527023, 2437384334 bytes, expires in 597436 seconds
2026-09-16T10:56:18.302+08:00 info: server started answering
2026-09-16T10:56:18.444+08:00 info: [DOMAIN.] IXFR, outgoing, remote
SLAVE_IP@38922 TCP, key transferkey., zone is up-to-date, serial 1789527023
2026-09-16T10:56:18.444+08:00 info: [DOMAIN.] notify, incoming, remote
MASTER_IP@10384 TCP, serial 1789527120
2026-09-16T10:56:18.447+08:00 info: [DOMAIN.] refresh, remote
MASTER_IP@5353, key transferkey., remote serial 1789527317, zone is outdated
2026-09-16T10:56:18.449+08:00 info: [DOMAIN.] IXFR, incoming, remote
MASTER_IP@5353 TCP, key transferkey., started
2026-09-16T10:56:18.461+08:00 info: [DOMAIN.] IXFR, incoming, remote
MASTER_IP@5353 TCP, key transferkey., finished, remote serial
1789527317, 0.01 seconds, 9 messages, 149001 bytes
2026-09-16T10:56:22.841+08:00 info: [DOMAIN.] DNSSEC, incremental
validation successful, checked RRSIGs 477
2026-09-16T10:56:22.844+08:00 info: [DOMAIN.] refresh, remote
MASTER_IP@5353, key transferkey., zone updated, 4.40 seconds, serial
1789527023 -> 1789527108, expires in 597432 seconds
5)
template:
- id: slave
storage: /home/knot/zone
module: mod-stats
master: group_master
dnssec-validation: on
acl: [ notify_from_master, permit_transfer ]
notify: [ notify_group ]
ixfr-by-one: on
zonefile-sync: 900
zone:
- domain: DOMAIN
template: slave
file: DOMAIN.zone
journal-max-usage: 8G
journal-max-depth: 4000
6) I will try to replicate it first.
Thank you.
Best Regards,
SUN Guonian
在 2026/10/23 17:14, Libor Peltan via knot-dns-users 写道:
Hello,
thank you for the info. However, we were still not able to see such
issue. Could you please clarify more?
ad 1) in fact, I haven't seen a setup where "incremental validation"
takes place at server startup, before "server started answering". Are
you sure?
4) could you please provide some log snippet from the server starting,
highlighting the affected zone?
5) could you also provide the zone-relevant configuration, such as
zonefile-load, zonefile-sync, journal-content ?
6) if we don't succeed to replicate your setup and your issue, would
you be willing to self-investigate the validation speed, using some
profiler?
Thank you,
Libor
On 23. 10. 26 3:28, SUN Guonian via knot-dns-users wrote:
> Hello,
>
> The answers are:
>
> 1) incremental validation.
>
> 2) NSEC3, ecdsap256sha256 (algorithm 13).
>
> 3) It does not sign zones, just validate zones. It's a slave of the
> signature server. For this large zone, I enlarge the
> |journal-max-usage| to |8G|.
>
> Thank you!
>
>
> Best Regards,
>
> SUN Guonian
>
>
> 在 2026/10/22 20:35, Libor Peltan via knot-dns-users 写道:
>> Hello,
>>
>> on first sight, the issue doesn't seem so obvious. Could you please
>> share more information?
>>
>> 1) does incremental validation take place in your case, or full zone
>> validation? You can see this in the log file, either there is
>> "DNSSEC, incremental validation successful, checked RRSIGs XY" or
>> the word "incremental" is missing
>>
>> 2) does the zone use NSEC, NSEC3 or NSEC3 with opt-out? Which DNSSEC
>> algorithm?
>>
>> 3) any other particular specifics
>>
>> Thank you!
>>
>> Libor
>>
>> On 22. 10. 26 13:52, Daniel Salzman via knot-dns-users wrote:
>>> Hello!
>>>
>>> Thank you for the report. We will investigate the cause.
>>>
>>> Daniel
>>>
>>> On 10/22/26 12:31, SUN Guonian via knot-dns-users wrote:
>>>> Hello,
>>>>
>>>> Recently, my hidden master has had two upgrades: one from 3.6.0 to
>>>> 3.6.1, and another from 3.6.1 to 3.6.2.
>>>>
>>>> I found that the time between "Knot DNS 3.X.Y starting" and
>>>> "server started answering" has increased significantly for
>>>> versions 3.6.1 and 3.6.2.
>>>>
>>>> I have a large DNSSEC-signed zone with about 2,700,000 records,
>>>> and I have set |dnssec-validation|to |on|. For versions 3.5.8 and
>>>> 3.6.0, it took about 4 minutes to restart; after 3.6.1, it took
>>>> 47–48 minutes.
>>>>
>>>> Best Regards,
>>>>
>>>> SUN Guonian
22 Říj
22 Říj
15:14
I don't see any regression between 3.6.0 and 3.6.1.
Do you always use the same configuration (especially policy.signing-threads)?
Do you build Knots the same way?
Daniel
On 10/22/26 13:52, Daniel Salzman via knot-dns-users wrote:
Hello!
Thank you for the report. We will investigate the cause.
Daniel
On 10/22/26 12:31, SUN Guonian via knot-dns-users wrote:
Hello,
Recently, my hidden master has had two upgrades: one from 3.6.0 to 3.6.1, and another
from 3.6.1 to 3.6.2.
I found that the time between "Knot DNS 3.X.Y starting" and "server
started answering" has increased significantly for versions 3.6.1 and 3.6.2.
I have a large DNSSEC-signed zone with about 2,700,000 records, and I have set
|dnssec-validation|to |on|. For versions 3.5.8 and 3.6.0, it took about 4 minutes to
restart; after 3.6.1, it took 47–48 minutes.
Best Regards,
SUN Guonian
--
--
23 Říj
23 Říj
3:41
Daniel,
Since it does not sign the zone, it's a slave of the signature server, I
didn't modify the policy.signing-threads (and adjust-threads).
I notice that the top CPU usage of the knotd process is no more than
100% in this period, it seems that the validation worker is only one.
Thank you!
Best Regards,
SUN Guonian
在 2026/10/22 21:14, Daniel Salzman via knot-dns-users 写道:
I don't see any regression between 3.6.0 and
3.6.1.
Do you always use the same configuration (especially
policy.signing-threads)?
Do you build Knots the same way?
Daniel
On 10/22/26 13:52, Daniel Salzman via knot-dns-users wrote:
> Hello!
>
> Thank you for the report. We will investigate the cause.
>
> Daniel
>
> On 10/22/26 12:31, SUN Guonian via knot-dns-users wrote:
>> Hello,
>>
>> Recently, my hidden master has had two upgrades: one from 3.6.0 to
>> 3.6.1, and another from 3.6.1 to 3.6.2.
>>
>> I found that the time between "Knot DNS 3.X.Y starting" and
"server
>> started answering" has increased significantly for versions 3.6.1
>> and 3.6.2.
>>
>> I have a large DNSSEC-signed zone with about 2,700,000 records, and
>> I have set |dnssec-validation|to |on|. For versions 3.5.8 and 3.6.0,
>> it took about 4 minutes to restart; after 3.6.1, it took 47–48 minutes.
>>
>> Best Regards,
>>
>> SUN Guonian
>>
7:06
Note that policy.signing-threads applies to dnssec-validation as well (you must configure
and assign a dnssec-policy),
so it should help you!
However, this doesn't explain your issue, as it hasn't changed.
Can you focus on the server shutdown? I suspect Knot might get stuck during shutdown.
Daniel
On 10/23/26 03:41, SUN Guonian via knot-dns-users wrote:
Daniel,
Since it does not sign the zone, it's a slave of the signature server, I didn't
modify the policy.signing-threads (and adjust-threads).
I notice that the top CPU usage of the knotd process is no more than 100% in this period,
it seems that the validation worker is only one.
Thank you!
Best Regards,
SUN Guonian
在 2026/10/22 21:14, Daniel Salzman via knot-dns-users 写道:
I don't see any regression between 3.6.0 and
3.6.1.
Do you always use the same configuration (especially policy.signing-threads)?
Do you build Knots the same way?
Daniel
On 10/22/26 13:52, Daniel Salzman via knot-dns-users wrote:
> Hello!
>
> Thank you for the report. We will investigate the cause.
>
> Daniel
>
> On 10/22/26 12:31, SUN Guonian via knot-dns-users wrote:
>> Hello,
>>
>> Recently, my hidden master has had two upgrades: one from 3.6.0 to 3.6.1, and
another from 3.6.1 to 3.6.2.
>>
>> I found that the time between "Knot DNS 3.X.Y starting" and
"server started answering" has increased significantly for versions 3.6.1 and
3.6.2.
>>
>> I have a large DNSSEC-signed zone with about 2,700,000 records, and I have set
|dnssec-validation|to |on|. For versions 3.5.8 and 3.6.0, it took about 4 minutes to
restart; after 3.6.1, it took 47–48 minutes.
>>
>> Best Regards,
>>
>> SUN Guonian
>>
--
8:24
I have added the followed config items:
policy.id: testpolicy
policy.signing-threads: 8
template.id.dnssec-policy: testpolicy
This time it take about 9 minutes to start.
2026-10-23T13:56:49.766+08:00 info: Knot DNS 3.6.2 starting
2026-10-23T14:05:52.720+08:00 info: server started answering
And the shutdown process finished smoothly without any problem.
knotc -c <config_path> stop
2026-10-23T14:10:02.069+08:00 info: control, received command 'stop'
2026-10-23T14:10:02.071+08:00 info: stopping server
2026-10-23T14:10:29.081+08:00 info: shutting down
P.S.,
I use the same configuration without signing-threads for all
3.5.8/3.6.0/3.6.1/3.6.2.
Best Regards,
SUN Guonian
在 2026/10/23 13:06, Daniel Salzman via knot-dns-users 写道:
Note that policy.signing-threads applies to
dnssec-validation as well
(you must configure and assign a dnssec-policy),
so it should help you!
However, this doesn't explain your issue, as it hasn't changed.
Can you focus on the server shutdown? I suspect Knot might get stuck
during shutdown.
Daniel
On 10/23/26 03:41, SUN Guonian via knot-dns-users wrote:
> Daniel,
>
> Since it does not sign the zone, it's a slave of the signature
> server, I didn't modify the policy.signing-threads (and adjust-threads).
>
> I notice that the top CPU usage of the knotd process is no more than
> 100% in this period, it seems that the validation worker is only one.
>
> Thank you!
>
>
> Best Regards,
>
> SUN Guonian
>
> 在 2026/10/22 21:14, Daniel Salzman via knot-dns-users 写道:
>> I don't see any regression between 3.6.0 and 3.6.1.
>> Do you always use the same configuration (especially
>> policy.signing-threads)?
>> Do you build Knots the same way?
>>
>> Daniel
>>
>> On 10/22/26 13:52, Daniel Salzman via knot-dns-users wrote:
>>> Hello!
>>>
>>> Thank you for the report. We will investigate the cause.
>>>
>>> Daniel
>>>
>>> On 10/22/26 12:31, SUN Guonian via knot-dns-users wrote:
>>>> Hello,
>>>>
>>>> Recently, my hidden master has had two upgrades: one from 3.6.0 to
>>>> 3.6.1, and another from 3.6.1 to 3.6.2.
>>>>
>>>> I found that the time between "Knot DNS 3.X.Y starting" and
>>>> "server started answering" has increased significantly for
>>>> versions 3.6.1 and 3.6.2.
>>>>
>>>> I have a large DNSSEC-signed zone with about 2,700,000 records,
>>>> and I have set |dnssec-validation|to |on|. For versions 3.5.8 and
>>>> 3.6.0, it took about 4 minutes to restart; after 3.6.1, it took
>>>> 47–48 minutes.
>>>>
>>>> Best Regards,
>>>>
>>>> SUN Guonian
3
days inactive
7
days old
9 comments
3 participants
participants (3)
-
Daniel Salzman -
Libor Peltan -
SUN Guonian