knot-resolver6 v6.0.13 introduces a bug that causes an invalid policy-loader.conf
to be generated when the following local-data options are enabled:
* addresses
* addresses-files
* rules/subtree
The log message from the crash:
kresd[223706]: [system] error while loading config: policy-loader.conf:65:
wrong number of arguments for function call (workdir '/run/knot-resolver')
The attached patch fixes this crash:
Brad Cowie (1):
datamodel/templates: fix kr_rule_local_* macros
.../templates/macros/local_data_macros.lua.j2 | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--
2.43.0
Hi,
I'm receiving this error:
ERROR: write access needed to keyfile dir '/etc/knot-resolver/root.keys'
Current permissions are 775 knot-resolver:knot-resolver. I've also
tried 0:0.
Contents of the dir are same owner 664.
Suggestions?
Thanks,
Mike Wright
Hi,
on a fresh debian system I followed this installation guide
https://www.knot-resolver.cz/documentation/stable/quickstart-install.html
The package installed successfully, but after that things get a bit more
difficult
The installed gpg key is expired
> /etc/apt/trusted.gpg.d/cznic-obs.gpg
> ------------------------------------
> pub rsa2048 2018-02-15 [SC] [verfallen: 2024-08-15]
> 4573 7F9C 8BC3 F3ED 2791 8182 7406 2DB3 6A1F 4009
> uid [ verfallen ] home:CZ-NIC OBS Project
> <home:CZ-NIC@build.opensuse.org>
>
>
"verfallen" means expired. Sorry that system speaks german (german hoster).
Makes it kind of hard to install kresd. :-)
And while we are at it, why are there no kresd packages for the
raspberry pi? Please!!!
Kind regards
/Ulrich
Dear Knot Resolver users,
Knot Resolver 6.0.12 (early-access) has been released!
Security:
- DoS: fix rare crashes with either of the lines below (!1682)
[system] requirement "h && h->end > h->begin" failed in queue_pop_impl
[system] requirement "val == task" failed in session2_tasklist_del
Bugfixes:
- daemon: fix DoH with multiple "parallel" queries in one connection
(#931, !1677)
- /management/unix-socket: revert to absolute path (#926, !1664)
- fix `tags` when used in /local-data/rules/*/records (!1670)
- stats: request latency was very incorrect in some cases (!1676)
Improvements:
- /local-data/rpz/*/watchdog: new configuration to enable watchdog for
RPZ files (!1665)
Full changelog:
https://gitlab.nic.cz/knot/knot-resolver/raw/v6.0.12/NEWS
Sources:
https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.12.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.12.tar.xz.asc
Documentation:
https://www.knot-resolver.cz/documentation/v6.0.12/
--
Ales Mrazek
PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE
I'm trying to set up a resolver with the addition of an invented TLD
(this is an experiment, no need to explain to me that it may be a bad
idea). I have authoritative name servers for the dummy TLD, which is
signed with DNSSEC and I want DNSSEC validation.
The documentation says that policy.FORWARD requires to forward to a
resolver :-(
policy.STUB disables validation so it is a no-no.
If I configure with policy.add + policy.FORWARD, and trust_anchors.add
for the key of the dummy TLD, it works for the TLD apex, for
subdomains of the TLD which are NOT signed but for signed subdomains
of the TLD, I get SERVFAIL + "EDE: 12 (NSEC Missing): (AHXI)".
Querying directly the authoritative name servers with the DO bit, I
get all the RRSIG and NSEC I need. But apparently, Knot cannot get them.
Knot-resolver 5.7.4
On 02/04/2025 23.19, oui.mages_0w(a)icloud.com wrote:
> So knot-resolver 6.0.8 with libknot15 seems to also trigger the memory
> leak I was experiencing with knot-resolver 6.0.9+ by the unidentified
> traffic pattern (or whatever is causing this).
Thanks, this is very interesting. I confirm that (for our Ubuntu 24.04
packages), libknot15 (i.e. knot 3.4) is used exactly since 6.0.9, so the
timing checks out, too. That's just a matter of binary builds. Even
the latest versions can still be built with libknot14 (3.3.x)
Have you looked into which libdnssec and libzscanner you have there?
The thing is that these two didn't change soname between knot 3.3 and
3.4, so here I see larger risks than with libknot itself.
