I think the init.d unbound code may be incorrect as it creates the dnsbl.conf file and I did a manual change of the dnsbl.conf file as a test. After I made the manual changes, RPZ started to work with multiple categories (e.g. ads, dating, doh)

Each `local network="${COLOR_NETADDRESS}/$"` probably needs their own access-control-tag.

===

# this section was added at the end of the dnsbl.conf file (it needs to be after the `define-tag:` lines)

server:
access-control-tag: 192.168.74.0/24 "ads.rpz.ipfire.org dating.rpz.ipfire.org doh.rpz.ipfire.org gambling.rpz.ipfire.org games.rpz.ipfire.org" # green

access-control-tag: 192.168.75.0/24 "ads.rpz.ipfire.org dating.rpz.ipfire.org doh.rpz.ipfire.org gambling.rpz.ipfire.org games.rpz.ipfire.org" # blue

===


This will allow the RPZ to work on more than one (or maybe two) categories.


------ Original Message ------
From "Michael Tremer" <[email protected]>
To "Jon Murphy" <[email protected]>
Cc "Adolf Belka" <[email protected]>; "IPFire: Development-List" <[email protected]>; [email protected]
Date 3/25/2026 4:30:32 AM
Subject Re: Feedback on issues with DNSFW in CU201 Testing

Hello Jon,

Why would it be necessary to manually change the configuration?

Can you explain to us what you are thinking?

 On 24 Mar 2026, at 21:03, Jon Murphy <[email protected]> wrote:

 Try this in the dnsbl.conf file.

 server:
    define-tag: "ads.rpz.ipfire.org dating.rpz.ipfire.org"

 server:
    access-control-tag: 192.168.74.0/24 "ads.rpz.ipfire.org 
dating.rpz.ipfire.org"


 Separate "access-control-tag" don’t seem to work.

What is this supposed to mean?

-Michael


 The above changes allows RPZ to work as expected.



 ------ Original Message ------
 From "Michael Tremer" <[email protected]>
 To "Adolf Belka" <[email protected]>
 Cc [email protected]; [email protected]
 Date 3/23/2026 9:41:07 AM
 Subject Re: Feedback on issues with DNSFW in CU201 Testing

 Hello,

 So this looks good. The list has been properly loaded into Unbound.

 I don’t quite know what could be going wrong now.

 -Michael

 On 23 Mar 2026, at 12:22, Adolf Belka <[email protected]> wrote:

 Hi Michael,

 On 23/03/2026 12:10, Michael Tremer wrote:
 Hello Adolf,
 What is the output of unbound-control list_auth_zones?

 porn.rpz.ipfire.org.    serial 1773964805        since 1774267487 
2026-03-23T13:04:47
 gambling.rpz.ipfire.org       serial 1773997205        since 1774267487 
2026-03-23T13:04:47

 Regards,

 Adolf.

 -Michael
 On 20 Mar 2026, at 16:59, Adolf Belka <[email protected]> wrote:

 Hi Michael,

 On 20/03/2026 16:56, Michael Tremer wrote:
 Hello Adolf,
 I am copying the DBL list, too.

 Good idea. I was just thinking of it being related to Testing issue.
 So this is obviously not normal, but we can debug this step by step:
 First of all, we should check if Unbound was able to successfully fetch the 
DNS zones. Gambling has clearly been downloaded, but it seems that the Porn 
list might not. You can check in /var/cache/unbound if there is the zone file. 
If yes, then you can try to resolve a couple of things on the console and check 
if they are being blocked:

 I should have already mentioned this but forgot. It was one of the first 
things I checked and I have just re-confirmed now. The porn zone file is 
present. It was updated at 11:40 CET and the Gambling zone was updated at 12:53 
CET.

 I also checked that the zone file contained the url's being used and it did 
and does.

 # dig @localhost some.porn.website.com <http://some.porn.website.com/>
 You should see NXDOMAIN if the domain exists and has been blocked and you 
should see the log entries just like gambling.

 Got

 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 54293
 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

 So NXDOMAIN is in the answer but there was nothing additional in the unbound 
log. The last entry in it was from 12:58:50 when I did the tests with the 
gambling sites and if there was an entry it should have a timestamp for around 
17:45

 This rules out anything that is going wrong between the browser and Unbound.
 In case of the URL filter, it simply seems that squidguard is not seeing the 
