Re: Let's launch our own blocklists...

[Michael Tremer <michael.tremer@ipfire.org>]

Hello Adam,

> On 23 Jan 2026, at 19:31, Adam Gibbons <adam.gibbons@ipfire.org> wrote:
> 
> On 22/01/2026 11:33 am, Michael Tremer wrote:
>> Hello everyone,
> 
> Hi Michael and Everyone,
> 
>> Over the past few weeks I have made significant progress on this all, and I think we're getting close to something the community will be really happy with. I'd love to get feedback from the team before we finalise things.
> 
> I've been keeping an eye on the development of IPFire DBL (RIP DNSBL) since the beginning and I agree the community should be very happy with it.
> 
> Having our own trusted, properly maintained blocklists that fit nicely into IPFire (and the wider adblock/domain-blocking ecosystem) makes IPFire a more complete UTM solution while expanding the IPFire brand.
> 
> I think we can make IPFire DBL a trusted alternative to the random lists hosted on the internet these days. Even the small things like DNSSEC by default, removing dead domains,and being able to track additions/removals over time will help build trust.
> 
> With the help of the community we can further refine the lists and make IPFire DBL something that attracts attention to the project as a whole.

Well said.

> 
>> I have added a couple more lists that I thought interesting and I have added a couple more sources that I considered a good start. Hopefully, we will soon gather some more feedback on how well this is all holding up. My main focus has however been on the technology that will power this project.
> 
> I've been using several of the lists for a few weeks now and the number of false-positives has been minimal for my use-case. It has even passed the dreaded "wife test", so I think this is ready for wider testing.

The “wife test” is particularly important for this :)

>> One of the bigger challenges was to create Suricata rules from the lists. Initially I tried to create a ton of rules but since our lists are so large, this quickly became too complicated. I have now settled on using a feature that is only available in more recent versions of Suricata (I believe 7 and later), but since we are already on Suricata 8 in IPFire this won't be a problem for us. All domains for each list are basically compiled into one massively large dataset and one single rule is referring to that dataset. This way, we won't have the option to remove any false-positives, but at least Suricata and the GUI won't starve a really bad death when loading millions of rules.
> 
> Yes, the IPFire DBL rules in IPS currently block all domains on the list without the ability to de-select false-positives. Luckily the reporting feature is very easy to use.
> 
> As mentioned previously, domain blocking in Suricata isn't intended to be the optimal way to handle DNS blocking because connections are dropped rather than returning a DNS response such as NXDOMAIN, so it's best used as a policy backstop.
> 
> For scenarios like schools using the "violence" list this will be perfect, though it might make some websites look/act unusual if the "advertising" list is used. But every scenario is different.
> 
> We see similar effects when people enable the "emerging-dns.rule" ruleset where the ".cc" TLD is blocked by default. Quite often because of the way it's dropped, it's sometimes difficult to diagnose because of the unusual UX. It pops up on the forum occasionally.

You can still have Suricata block the other protocols and disable the DNS rule in each of the categories. That way, you won’t have this problem.

>> Looking ahead, I would like us to start thinking about the RPZ feature that has been on the wishlist. IPFire DBL has been a bigger piece of work, and I think it's worth having a conversation about sustainability. Resources for this need to be allocated and paid for. Open source is about freedom, not free beer — and to keep building features like this, we will need to explore some funding options. I would be interested to hear any ideas you might have that could work for IPFire.
> 
> The community has been seeking a solution like this for some time now. It's great to see the start of what it will end up being. With community support, both funding and false-positive reporting, this can go a long way.

True. I am awaiting their test feedback on this so that we can move forward soon.

> Thank you for the work towards this, Michael.

Pleasure.

> Regards,
> Adam
>