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
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
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.
Hello,
In short, we do use stats module with http module exposing webmgmt every
time SYSTEMD process knot is started (we do have 30 on one machine).
Unfortunately each of webmgmt shows the same stats in /stats or /metrics
endpoint (prometheus)
Checking metrics with socat, going into each process and running
stats.list() shows correctly stats per process.
Is there any way to have automatically exported per knot process statistics?
Regards,
_
*Marcel Adamski*DevOps Engineer
*M: *+48 882 115 524
*Redge *Technologies
Ostrobramska 86 | 04-163 Warsaw
*T: *+48 22 255 11 00 | *F: *+48 22 255 15 50
*www.redge.com* <https://redge.com/>
[image: RedgeTechnologies]
*Redge Technologies Sp. z o.o.*
*VAT No:* PL1132687365 | *REGON:* 141103558 | *KRS: *0000287417
District Court for the Capital City of Warsaw, XIV Commercial Division of
National Court Register | Share capital: 501 650 PLN
We use personal data in accordance with our privacy policy
<https://redge.com/privacy-policy/>
Hello
We are using knot-resolver 5.7.4 with multiple independent instances - 32. We also use tmpfs.
We starts processes by systemd.
the problem we encountered is that when systemd starts 32 processes, they get a timeout and are restarted by systemd. As a result, we have problems starting all processes. The problem does not occur when we do not use tmpfs.
How to solve this problem?
We shoud add to systemd something like this?
ExecStartPre=/bin/sleep $(( RANDOM % 5 ))
[Service]
StartLimitBurst=5
StartLimitIntervalSec=10
Or we should something to kresd configuration?
Hi,
I've found this warning in my journal:
... kresd[1071788]: [taupd ] you need to update package with trust
anchors in "/usr/share/dns/root.key" before it breaks
I don't know how to do that.
I think my system is current but just ran: apt update; apt list
--upgradable and it shows nothing regarding knot.
Thanks for any pointers,
Mike Wright
Hello,
On my local network, I have a computer fixed IP that I would like to use
a specific TLS FORWARD.
Generic TLS_FORWARD is simply configured as such.
policy.add(policy.all(policy.TLS_FORWARD({
{'9.9.9.9', hostname='dns9.quad9.net'},
{'1.1.1.1', hostname='cloudflare-dns.com'},
{'1.0.0.1', hostname='cloudflare-dns.com'},
})))
I tried to embed a specific different TLS_FORWARD with a
view:addr('10.10.10.10', ... )
but I cannot manage to restrict this TLS_FORWARD and to avoid it
poisoning the cache.
Is there somewhere an example of such setup, with ACL ending up on two
different TLS_FORWARD and one with no cache ?
Regards,
--
Mathieu Roy
