We do not need a download solution, because that is integrated into unbound!
This is done, hopefully, by the unbound RPZ module. The docs aren’t exactly enough at this point. But experience shows, that the list are updated at most with the frequency defined in the SOA record.
For the details we should examine the sources.
@jon
to me as an ignorant user it is a quite
surprising coincedence that we shared the
exact same question:
So if RPZ doesn’t use HTTPS, what is it using?
source
and to read:
… there are some that have a metered
connection and will pay for data by volume …
source
as an answer is just:
however 
I have realised that it was wrong of me to respond in to this post thread because now we have a parallel path of discussion to the dev mailing list with the two not being synced or see by the same people.
I will therefore make my response from now on into the dev mailing list thread already existing.
I think both channels are necessary.
The dev list to discuss the integration into IPFire. Technical and formal.
The community to explain the time it takes to integrate this addon, which a couple of users are satisfied with. ( Including me 
)
@jon has chosen both channels. IMO, this is adequate.
This looks interesting as I am all for security and privacy.
Hello,
I upgraded to rpz-beta-0.1.18-18.ipfire.tar and all is working fine.
For whoever is interested, this version has these sub-components:
grep version= /usr/sbin/rpz*
/usr/sbin/rpz-config:version="2025-01-11 - v44"
/usr/sbin/rpz-functions:version="2024-12-10 - v02"
/usr/sbin/rpz-make:version="2025-01-11 - v14"
/usr/sbin/rpz-metrics:version="2025-01-20 - v25"
/usr/sbin/rpz-sleep:version="2024-08-16" # v05
hello everyone, sorry for the question, but there was talk of making this component official, can we know something about it?
thanks
Wait, lists are downloaded from public sources which even 100k UBlock users download daily and the amount of traffic is a problem for the source?
Never heard of such problems… are this Problems?
I generated 20 useable lists from the Hagezi source on github. Should I stop this?
Hi all,
happy new year from me too but also with a little present GitHub - twitOne/RPZ-Blocklists: Multi-Source RPZ Blocklists for DNS Filtering (automated conversion and updates) hope it works like it should and let us know if someone have good lists, find bugs, have new ideas, or just constructive critics/or_ 
.
Best,
Erik
Some stuff has changed in main GitHub - twitOne/RPZ-Blocklists: Multi-Source RPZ Blocklists for DNS Filtering (automated conversion and updates) . SOURCES.md should deliver a good overview of all but am not sure if some more can be included, i was wondering what you all thinking about 
. Ideas ?
Best,
Erik
P.S.: Good lists and may new categories might be a good next step ?
ok, i read this like a hint to show my generated lists 
, but it is relative easy to do so, they all can be find on Hagezi’s github. I did two screenshots here to show. Several of these lists are also in my uBlock extension of the Browser, so the hits here are not so high.
Hi @mumpitz
No, this was not meant as a hint to show own lists :D. It’s an idea to provide lists from very different sources in one place (RPZ-Blocklists/SOURCES.md at main · twitOne/RPZ-Blocklists · GitHub) with an automated update/validation every hour for all lists 
.
The RPZ lists are relatively widely spread across different sources, so the intention was to organize them a little better, extend them, and provide a source for RPZ lists for the IPFire community.
This project also includes a converter for different blacklist formats, which you can checkout with this tool: https://github.com/twitOne/RPZ-Blocklists/blob/main/tools/blocklist2rpz-format-tester.pl before adding potential new sources.
This project is under the control of us (the users/developer of RPZ on IPFire), so we should be able to extend it as we want. However, there doesn’t seem to be much interest in it (many clones but currently no ideas for extensions), but maybe that will change someday on a sunny day :D.
Best,
Erik
fully unaware of its existance
It is a shame the RPZ addon is not in the addon list.
Yes, but may the discussion will come up again ? Who knows. Nevertheless, the idea behind creating this repo was to address some concerns raised at or at least to show some movement and the willingness to work on some of the points mentioned as good as possible.
Best,
Erik
As a beneath one:
A short description and mention of how to integrate lists from the repo into the RPZ Web User Interface have been added .
It is in the roadmap here www.ipfire.org - Response Policy Zone (RPZ) and I really hope it will be approved and released soon.
It has been put into the directory as a work in progress but it has not been referenced in the roadmap directory itself
https://www.ipfire.org/docs/roadmap
The last communication on this topic in the developers mailing list was 23rd May 2025.
One or more of the people listed in the roadmap as working on this need to pick it up in the dev mailing list and follow up on the questions that have been raised.
Erik ( @ummeegge ) did a great job since then.
As far as I understand the discussion on the mailing list, the main topic where the origin of the lists and their licensing.
The collection on Erik’s github page and the conversation tool are a very good start point to establish DNS filtering similiar to IP filtering ( IP Block Lists ).
The IBLs are controlled by IPFire, this would be possible with Eriks work also. The real update is implemented in Unbound yet. Updating of the lists from the various sources can be done locally or in the IPFire infrastructure. I would prefer a central solution; the data transfer is done for many installations only once. The transfer from server to IPFire system is controlled by the SOA mechanism.
The questions asked were all answered in the dev mailing list
just in case one missed it:
Q. * The problem are the sources and the quality of the blacklists.
Unless those are available to us and our users the entire technology is
becoming worthless. This is exactly what we have with the URL filter.
A. To me this is similar to many other open source items. If the head
MFiC walks away, then the open source becomes toast. If the projects is
sold or transferred to a paid service, then the open source project is
toast. I don’t like it, but unless IPFire becomes the mix-master of
blocklists (collect, filter, publish, etc.) then there is no way around
this.
==
Q. * Unbound itself is a whole mess and I hope we will be able to launch
our plans to replace it as soon as possible.
A. This one I cannot answer since I don’t know the issues others have
experienced. I started near the time when IPFire went from dnsmasq to
unbound and to me unbound seems A-OK. But again I don’t know the
issues.
https://lists.ipfire.org/development/02C0C954-80A6-4090-9056-EA114E8CB36B@ipfire.org/T/#mc51823a704e8be19ed1e0d45005dcd8b2f39ba95
