From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [IPv6:::1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4dySjt1C1Gz30Kj for ; Fri, 23 Jan 2026 19:32:02 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [IPv6:2001:678:b28::25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (secp384r1 raw public key) server-digest SHA384 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail01.haj.ipfire.org", Issuer "R12" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4dySjp5Yc8z2xKR for ; Fri, 23 Jan 2026 19:31:58 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4dySjn0ScLz2V5 for ; Fri, 23 Jan 2026 19:31:57 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1769196717; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ndtdq1VIr8nboabQ6MbJGdKg40c1B1kvRaODtbU+pBQ=; b=BR9pYUtmQF8wVNspJvatkpS6v13IJ8qjXD/2/TtBUSVKGSsFkUQkHtQ8O4TOkHHfKHQt7w jkFyFWEledIi8tAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1769196717; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ndtdq1VIr8nboabQ6MbJGdKg40c1B1kvRaODtbU+pBQ=; b=p+VNmfTvR3pp0lowwl8R/KdFTniuEE7vK0yCvFTcAhSi1FI/KCs68ht5rQFJHWCJcqy+EG 8HZEV32sWOwO10IwlyY6pUJQjhAv7J+0FxY+4TvSlR8cyX99EttabT1sNGBixG+5G+gVz1 uiThbEFNW7RUgXcwurGOsujBbFeFFg9N3DGNCFAZiBDnVyuVYes3WSNbBjzo+UkzJjPaRG 5FHVv8skp1jmq7jtbtTbOOVJ34lzvnhIqUJmmQQYeE/uixPEW/qwmqfqwWhdXwcKjeE0SJ R1yB4uVUOv49inbKrGJIrAN4L3F9iCoVZE/txhjjtG+zGS84tpiTdPaISFU7AA== Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: MIME-Version: 1.0 Date: Fri, 23 Jan 2026 19:31:55 +0000 From: Adam Gibbons To: development@lists.ipfire.org Subject: Re: Let's launch our own blocklists... In-Reply-To: <0B3D624B-9AF8-474A-B6F2-58F78665CB12@ipfire.org> References: <7EF00B55-81C0-493F-A70F-B1DDD45363E2@ipfire.org> <9ac9c734-51fb-4152-bc0b-d2442d03d42a@ipfire.org> <5936cb35-c243-4b0f-843f-e6354226f9be@ipfire.org> <0bc86e25-903a-42a5-a338-72defd31c606@ipfire.org> <6AD00CB0-4937-4F7F-B67B-E88D870B4942@ipfire.org> <92BFE2B7-549F-41EC-ADC9-D2D7A29BEC82@ipfire.org> <0B3D624B-9AF8-474A-B6F2-58F78665CB12@ipfire.org> Message-ID: <04b9ec03c6898d165e05f7bfc821c0b6@ipfire.org> X-Sender: adam.gibbons@ipfire.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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. > 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. > 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. > 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. Thank you for the work towards this, Michael. Regards, Adam