7 Říj
2026
7 Říj
'26
15:09
If Knot Resolver has no directive about trust anchors, it stills works
and validates automatically, great.
Now, I wanted to check the trust anchors in preparation for sunday's
rollover and I have questions:
* when you do not specify a trust anchors file, where is it stored?
I've checked many places on the disk without a result. (More general
question: how to display the entire configuration, with the default values?)
* when you do not specify a trust anchors file, how to check that you
indeed got the new root key?
% knot-resolver --version
6.4.0
8 Říj
8 Říj
6:53
On 07/10/2026 15.09, Stephane Bortzmeyer wrote:
If Knot Resolver has no directive about trust anchors,
it stills works
and validates automatically, great.
Now, I wanted to check the trust anchors in preparation for sunday's
rollover and I have questions:
* when you do not specify a trust anchors file, where is it stored?
I've checked many places on the disk without a result. (More general
question: how to display the entire configuration, with the default values?)
The default trust anchors are configurable during build time, and so far
they are not represented explicitly in the configuration model (which
just shows None).
It's certainly possible to dive a little into internals, e.g. run
echo 'trust_anchors.summary()' | sudo socat - /run/knot-resolver/control/0
# or more detailed
echo 'trust_anchors' | sudo socat - /run/knot-resolver/control/0
We prefer to use an in-distro package with this information, e.g.
dns-root-data in .deb distros:
https://packages.debian.org/trixie/dns-root-data but the
builder/packager has other options: install our own file with those TAs
(we upgraded those in June 2024 already) or use a bootstrapping method
(or any path in the filesystem).
* when you do not specify a trust anchors file, how to
check that you
indeed got the new root key?
Generally I think it's best to test from outside of the resolver, e.g.
https://dnstest.dev/ksk-2024/
% knot-resolver --version
6.4.0
That's slightly outdated, but not significantly in this context - unless
you use trust anchor bootstrapping (but that isn't a common config, I
think), as 6.4.1 added
https://gitlab.nic.cz/knot/knot-resolver/-/merge_requests/1847
9 Říj
9 Říj
11:31
On Thu, Oct 08, 2026 at 06:53:56AM +0200,
Vladimír Čunát <vladimir.cunat(a)nic.cz> wrote
a message of 112 lines which said:
This is the current ArchLinux package (most of the times, ArchLinux is
very up-to-date but not always).
It's certainly possible to dive a little into
internals, e.g. run
echo 'trust_anchors.summary()' | sudo socat - /run/knot-resolver/control/0
Good idea.
'. 33663 DNSKEY 257 3
8
AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=
; Valid: ; KeyTag:20326
. 33663 DNSKEY 257 3 8
AwEAAa96jeuknZlaeSrvyAJj6ZHv28hhOKkx3rLGXVaC6rXTsDc449/cidltpkyGwCJNnOAlFNKF2jBosZBU5eeHspaQWOmOElZsjICMQMC3aeHbGiShvZsx4wMYSjH8e7Vrhbu6irwCzVBApESjbUdpWWmEnhathWu1jo+siFUiRAAxm9qyJNg/wOZqqzL/dL/q8PkcRU5oUKEpUge71M3ej2/7CPqpdVwuMoTvoB+ZOT4YeGyxMvHmbrxlFzGOHOijtzN+u1TQNatX2XBuzZNQ1K+s2CXkPIZo7s6JgZyvaBevYtxPvYLw4z9mR7K2vaF18UYH9Z9GNUUeayffKC73PYc=
; Valid: ; KeyTag:38696
'
We prefer to use an in-distro package with this
information, e.g.
dns-root-data in .deb distros:
For instance, on ArchLinux, it seems Knot uses the package
dnssec-anchors, which has the two keys in its /etc/trusted-key.key.
Generally I think it's best to test from outside
of the resolver, e.g.
https://dnstest.dev/ksk-2024/
But it is not very convenient when you test a remote server without
the ability to run a modern browser. ("JavaScript is requiredEnable
JavaScript to run this test.")
%
knot-resolver --version
6.4.0
That's slightly outdated,
11:37
On 09/10/2026 11.31, Stephane Bortzmeyer wrote:
Advanced users can do the same tests over command-line. This web even
suggests concrete dig commands.
Generally I
think it's best to test from outside of the resolver, e.g.
https://dnstest.dev/ksk-2024/
But it is not very convenient when you test a remote
server without
the ability to run a modern browser. ("JavaScript is requiredEnable
JavaScript to run this test.")
0
days inactive
2
days old
knot-resolver-users@lists.nic.cz
3 comments
2 participants
participants (2)
-
Stephane Bortzmeyer -
Vladimír Čunát