$ sudo apt list --installed | grep cznicknot-dnsutils/noble,now 3.4.4-cznic.1~noble amd64 [installed]knot-resolver6/noble,now 6.0.11-cznic.1~noble amd64 [installed]libdnssec9/noble,now 3.4.4-cznic.1~noble amd64 [installed,automatic]libknot15/noble,now 3.4.4-cznic.1~noble amd64 [installed,automatic]libzscanner4/noble,now 3.4.4-cznic.1~noble amd64 [installed,automatic]lua-psl/noble,now 0.3-cznic.1~noble amd64 [installed,automatic]
$ sudo apt list --installed | grep cznicknot-resolver6/noble,now 6.0.8-cznic.2~noble amd64 [installed,upgradable to: 6.0.11-cznic.1~noble]libdnssec9/noble,now 3.4.4-cznic.1~noble amd64 [installed,automatic]libknot14/noble,now 3.3.9-cznic.1~noble amd64 [installed,automatic]libzscanner4/noble,now 3.4.4-cznic.1~noble amd64 [installed,automatic]lua-psl/noble,now 0.3-cznic.1~noble amd64 [installed,automatic]
Le 3 avr. 2025 à 11:43, Vladimír Čunát <vladimir.cunat_at_nic_cz_48qbhjm2vj0347_240cc87d@icloud.com> a écrit :On 02/04/2025 23.19, oui.mages_0w@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.