Hello,
I'm doing tests of filtering DNS with RPZ lists. Now, I would like to collect stats and metrics about blocked requests (blocked domains, sources IP, count of blocked requests...).
In journalctl I have logs like this : "[rules ] => local data applied, user: xxx.xxx.xxx.xxx, name: blocked-domain.tld." Main infos I want to collect exist.
Is there a way to do this with Prometheus format metrics + Grafana ? I didn't really find anything in documentation.
Thank you so much if you have a tip to help me.
Hello,
I was using Knot resolver 5 with configuration where I was replacing some parts of DNS tree (https://knot-resolver.readthedocs.io/en/latest/modules-policy.html#replacin…).
Since I updated to Knot Resolver 6 and rewrite configuration to YAML using forward directive (https://www.knot-resolver.cz/documentation/latest/config-forward.html#forwa…) it seems that this configuration is not working as planned. After short time Knot Resolver started responding to replaced part of tree as NXDOMAIN.
Is this behavior intended, or is it some unintended bug?
Configuration for v6 was:
forward:
# Internal Domains
- subtree:
- internal.corp
- 10.in-addr.arpa
servers:
- 10.3.0.102
- 10.3.0.103
options:
authoritative: false
dnssec: false
I've tried to find if I do have something misconfigured, but without any luck. I have only a theory - in docs, it states like this: "Forwarding configuration instructs resolver to forward cache-miss queries from clients to manually specified DNS resolvers". Can the real reason of malfunction be, that Knot resolver 6 uses information from cache BEFORE it even tries to forward the query?
Since I am not sure how Knot resolver handles these rules internally, it is only theory.
Is there any correct way to replicate behavior from Knot Resolver 5? My config in v5 was:
internalDomains = policy.todnames({
'10.in-addr.arpa',
'mydomain.corp'
})
policy.add(policy.suffix(policy.FLAGS({'NO_CACHE'}), internalDomains))
policy.add(policy.suffix(policy.STUB({
'10.3.0.102',
'10.3.0.103'
}), internalDomains))
Regards,
Jiri Masek
Hi,
I run my knot-resolver on a raspberry pi with pxe boot and the root file
system on nfs.
I realize that this is not recommended operations.
Therefore I try to run my cache on an tmpfs file system.
> tmpfs on /var/cache/knot-resolver type tmpfs (rw,relatime,size=102400k)
But now my knot-resolver refuses to start
Oct 2 20:14:39 pi-hole1 systemd[1]: Starting Knot Resolver daemon...
Oct 2 20:14:40 pi-hole1 kresd[1052]: [system] error while loading
config: /etc/knot-resolver/kresd.conf:69: can't open cache path
'/var/cache/knot-resolver'; working directory '/var/lib/knot-resolver';
No space left on device (workdir '/var/lib/knot-resolver')
Oct 2 20:14:40 pi-hole1 systemd[1]: kresd(a)1.service: Main process
exited, code=exited, status=1/FAILURE
Oct 2 20:14:40 pi-hole1 systemd[1]: kresd(a)1.service: Failed with result
'exit-code'.
Oct 2 20:14:40 pi-hole1 systemd[1]: Failed to start Knot Resolver daemon.
Besides the fact that this message makes no sense (why wouldn't the
cache be opened in /var/cache when /var/lib is full?), the cache gets
actually opened and a database created. The kres-cache-gc process runs
without problems.
The /var/lib/knot-resolver directory exists and is writeable.
I have tried to put it on tmpfs too, no luck.
What solved the problem was
root@pi-hole1:~# umount /var/cache/knot-resolver
root@pi-hole1:~# systemctl start kresd@1
But now the cache is on nfs. That seems risky.
I think this is the relevant part of the configuration
-- Cache size
workdir = '/var/cache/knot-resolver'
cache.open(100 * MB, 'lmdb:///var/cache/knot-resolver')
But it comes with a distro pre-config of
-- Set cache location
rawset(cache, 'current_storage', 'lmdb:///var/cache/knot-resolver')
Which by the way makes it very hard to change cache location. Not to
mention the hard coded location in the systemd script for kres-cache-gc.
What do I do wrong?
/Ulrich
Dear Knot Resolver users,
Knot Resolver 6.0.15 (early-access) has been released!
Security:
- DoS: fix a rare segfault in `resolve` function (!1717)
Someone controlling the DNS traffic might be able
to trigger this crash intentionally and too often.
- DoS: drop a wrong assertion/crash (!1718)
Someone controlling the DNS traffic will most likely be able
to trigger this crash intentionally and too often.
Bugfixes:
- manager: prometheus metrics update (!1703, #917, !1712)
- added missing metrics split by IPv4 and IPv6
- typo: resolver_answer_flags_rd_total -> resolver_answer_flag_rd_total
- /dnssec/trust-anchors-files: fix resolver startup (!1704)
- /network/edns-buffer-size: fix swapped upstream+downstream (!1711)
- cache: fix a crash in case garbage collection is too slow (!1713)
[system] assertion "env->is_cache" failed in cdb_write
- /cache/prefill: fix 6.0.13 regression (!1705)
- datamodel: improve file permission check (#933, !1714)
- NO_CACHE flag: fix and tweak its behavior (!1715)
Improvements:
- update/more precise default answers for special names (!1709)
https://www.iana.org/assignments/special-use-domain-nameshttps://www.iana.org/assignments/locally-served-dns-zones
- kresctl: strict validation is now disabled by default (!1714)
Full changelog:
https://gitlab.nic.cz/knot/knot-resolver/raw/v6.0.15/NEWS
Sources:
https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.15.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-resolver/knot-resolver-6.0.15.tar.xz.asc
Documentation:
https://www.knot-resolver.cz/documentation/v6.0.15/
--
Ales Mrazek
PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE
Hello.
On 23/06/2025 10.18, Stéphane Paillet wrote:
> I would like to know if it's possible to split the config.yaml in
> several files (the main config in one file, acl and views section in
> another, data-local section with rpz lists and tags to rely acl lists
> to blocklists in another), and if the answer is yes, how can I do ?
Currently it's not possible. You could of course use some generator
that produces the config.yaml, but that's of course less ergonomic.
Incidentally we have this WIP:
https://gitlab.nic.cz/knot/knot-resolver/-/merge_requests/1710
--Vladimir
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
