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 4dzZC63c4dz3320 for ; Sun, 25 Jan 2026 14:42:42 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519) (Client CN "mail01.haj.ipfire.org", Issuer "R12" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4dzZC26xbMz2xJy for ; Sun, 25 Jan 2026 14:42:38 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4dzZC20t4lz5Z9; Sun, 25 Jan 2026 14:42:38 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1769352158; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=b6kCasnAxWNkxdu6EsKAszrTHeiKpS0r3BOMSh0+xdk=; b=apW/BiQHxyCu0VDn6Xb5sUEektwwlB/S7ZQ9gx2ZpLGbhVCM+GRGgWl5uXJ0qgRd2+Ish2 GEonRVoXzGGSGnAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1769352158; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=b6kCasnAxWNkxdu6EsKAszrTHeiKpS0r3BOMSh0+xdk=; b=kPjlbbjVeaRCt0Hw0mMxehicfAbO4PwWN/cgQCQpyPjmvGK0vg8FUnksdnoL1WMX1iwEEQ UWk2c8muggy43NWE+qry3v98obuHGnfidxBaYwqiPdeyVQnIQYsZjubu0hoh9tM+GG50sn v5Zpd4W7+f2SfMYY009JWYPD7icQDajTTRF4VRIPCAKJOoBaF13SCbCgZbg2JXw/YpVB5o Jo6wgH2ESqvid8m5nl3s4LlZtBKRwm1GhDmR6+DV55JQYSo7+FakJpbf0naKSFYWeCbXYC tRUvQmJ7MUpW8fcm5OY9lxoEbPYgC2sc/v9l6/zl3LZbuartRdDuMo/qJR4F9w== Content-Type: text/plain; charset=utf-8 Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: Mime-Version: 1.0 Subject: Re: Let's launch our own blocklists... From: Michael Tremer In-Reply-To: <04b9ec03c6898d165e05f7bfc821c0b6@ipfire.org> Date: Sun, 25 Jan 2026 14:42:37 +0000 Cc: development@lists.ipfire.org Content-Transfer-Encoding: quoted-printable Message-Id: 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> <04b9ec03c6898d165e05f7bfc821c0b6@ipfire.org> To: Adam Gibbons Hello Adam, > On 23 Jan 2026, at 19:31, Adam Gibbons = wrote: >=20 > On 22/01/2026 11:33 am, Michael Tremer wrote: >> Hello everyone, >=20 > Hi Michael and Everyone, >=20 >> 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 >> 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. >=20 > 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 =E2=80=9Cwife test=E2=80=9D 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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=E2=80=99t 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 =E2=80=94 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. >=20 > 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 >=20