Of course you can still report Unbound Bugs to Unbound.
As Michael said, within IPFire we won’t look at them anymore, to use the development time to replace Unbound.
As far it is possible, there will be work-rounds published in the community for the time being.
I’ll try to test the behaviour of unbound with my VM test bed.
Next topic will be to look at the side effects, processes with memory in swap, for example.
Unbound is indeed eating memory. But is not as dramatic as it sounds. With 4 lists enabled in DNS Firewall for blue and green it goes from 47% to around 70% in 5 days or so (on a 8gb memory machine). Probably in a week or more it reaches a breaking point. But is nicely fixed by a necessary/ sanitary weekly reboot.
Not as sexy as pihole, but way safer. So… no complains. Thank you for your beautiful work. And for DBL lists… which are productive as hell on scamware/ adware side. I’ve been using IPF for a year now, and I succeeded to learn it a bit better… and it with this final touch (adopting filtering at DNS level - with GUI) I feel like Santa Claus might exist. My gratitude for the noble people that designed it.
The problem isn’t the percentage in memory, because a rational is depend on the nominator ( memoy size in this case ).
An increase of 23% , based on 8GB, means 1.84 GB. This amount is generated without any value. The size of the lists doesn’t vary so much.
The startup size, your case 47% includes two(!) instances of the unbound state. This is the reason for the complain and my inspectations.
Try 12 lists.
ipFire DNSBL plus some of the Haghezi for different specific areas (specific phone model, specific smarttv/OS) and then just leave it running until some of the background refresh takes place and reloads the daemon.
In 3 weeks my box started with 1,4 GB RAM solely for unbound and reached 3,4 GB - nothing touched, just normal refresh precesses.
I usually check the box when a new & Major version is released so the uptime is sometines around 90-100 days. That was until unbound eats all memory.
Reboot: needs 5 minutes for down and 6 for up because of large ipsets I blocked - loading 200 CC ipsets in memory is not easy…
Funny part: all those Ipsets consume far less memory than 1-2 DNS blocklist. And swapping IPSets in kernel (updating them) is achieved with zero downtime for the FW. Plus I can run in paralel the update of CC ipsets and ASN ipsets and swapping them when ready with no race condition (list name stays the same, just change the content)
I would like that to happen witz RPZ list in the future - security services update their memory “databases” with minimum if not zero downtime for that protection.
It seems that everybody has a different approach on using this solution (and that is normal!) therefore each will evaluate the solution against delivering personalized needs.
RPZ lists do not generate downtime with the AXFR/IXFR mechanism. But other changes to the DNS resolver unbound can make it inresponsive. This can be avoided by the new fast_reload operation. Unfortunately this leaves some memory of the status copy necessary.
This operation is used by IPFire now, which is good for responsiveness but bad for systems with little RAM ( because of the memory leak ).
Unbound development does not really react on this issue, which exists for a longer time yet. Therefore the DNS resolver for IPFire will change soon.
For time being we must live with work-arounds. My system for example doesn’t use the fast_reload operation, but reload_keep_cache which is similiar but has some DNS downtime. For my installation, small home network, this is acceptable.
Right. Restarting unbound bring the ram to 1,5 gb. I missed the simplest solution.
I somehow miss hagezi native lists, but on the other hand ipf adware list does a good job. At least with apple devices - without impairing the machines. And could be nicely completed by learning the local traffic and adding in custom list the domains that bother. I prefer this way.
The increase does not occur by updates, but even minor corrections ( inclusion or exclusion of certain domains ). It is the reload, which is done at boot time for example to update the forwarders.
This overhead is contained in your 36.64% RAM usage. To see the effect it is necessary to inspect the absolute values of unbound memory with fast_reload and reload_keep_cache. I made this test with my test VM.
Thanks Michael for providing the IPFire DNS list text files for other project to consume. In my fork of IPFire, the unbound memory issue can be avoided by processing the DNS lists in eBPF XDP, this not only avoids unbound memory issue, but also save CPU cycles.
This does not avoid the memory leak. It only decreases the memory usage of unbound. The increasing effect of the memory leak bug remains.
In practical usage it doesn’t occur so frequent, because most configuration editing is based on the DBL files.
BTW: This thread is about implementation of DBL with unbound ( 99,9% of the use cases ). And it is verified that the issue doesn’t originate from the lists.
the DBL is processed by XDP, not by unbound, so there is no unbound reload required, it completely bypass unbound.
Processing a defined set of official DBLs doesn’t need reloads.
Using the lists may need to define exceptions, a general list cannot realise all use cases.
How do you realise this?
to explain, when google.com domain DNS query is sent to the firewall green0 interface, google.com domain is looked up in the DBL ebpf map in the XDP program hooked by the green0 driver, since the google.com is not in DBL, the looked up would fail, then google.com is passed to unbound for normal DNS query processing. if say some dating domain like letsbond.com is sent to the firewall green0 interface, it is stored in the DBL ebpf map and look up succeed, then packet is dropped by XDP in the driver, unbound won’t even see the letsbond.com query.
so in my solution, the DBL ebpf map stores the predefined DNS records stored in the plaintext format www.ipfire.org - IPFire DBL - How To Use? , and another ebpf map can store exceptions, the XDP program can do exceptions list ebpf map lookup first, if in the exception list, return pass and pass it to unbound for normal DNS query processing.
DBL XDP looks interesting. Presumably Unbound can go back to normal reloads rather than fast-reloads which will bypass the leak. Unbound (re-)starts would speed up because they only have to load a very small amount of data. At a guess, the total memory footprint would drop.
How long does it take XDP to update to new data lists?
Obviously it will need development work.
Unbound can’t go back to normal reloads. Any reload but fast_reload makes the DNS some time inresponsive. And reloads are not initiated by list updates.
But unbound has reached its end in IPFire and the XDP discussion has paused since mid 2025.
IMO, XDP is a much greater change than the change of the DNS resolver.
once XDP program is loaded and attached to network interface, at run time, you only need to update the blocklist ebpf map that is associated with the XDP program, it is like sort of database update operation, no reload required, so no traffic interruption, ebpf map has batch operation that can speed up the map update very quickly, for example, here is I batch delete or batch add porn list
[root@loongfire dns]# time dns_fw /sys/fs/bpf/dns-fw/dns_fw_blocklist batch-delete porn.txt | tail -10
Processed 360000 domains so far...
Processed 370000 domains so far...
Processed 380000 domains so far...
Processed 390000 domains so far...
Processed 400000 domains so far...
Processed 410000 domains so far...
Processed 420000 domains so far...
Processed 430000 domains so far...
Total processed: 435653 domains from porn.txt
Successfully processed 435653 domains from file
real 0m0.248s
user 0m0.062s
sys 0m0.188s
total time to load XDP program and load all blocklists with about 1.3 million DNS domains in ebpf map, note the time spent most is to load XDP program
[root@loongfire dns]# time /etc/rc.d/init.d/dnsfw start
Starting dns-fw...Synchronizing DNS blocklists...
Finished synchronizing blocklists [ OK ]
real 0m1.303s
user 0m0.357s
sys 0m1.015s
right, the development time would be spent on XDP program, nlnetlab has sample program Journeying into XDP: Fully-fledged DNS service augmentation , IPFire needs to update kernel to support eBPF network functionality. here is the XDP program I use and based on nlnetlab XDP program xdp-tools/dns-fw/dns_fw.bpf.c at main · vincentmli/xdp-tools · GitHub. XDP program is not trivial to write, but with AI assistance, it is not that hard neither. anyway, just share the idea.
The topic is discussed broadly and there is no solution with the current CU and DNS resolver, therefore I suppose to close this thread.