5 Čen
2026
5 Čen
'26
7:50
Hi,
is it somehow possible to disable RFC 8198 - aggressive caching in knot-resolver 6?
I cannot find any information about that in docs. Unnamed chatbot is sure that it can be
done with "cache.aggressive = false" in LUA script. But since it is
undocumented, I would like to confirm that.
Regards
Jiri Masek
5 Čen
5 Čen
7:53
On 05/06/2026 07.50, Jiri Masek via knot-resolver-users wrote:
is it somehow possible to disable RFC 8198 -
aggressive caching in knot-resolver 6?
I cannot find any information about that in docs. Unnamed chatbot is sure that it can be
done with "cache.aggressive = false" in LUA script. But since it is
undocumented, I would like to confirm that.
No, that's just a hallucination. We currently don't support turning it
off; there's no code for that.
Are there some particular issues with it?
--Vladimir
8:57
Hi,
problem is my good old over-complicated internal DNS structure which conflicts with
Internet DNS tree. Then getting fake NXDOMAINS (synthesized from aggressive cache).
I'll try to shorten it.
Let's have this configuration in config.yaml:
dnssec:
# Disable DNSSEC for internal domains
negative-trust-anchors:
- corp
forward:
- subtree: "."
servers:
- 10.11.2.36
options:
authoritative: false
dnssec: true
When I query for example proxy.corp, it seem to work. Unless there is real traffic on
resolver. When it is, after some time I am getting those fake NXDOMAIN responses. Not
consistently - it changes in time. So far every research points to that RFC 8198 -
aggressive cache.
I believe this cannot be solved on knot-resolver, since negative-trust-anchors does not
disable that aggressive cache for selected domains.
Regards,
Jiri Masek
10:52
On 05/06/2026 08.57, Jiri Masek via knot-resolver-users wrote:
I believe this cannot be solved on knot-resolver,
since negative-trust-anchors does not disable that aggressive cache for selected domains.
OK. At a glance, it makes sense to turn of aggressive synthesis for
names under a negative TA, so I'd like that in future.
In the current version, similar use cases were meant (since commit
6f1d9b6140f0e) to be covered by:
forward:
- subtree: "corp"
servers:
- 10.11.2.36
options:
authoritative: false
dnssec: false
(or with authoritative: true in case you have also auth server for these
names)
The general cases were expected to go directly without forwarding, but I
believe you can combine like:
forward:
- subtree: "."
servers:
- 10.11.2.36
options:
authoritative: false
dnssec: true
- subtree: "corp"
servers:
- 10.11.2.36
options:
authoritative: false
dnssec: false
I haven't really tested these now, but at a glance the code for
disabling aggressive synthesis should fire for names covered by
forwarding with dnssec: false.
--Vladimir
0
days inactive
0
days old
knot-resolver-users@lists.nic.cz
3 comments
2 participants
participants (2)
-
Jiri Masek -
Vladimír Čunát