Re: debsuryorg-archive-keyring

2025-02-13 Thread Malcolm Scott via bind-users
On Thu, 13 Feb 2025, at 16:54, Petr Špaček wrote: >> [1] https://gitlab.isc.org/isc-projects/bind9/-/issues/5050 > > BTW you can expedite fixing it if you test code changes in > https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/9967 > and provide feedback. Aha -- I had missed that -- I wi

Re: debsuryorg-archive-keyring

2025-02-13 Thread Petr Špaček
On 13. 02. 25 17:17, Malcolm Scott via bind-users wrote: I mainly noticed this because I am temporarily building my own patched version of your package with a workaround for the SIG(0) key limit problem I reported some months back [1], [1] https://gitlab.isc.org/isc-projects/bind9/-/iss

Re: debsuryorg-archive-keyring

2025-02-13 Thread Malcolm Scott via bind-users
Hi Ondřej, That's a fair point; I am indeed trusting you anyway by installing your packages :-) I mainly noticed this because I am temporarily building my own patched version of your package with a workaround for the SIG(0) key limit problem I reported some months back [1], and realised that

Re: dnsviz.net: has errors; select the "Denial of existence" DNSSEC option to see them.

2025-02-13 Thread Hans Mayer via bind-users
Hi Taavi, It seems I was blind and didn't see the button. Problem solved. Iterations set to 0 and salt to null. Everything green now at DNSviz. Best regards Hans -- On 07.02.25 17:05, Taavi Eomäe wrote: Hi, If you select the "Denial of existence" under options, then you will see the exac

Re: debsuryorg-archive-keyring

2025-02-13 Thread Ondřej Surý
It's absolutely ok to drop the dependency for your custom packages. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 13. 2. 2025, at 17:17, Malcolm Scott wrote:

Re: debsuryorg-archive-keyring

2025-02-13 Thread Ondřej Surý
Hi Malcolm, if you trust me to produce BIND 9 code directly from the upstream, I guess that trust can be transitioned to the packaging repositories. The packaging is created in a way that makes it easy to create packages for both Ubuntu and Debian in the same way. I'll add some text to the KB, t

debsuryorg-archive-keyring

2025-02-13 Thread Malcolm Scott via bind-users
Hi all, With apologies if this is a FAQ: why do the ISC BIND packages for Ubuntu, linked from https://kb.isc.org/docs/isc-packages-for-bind-9 and published at https://launchpad.net/~isc/+archive/ubuntu/bind, depend on debsuryorg-archive-keyring? That package makes Apt trust a key for an enti

Re: Just a suspicion for now: Memory leak in 9.20.4?

2025-02-13 Thread Ondřej Surý
There’s official KB article on the topic: https://kb.isc.org/docs/bind-memory-consumption-explained - you actually need to use jeprof and understand the BIND 9 internals.Baeldung wouldn’t be my first (nor the last choice) for something that’s really useful. My feeling is they optimize content for S

Re: Just a suspicion for now: Memory leak in 9.20.4?

2025-02-13 Thread Robert Wagner
Not sure if we have a good howto on watching for memory leaks. But you could run something like "sudo pmap [pid]" and watch it over time (like several days). Expect some fluctuations for load. You may find a dependent library that has an issue. Others may have better tools that are commonly f

Re: Just a suspicion for now: Memory leak in 9.20.4?

2025-02-13 Thread Ondřej Surý
The increase could be for various reasons. The query pattern is different, the underlying database is different, the other data structures are different. Unless there’s unbounded growth (in the stats), or the cache memory goes over configured limit, there’s nothing to worry about. Sometimes it

Just a suspicion for now: Memory leak in 9.20.4?

2025-02-13 Thread Borja Marcos via bind-users
Hi, I am running 9.18.32 and 9.20.4 on FreeBSD. I have noticed that 9.20.4 is using much more memory 24 hours since restarting them, despite the fact that the 9.18.32 has a higher query load. Nothing substantial now, but I would like to confirm (or not) whether someone else has observed someth