bind: please update package

[ler762]

Maintainer: @<nmeyerhans> BKPepe

Environment: (put here arch, model, OpenWrt version) I have no idea what the arch, model is for a GL.inet MT3000 OpenWrt version: latest

Description:

(https://openwrt.org/packages/table/start?dataflt%5BName_pkg-dependencies*%7E%5D=bind)

says the OpenWrt version of bind is 9.18.19-1

https://downloads.isc.org/isc/bind9/cur/9.18/CHANGES

says the current 9.18 version of bind is 9.18.27

I asked on the openwrt forum

https://forum.openwrt.org/t/bring-bind-up-to-current/200216

and was told to submit my request via bug tracker, so here it is.

[brada4]

The actual version in opkg is 9.18.24 which has published security issues solved. Are you affected by bugs fixed after that?

[ler762]

The actual version in opkg is 9.18.24 which has published security issues solved. Are you affected by bugs fixed after that?

I don't know which bugs might be giving me grief; all I know is that bind stops resolving some/all names after a period of time and a reboot gets things working again.

I'm using the gl.inet mt3000 software which has an even older version of bind. I was thinking about trying a switch to "pure" openwrt but I noticed you aren't offering the latest 9.18 version of bind software either.

I sent an email to gl.inet support and it sounds like they're going to update the version of bind they offer, so if it's too much trouble for you to update that's OK.. I can wait for the gl.inet update.

Thanks Lee

Message ID: @.***>

[brada4]

Set max-cache-size to half of otherwise free memory e.g options { .... max-cache-size 50%; }

default is 90% in last 5 years and unlimited before that.

[ler762]

Set max-cache-size to half of otherwise free memory

Thanks, I'll give it a try.

Does the Debian version of bind have any patches to help it survive with a full cache? Because I basically copied my bind config on Debian over to the MT3000 and I've been running bind on Debian for years -- starting with Debian 9 on a 32 bit Pentium processor and I've kept

$ grep cache-size named.conf max-cache-size 10M;

in the config since then and it's been rock solid for me at home. ... altho I have no idea how to verify that it hasn't exceeded 10MB for the cache and Debian 11 is on Version: 9.16.48-Debian instead of the 9.18 train

[brada4]

slow deteroriation of bind named is sign of memory usage running wild. It is not a bug here or with any other platforms you mention. Check with glinet for monitoring their firmware. debian config was never activated as it would write data in flash and wear device out in no time.

[brada4]

The problem is not full cache, the problem is process size with most being cache exceeding RAM available. It was solved by setting default to 90% suitable for bind-only big systems. More info on running BIND process:

rndc status
rndc stats

If the problem is same with ncient glinet and openwrt package then it is either with your config or with glinet firmware. You should try mainstream openwrt to point fingers into either direction. Probably in forum somebody can help to bring bind in order in config case.

[ler762]

uptime is 2 days, 22 hours and dns name lookups are still working Yay!

On Sat, Jun 8, 2024 at 1:48 AM Andrew wrote:

The problem is not full cache, the problem is process size with most being cache exceeding RAM available.

Then it shouldn't have been a problem for me since I had the max cache set to 10MB Anyway.. I bumped up the max-cache like I said I would:

@.***:/# grep max-cache /etc/bind/named.conf max-cache-size 60M;

and since I don't have ipv6 enabled I changed /etc/init.d/named to add the "-4" option to named and also "-n 1" to see if the # threads was a problem.

From the luci interface, status / overview shows 480MB of memory on the system status / processes shows bind as /usr/sbin/named -u bind -4 -n 1 -f -c /etc/bind/named.conf and taking 5% of memory, so be about 24MB of memory?

More info on running BIND process:

rndc status rndc stats

from rndc stats

++ Cache Statistics ++ [View: default] 183301 cache hits 13 cache misses 63813 cache hits (from query) 42496 cache misses (from query) 0 cache records deleted due to memory exhaustion 12384 cache records deleted due to TTL expiration 60365 covering nsec returned 1119 cache database nodes 3 cache NSEC auxiliary database nodes 1024 cache database hash buckets 15683178 cache tree memory total 450721 cache tree memory in use 0 cache tree highest memory in use 140352 cache heap memory total 140352 cache heap memory in use 0 cache heap highest memory in use

You should try mainstream openwrt to point fingers into either direction. openwrt bind has known bugs. If it offered current software I could see trying it, but as it is.. not a terribly appealing idea since #1 not all known bugs are fixed and #2 I don't know what else would be changed -- which I should probably learn, but it's low on my priority list because #1

Message ID: @.***>

[brada4]

It is 9.18.24 in OpenWRT repos, and you have to use real OpenWRT to isolate from potential issues in fork distribution.

[BKPepe]

I'm using the gl.inet mt3000 software which has an even older version of bind. I was thinking about trying a switch to "pure" openwrt but I noticed you aren't offering the latest 9.18 version of bind software either.

There is said everything. You should use vanilla OpenWrt isntead of the fork. In OpenWrt 22.03, which is EoL these days, there is version 9.18.24. You can check it be here: https://github.com/openwrt/packages/blob/openwrt-22.03/net/bind/Makefile. In the latest stable OpenWrt version, we do have currently 9.18.27. That can be check here: https://github.com/openwrt/packages/blob/openwrt-23.05/net/bind/Makefile

The versioning can be changed over the time.

Closing.