requests. You might as well try something like:

 With the URL Filter enabled and DNSFW disabled then the URL Filter blocks and 
logs both the Gambling and Porn site accesses. Sorry if that came across as 
differently in my mail. The URL Filter works fine for me with both CU200 and 
CU201 Testing.

 # http_proxy=http://1.2.3.4:800 <http://1.2.3.4:800/> https_proxy=http://1.2.3.4:800 
<http://1.2.3.4:800/> wget -d http://some.porn.website.com 
<http://some.porn.website.com/>
 The squidguard.log should also contain some interesting information if 
something didn’t go as planned.
 -Michael
 On 20 Mar 2026, at 12:30, Adolf Belka <[email protected]> wrote:

 Hi All,

 I am having issues with getting DNSFW to work properly, it fails in many 
conditions to block things from the list.

 The dbl list works fine for me in the URL Filter for both CU200 and CU201 
Testing.

 For my testing I created a new install of CU201 Testing and just went straight 
to DNSFW and enabled the Gambling and Pornography categories and Saved.

 Then selected the Green network for both categories using the pencil edit 
option.

 In this setup I had no Web Proxy enabled.

 I then cleared the browser cache and set the Browser to No Proxy.

 I then tested out nl.onecasino.com and www.xnxx.com in Firefox and in Netsurf

 The gambling site was blocked and gave the message

 Unable to connect
 Firefox can’t establish a connection to the server at nl.onecasino.com.

 For the porn site it was not blocked but opened up.
 I tried with two other gambling and porn sites. All three gambling sites were 
blocked. All three porn sites were allowed through.

 In the DND: Unbound System Logs I found

 12:52:26 unbound: [1820:0]  info: rpz: applied [gambling.rpz.ipfire.org] 
*.postcodeloterij.nl. rpz-nxdomain 192.168.200.11@44247 www.postcodeloterij.nl. 
A IN
 12:52:26 unbound: [1820:0]  info: rpz: applied [gambling.rpz.ipfire.org] 
*.postcodeloterij.nl. rpz-nxdomain 192.168.200.11@44356 www.postcodeloterij.nl. 
HTTPS IN
 12:51:32 unbound: [1820:0]  info: rpz: applied [gambling.rpz.ipfire.org] 
*.onecasino.com. rpz-nxdomain 192.168.200.11@55955 nl.onecasino.com. A IN
 12:51:32 unbound: [1820:0]  info: rpz: applied [gambling.rpz.ipfire.org] 
*.onecasino.com. rpz-nxdomain 192.168.200.11@49136 nl.onecasino.com. HTTPS IN
 12:50:41 unbound: [1820:0]  info: rpz: applied [gambling.rpz.ipfire.org] 
*.hollandcasino.nl. rpz-nxdomain 192.168.200.11@47229 welkom.hollandcasino.nl. 
A IN
 12:50:41 unbound: [1820:0]  info: rpz: applied [gambling.rpz.ipfire.org] 
*.hollandcasino.nl. rpz-nxdomain 192.168.200.11@43346 welkom.hollandcasino.nl. 
HTTPS IN

 So the blocked gambling sites were in the logs but not any of the pornography 
sites  had tested.

 Then tried the browser with the Network Settings set to Use system proxy 
settings and the same result occurred.

 I then turned on the Web Proxy with conventional connection on port 800. Saved 
and restarted and then Cleared the web proxy cache.
 Then I cleared the browser cache and set the Network Settings to Manual proxy 
configuration with the IP of my IPFire system being tested.

 I then tested the same three gambling URL's and Porn URL's.
 All of the sites were opened up.
 In the DNS: Unbound system log there were no new entries.
 In the Proxy Logs there were entries for the gambling and porn sites.

 I have also tested the browser out using the web proxy with the Automatic 
proxy configuration URL accessing the wpad file via dhcp and that also had the 
same results as using the Manual proxy configuration option.

 I have repeated a lot of my tests multiple times, also with repeated new 
installs and for me, as long as I ensured I had cleared the web proxy and 
browser caches, always came up with the same results as I have described above.

 It would be good to know if any of you also experience the same effect or if 
it works without problems for yourselves.

 Regards,

 Adolf.











Reply via email to