Bug #16217
open
Memory exhaustion in ``kea2unbound`` when pfBlockerNG DNSBL is enabled in "Unbound mode" instead of "Unbound python mode"
Added by Kevin Burge 7 days ago.
Updated 3 days ago.
Affected Architecture:
amd64
Description
Upgraded to 2.8.x yesterday:
2.8.0-RELEASE (amd64)
built on Wed May 21 18:12:00 CDT 2025
FreeBSD 15.0-CURRENT
I am receiving frequent crashes reported:
[29-May-2025 11:08:56 US/Central] PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 4096 bytes) in /usr/local/bin/kea2unbound on line 524
I have several VLANs as well as a VPN set up. I'm using IPv4 / IPv6 DHCP servers.
Files
- Priority changed from Normal to Very Low
Most users who have encountered this were using pfBlockerNG and were not using python mode. Changing pfBlockerNG to python mode eliminated any errors as it does not load all of that data into Unbound directly.
While it may be possible for kea2unbound to somehow detect/skip entries from pfBlockerNG in the future, it may not be viable. Using python mode in pfBlockerNG is much more efficient and the best practice workaround.
- Subject changed from kea2unbound memory exhaustion in to Memory exhaustion in ``kea2unbound`` when pfBlockerNG DNSBL is enabled in "Unbound mode" instead of "Unbound python mode"
Why did this change in 2.8.0? I never had errors about memory before the update..
Jim Pingle wrote in #note-1:
Priority changed from Normal to Very Low
Should this be a HIGH protity. If I was getting crash log error message like this I'd want an update pushed out to explain WHY its crashing. Maybe update kea2unbound to say "Hey if your getting this error, and using PFblockerNG try changing your unbound mode from unbound to unbound python mode"
Or maybe update PFblockerNG to default to unbound python mode, or simular to how you told us the old DHCP was being depraticated and to switch to kea. Maybe say "Hey you should update this"...
kea2unbound is new in CE 2.8.0. Kea did not have DNS registration functionality before.
You can easily switch pfBlockerNG DNSBL modes to work around it, it does not necessarily require a fix in kea2unbound, I left this open in case we can find a way to make kea2unbound more tolerant of that situation in the future.
If the pfBlockerNG developer wants to detect that and change the pfBlockerNG behavior based on the DHCP daemon, that's up to them, but that's not a high priority base system issue.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by