* Feedback on issues with DNSFW in CU201 Testing
@ 2026-03-20 12:30 Adolf Belka
2026-03-20 15:56 ` Michael Tremer
0 siblings, 1 reply; 18+ messages in thread
From: Adolf Belka @ 2026-03-20 12:30 UTC (permalink / raw)
To: IPFire: Development-List
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Feedback on issues with DNSFW in CU201 Testing
2026-03-20 12:30 Feedback on issues with DNSFW in CU201 Testing Adolf Belka
@ 2026-03-20 15:56 ` Michael Tremer
2026-03-20 16:59 ` Adolf Belka
0 siblings, 1 reply; 18+ messages in thread
From: Michael Tremer @ 2026-03-20 15:56 UTC (permalink / raw)
To: Adolf Belka; +Cc: IPFire: Development-List, dbl
Hello Adolf,
I am copying the DBL list, too.
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:
# 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.
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:
# 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 <adolf.belka@ipfire.org> 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.
>
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Feedback on issues with DNSFW in CU201 Testing
2026-03-20 15:56 ` Michael Tremer
@ 2026-03-20 16:59 ` Adolf Belka
2026-03-23 11:10 ` Michael Tremer
0 siblings, 1 reply; 18+ messages in thread
From: Adolf Belka @ 2026-03-20 16:59 UTC (permalink / raw)
To: Michael Tremer; +Cc: development, dbl
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 <adolf.belka@ipfire.org> 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.
>>
>>
>
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Feedback on issues with DNSFW in CU201 Testing
2026-03-20 16:59 ` Adolf Belka
@ 2026-03-23 11:10 ` Michael Tremer
2026-03-23 12:22 ` Adolf Belka
0 siblings, 1 reply; 18+ messages in thread
From: Michael Tremer @ 2026-03-23 11:10 UTC (permalink / raw)
To: Adolf Belka; +Cc: development, dbl
Hello Adolf,
What is the output of unbound-control list_auth_zones?
-Michael
> On 20 Mar 2026, at 16:59, Adolf Belka <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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.
>>>
>>>
>
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Feedback on issues with DNSFW in CU201 Testing
2026-03-23 11:10 ` Michael Tremer
@ 2026-03-23 12:22 ` Adolf Belka
2026-03-23 14:41 ` Michael Tremer
0 siblings, 1 reply; 18+ messages in thread
From: Adolf Belka @ 2026-03-23 12:22 UTC (permalink / raw)
To: Michael Tremer; +Cc: development, dbl
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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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.
>>>>
>>>>
>>
>>
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Feedback on issues with DNSFW in CU201 Testing
2026-03-23 12:22 ` Adolf Belka
@ 2026-03-23 14:41 ` Michael Tremer
2026-03-24 21:03 ` Re[2]: " Jon Murphy
0 siblings, 1 reply; 18+ messages in thread
From: Michael Tremer @ 2026-03-23 14:41 UTC (permalink / raw)
To: Adolf Belka; +Cc: development, dbl
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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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.
>>>>>
>>>>>
>>>
>>>
>
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re[2]: Feedback on issues with DNSFW in CU201 Testing
2026-03-23 14:41 ` Michael Tremer
@ 2026-03-24 21:03 ` Jon Murphy
2026-03-25 9:30 ` Michael Tremer
0 siblings, 1 reply; 18+ messages in thread
From: Jon Murphy @ 2026-03-24 21:03 UTC (permalink / raw)
To: Michael Tremer, Adolf Belka; +Cc: IPFire: Development-List, dbl
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.
The above changes allows RPZ to work as expected.
------ Original Message ------
From "Michael Tremer" <michael.tremer@ipfire.org>
To "Adolf Belka" <adolf.belka@ipfire.org>
Cc development@lists.ipfire.org; dbl@lists.ipfire.org
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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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.
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Feedback on issues with DNSFW in CU201 Testing
2026-03-24 21:03 ` Re[2]: " Jon Murphy
@ 2026-03-25 9:30 ` Michael Tremer
2026-03-25 11:58 ` Adolf Belka
2026-03-25 15:17 ` Jon Murphy
0 siblings, 2 replies; 18+ messages in thread
From: Michael Tremer @ 2026-03-25 9:30 UTC (permalink / raw)
To: Jon Murphy; +Cc: Adolf Belka, IPFire: Development-List, dbl
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 <jon.murphy@ipfire.org> 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" <michael.tremer@ipfire.org>
> To "Adolf Belka" <adolf.belka@ipfire.org>
> Cc development@lists.ipfire.org; dbl@lists.ipfire.org
> 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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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.
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Feedback on issues with DNSFW in CU201 Testing
2026-03-25 9:30 ` Michael Tremer
@ 2026-03-25 11:58 ` Adolf Belka
2026-03-25 13:43 ` Adolf Belka
2026-03-25 15:17 ` Jon Murphy
1 sibling, 1 reply; 18+ messages in thread
From: Adolf Belka @ 2026-03-25 11:58 UTC (permalink / raw)
To: Michael Tremer; +Cc: Jon Murphy, IPFire: Development-List, dbl
Hi Michael and Jon,
On 25/03/2026 10:30, Michael Tremer wrote:
> Hello Jon,
>
> Why would it be necessary to manually change the configuration?
>
> Can you explain to us what you are thinking?
I think the argument is that the define-tag and access-control-tag options should not be multiple entries but single entries with multiple tags space separated in the "" section.
>
>> On 24 Mar 2026, at 21:03, Jon Murphy <jon.murphy@ipfire.org> 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"
Tried this but it made no difference. I suspect this might be that unbound needs to reload the config file if it has been changed and running unbound reload results in the dnsbl.conf file being updated with what is on the WUI page, so it goes back to the version before it was manually edited.
However this made me wonder what would happen if I only had the porn entry selected and not both the porn and gambling.
The result, with the browser network option set to No Proxy was that all porn sites were now blocked.
I then wondered what would happen if I chose two different categories where the working gambling one was after another category. So I tested out Dating and Gambling.
First tested out Dating on its own.
It blocked for academysingles.com and loopylove.com
Then I enabled both Dating and Gambling. In this case the two dating urls were still blocked but now all the urls that I had previously used, when testing out Gambling and Porn categories together, were no longer blocked.
If I disabled the Dating category then the Gambling sites were blocked again.
This was also found in the DNS: Unbound logs.
So it looks like if there are multiple categories selected then only the urls from the first category get blocked.
Regards,
Adolf.
>>
>>
>> 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" <michael.tremer@ipfire.org>
>> To "Adolf Belka" <adolf.belka@ipfire.org>
>> Cc development@lists.ipfire.org; dbl@lists.ipfire.org
>> 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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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.
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Feedback on issues with DNSFW in CU201 Testing
2026-03-25 11:58 ` Adolf Belka
@ 2026-03-25 13:43 ` Adolf Belka
2026-04-09 10:20 ` Michael Tremer
0 siblings, 1 reply; 18+ messages in thread
From: Adolf Belka @ 2026-03-25 13:43 UTC (permalink / raw)
To: Michael Tremer; +Cc: Jon Murphy, IPFire: Development-List, dbl
Hi Michael & Jon,
On 25/03/2026 12:58, Adolf Belka wrote:
> Hi Michael and Jon,
>
> On 25/03/2026 10:30, Michael Tremer wrote:
>> Hello Jon,
>>
>> Why would it be necessary to manually change the configuration?
>>
>> Can you explain to us what you are thinking?
>
> I think the argument is that the define-tag and access-control-tag options should not be multiple entries but single entries with multiple tags space separated in the "" section.
At least the access-control-tag option has to be able to be used multiple times. If you have three categories defined, one with green selected another with blue and the last with orange then there has to be at least three access-control-tags because each of the subnets has a different category assigned to it.
I also found a similar situation outlined in the unbound documentation where they have four access-control-tags defined.
https://unbound.docs.nlnetlabs.nl/en/latest/topics/filtering/tags-views.html#tags
Regards,
Adolf.
>
>>
>>> On 24 Mar 2026, at 21:03, Jon Murphy <jon.murphy@ipfire.org> 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"
>
> Tried this but it made no difference. I suspect this might be that unbound needs to reload the config file if it has been changed and running unbound reload results in the dnsbl.conf file being updated with what is on the WUI page, so it goes back to the version before it was manually edited.
>
> However this made me wonder what would happen if I only had the porn entry selected and not both the porn and gambling.
>
> The result, with the browser network option set to No Proxy was that all porn sites were now blocked.
>
> I then wondered what would happen if I chose two different categories where the working gambling one was after another category. So I tested out Dating and Gambling.
>
> First tested out Dating on its own.
>
> It blocked for academysingles.com and loopylove.com
>
> Then I enabled both Dating and Gambling. In this case the two dating urls were still blocked but now all the urls that I had previously used, when testing out Gambling and Porn categories together, were no longer blocked.
>
> If I disabled the Dating category then the Gambling sites were blocked again.
>
> This was also found in the DNS: Unbound logs.
>
> So it looks like if there are multiple categories selected then only the urls from the first category get blocked.
>
> Regards,
>
> Adolf.
>
>
>>>
>>>
>>> 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" <michael.tremer@ipfire.org>
>>> To "Adolf Belka" <adolf.belka@ipfire.org>
>>> Cc development@lists.ipfire.org; dbl@lists.ipfire.org
>>> 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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>
>>
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Feedback on issues with DNSFW in CU201 Testing
2026-03-25 9:30 ` Michael Tremer
2026-03-25 11:58 ` Adolf Belka
@ 2026-03-25 15:17 ` Jon Murphy
1 sibling, 0 replies; 18+ messages in thread
From: Jon Murphy @ 2026-03-25 15:17 UTC (permalink / raw)
To: IPFire: Development-List
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" <michael.tremer@ipfire.org>
To "Jon Murphy" <jon.murphy@ipfire.org>
Cc "Adolf Belka" <adolf.belka@ipfire.org>; "IPFire: Development-List"
<development@lists.ipfire.org>; dbl@lists.ipfire.org
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 <jon.murphy@ipfire.org> 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" <michael.tremer@ipfire.org>
>> To "Adolf Belka" <adolf.belka@ipfire.org>
>> Cc development@lists.ipfire.org; dbl@lists.ipfire.org
>> 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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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.
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Feedback on issues with DNSFW in CU201 Testing
2026-03-25 13:43 ` Adolf Belka
@ 2026-04-09 10:20 ` Michael Tremer
2026-04-10 9:33 ` Adolf Belka
0 siblings, 1 reply; 18+ messages in thread
From: Michael Tremer @ 2026-04-09 10:20 UTC (permalink / raw)
To: Adolf Belka; +Cc: Jon Murphy, IPFire: Development-List, dbl
Hello Adolf,
Could you please let me know is this fixes the problem?
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=e3c11ae3436b578432df0058eee229f262791254
Best,
-Michael
> On 25 Mar 2026, at 13:43, Adolf Belka <adolf.belka@ipfire.org> wrote:
>
> Hi Michael & Jon,
>
> On 25/03/2026 12:58, Adolf Belka wrote:
>> Hi Michael and Jon,
>> On 25/03/2026 10:30, Michael Tremer wrote:
>>> Hello Jon,
>>>
>>> Why would it be necessary to manually change the configuration?
>>>
>>> Can you explain to us what you are thinking?
>> I think the argument is that the define-tag and access-control-tag options should not be multiple entries but single entries with multiple tags space separated in the "" section.
>
> At least the access-control-tag option has to be able to be used multiple times. If you have three categories defined, one with green selected another with blue and the last with orange then there has to be at least three access-control-tags because each of the subnets has a different category assigned to it.
>
> I also found a similar situation outlined in the unbound documentation where they have four access-control-tags defined.
>
> https://unbound.docs.nlnetlabs.nl/en/latest/topics/filtering/tags-views.html#tags
>
> Regards,
>
> Adolf.
>
>>>
>>>> On 24 Mar 2026, at 21:03, Jon Murphy <jon.murphy@ipfire.org> 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"
>> Tried this but it made no difference. I suspect this might be that unbound needs to reload the config file if it has been changed and running unbound reload results in the dnsbl.conf file being updated with what is on the WUI page, so it goes back to the version before it was manually edited.
>> However this made me wonder what would happen if I only had the porn entry selected and not both the porn and gambling.
>> The result, with the browser network option set to No Proxy was that all porn sites were now blocked.
>> I then wondered what would happen if I chose two different categories where the working gambling one was after another category. So I tested out Dating and Gambling.
>> First tested out Dating on its own.
>> It blocked for academysingles.com and loopylove.com
>> Then I enabled both Dating and Gambling. In this case the two dating urls were still blocked but now all the urls that I had previously used, when testing out Gambling and Porn categories together, were no longer blocked.
>> If I disabled the Dating category then the Gambling sites were blocked again.
>> This was also found in the DNS: Unbound logs.
>> So it looks like if there are multiple categories selected then only the urls from the first category get blocked.
>> Regards,
>> Adolf.
>>>>
>>>>
>>>> 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" <michael.tremer@ipfire.org>
>>>> To "Adolf Belka" <adolf.belka@ipfire.org>
>>>> Cc development@lists.ipfire.org; dbl@lists.ipfire.org
>>>> 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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Feedback on issues with DNSFW in CU201 Testing
2026-04-09 10:20 ` Michael Tremer
@ 2026-04-10 9:33 ` Adolf Belka
2026-04-10 10:09 ` Adolf Belka
0 siblings, 1 reply; 18+ messages in thread
From: Adolf Belka @ 2026-04-10 9:33 UTC (permalink / raw)
To: Michael Tremer; +Cc: Jon Murphy, IPFire: Development-List
Hi Michael,
On 09/04/2026 12:20, Michael Tremer wrote:
> Hello Adolf,
>
> Could you please let me know is this fixes the problem?
It has solved the problem when the browser is set up to use No Proxy or System Proxy and the PC has no proxy set up.
I was able to select Advertising, Dating, Gambling, Pornography, Shopping and Streaming at the same time and trying to access URL's from the lists of those zones caused the access to be blocked. Yaaah. Entries for all these categories found in the unbound log.
Unfortunately when I changed the browser to use IPFire as the web proxy (Conventional mode) by selecting Manual proxy configuration in the browser and specifying the IPFire IP all accesses to the selected categories listed above were allowed to be accessed except for the url for the shopping site. That was still blocked and in the unbound log there was an entry for the shopping site but no entries for any of the other category url's I had just accessed and that were allowed.
So problem is fixed for when the IPFire web proxy is not used by the browser but there is still an issue when working via the proxy.
I will check some more shopping site url's to see if the shopping site issue is consistent for multiple url's or only that one. I thought it might be that the url no longer exists but it is in the unbound logs getting blocked by the DNSFW. So the question would be why that url gets blocked by the DNSFW via the web proxy when the other Category url's are not shown in the unbound log at all.
Regards,
Adolf.
>
> https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=e3c11ae3436b578432df0058eee229f262791254
>
> Best,
> -Michael
>
>> On 25 Mar 2026, at 13:43, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>
>> Hi Michael & Jon,
>>
>> On 25/03/2026 12:58, Adolf Belka wrote:
>>> Hi Michael and Jon,
>>> On 25/03/2026 10:30, Michael Tremer wrote:
>>>> Hello Jon,
>>>>
>>>> Why would it be necessary to manually change the configuration?
>>>>
>>>> Can you explain to us what you are thinking?
>>> I think the argument is that the define-tag and access-control-tag options should not be multiple entries but single entries with multiple tags space separated in the "" section.
>>
>> At least the access-control-tag option has to be able to be used multiple times. If you have three categories defined, one with green selected another with blue and the last with orange then there has to be at least three access-control-tags because each of the subnets has a different category assigned to it.
>>
>> I also found a similar situation outlined in the unbound documentation where they have four access-control-tags defined.
>>
>> https://unbound.docs.nlnetlabs.nl/en/latest/topics/filtering/tags-views.html#tags
>>
>> Regards,
>>
>> Adolf.
>>
>>>>
>>>>> On 24 Mar 2026, at 21:03, Jon Murphy <jon.murphy@ipfire.org> 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"
>>> Tried this but it made no difference. I suspect this might be that unbound needs to reload the config file if it has been changed and running unbound reload results in the dnsbl.conf file being updated with what is on the WUI page, so it goes back to the version before it was manually edited.
>>> However this made me wonder what would happen if I only had the porn entry selected and not both the porn and gambling.
>>> The result, with the browser network option set to No Proxy was that all porn sites were now blocked.
>>> I then wondered what would happen if I chose two different categories where the working gambling one was after another category. So I tested out Dating and Gambling.
>>> First tested out Dating on its own.
>>> It blocked for academysingles.com and loopylove.com
>>> Then I enabled both Dating and Gambling. In this case the two dating urls were still blocked but now all the urls that I had previously used, when testing out Gambling and Porn categories together, were no longer blocked.
>>> If I disabled the Dating category then the Gambling sites were blocked again.
>>> This was also found in the DNS: Unbound logs.
>>> So it looks like if there are multiple categories selected then only the urls from the first category get blocked.
>>> Regards,
>>> Adolf.
>>>>>
>>>>>
>>>>> 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" <michael.tremer@ipfire.org>
>>>>> To "Adolf Belka" <adolf.belka@ipfire.org>
>>>>> Cc development@lists.ipfire.org; dbl@lists.ipfire.org
>>>>> 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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Feedback on issues with DNSFW in CU201 Testing
2026-04-10 9:33 ` Adolf Belka
@ 2026-04-10 10:09 ` Adolf Belka
2026-04-10 16:46 ` Jon Murphy
0 siblings, 1 reply; 18+ messages in thread
From: Adolf Belka @ 2026-04-10 10:09 UTC (permalink / raw)
To: Michael Tremer; +Cc: Jon Murphy, IPFire: Development-List
Hi Michael,
On 10/04/2026 11:33, Adolf Belka wrote:
> Hi Michael,
>
> On 09/04/2026 12:20, Michael Tremer wrote:
>> Hello Adolf,
>>
>> Could you please let me know is this fixes the problem?
>
> It has solved the problem when the browser is set up to use No Proxy or System Proxy and the PC has no proxy set up.
>
> I was able to select Advertising, Dating, Gambling, Pornography, Shopping and Streaming at the same time and trying to access URL's from the lists of those zones caused the access to be blocked. Yaaah. Entries for all these categories found in the unbound log.
>
>
> Unfortunately when I changed the browser to use IPFire as the web proxy (Conventional mode) by selecting Manual proxy configuration in the browser and specifying the IPFire IP all accesses to the selected categories listed above were allowed to be accessed except for the url for the shopping site. That was still blocked and in the unbound log there was an entry for the shopping site but no entries for any of the other category url's I had just accessed and that were allowed.
>
> So problem is fixed for when the IPFire web proxy is not used by the browser but there is still an issue when working via the proxy.
>
> I will check some more shopping site url's to see if the shopping site issue is consistent for multiple url's or only that one. I thought it might be that the url no longer exists but it is in the unbound logs getting blocked by the DNSFW. So the question would be why that url gets blocked by the DNSFW via the web proxy when the other Category url's are not shown in the unbound log at all.
Further follow-up. After the test above with the web proxy being used where the web sites were allowed to be accessed, I left the browser open with the opened tabs.
Although the sites were not blocked by DNSFW via the web proxy, except for the shopping url, DNSFW did then stop some Mozilla telemetry accesses via the ads zone.
11:22:13 unbound: [1741:0] info: rpz: applied [shopping.rpz.ipfire.org] 1000islandsphotoart.com. rpz-nxdomain 127.0.0.1@42131 1000islandsphotoart.com. A IN
11:38:12 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org] *.telemetry.mozilla.org. rpz-nxdomain 192.168.200.10@45618 incoming.telemetry.mozilla.org. A IN
11:40:12 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org] *.telemetry.mozilla.org. rpz-nxdomain 192.168.200.10@47126 incoming.telemetry.mozilla.org. A IN
11:42:20 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org] *.telemetry.mozilla.org. rpz-nxdomain 192.168.200.10@50709 incoming.telemetry.mozilla.org. A IN
11:46:20 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org] *.telemetry.mozilla.org. rpz-nxdomain 192.168.200.10@46388 incoming.telemetry.mozilla.org. A IN
11:54:20 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org] *.telemetry.mozilla.org. rpz-nxdomain 192.168.200.10@53250 incoming.telemetry.mozilla.org. A IN
11:55:25 unbound: [1741:0] info: rpz: applied [shopping.rpz.ipfire.org] 1000islandsphotoart.com. rpz-nxdomain 127.0.0.1@42131 1000islandsphotoart.com. A IN
11:55:31 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org] ads.mozilla.org. rpz-nxdomain 192.168.200.10@43432 ads.mozilla.org. A IN
11:55:31 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org] *.telemetry.mozilla.org. rpz-nxdomain 192.168.200.10@48485 incoming.telemetry.mozilla.org. A IN
The first line was the blocked shopping url after changing the browser to use the IPFire web proxy.
The second shopping block was when I cam back and tried the shopping url again to see if it was still blocked.
All the other mozilla related blocks must be the Firefox browser trying to open some things on the web pages that had previously been opened.
Regards,
Adolf.
>
> Regards,
>
> Adolf.
>
>>
>> https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=e3c11ae3436b578432df0058eee229f262791254
>>
>> Best,
>> -Michael
>>
>>> On 25 Mar 2026, at 13:43, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>>
>>> Hi Michael & Jon,
>>>
>>> On 25/03/2026 12:58, Adolf Belka wrote:
>>>> Hi Michael and Jon,
>>>> On 25/03/2026 10:30, Michael Tremer wrote:
>>>>> Hello Jon,
>>>>>
>>>>> Why would it be necessary to manually change the configuration?
>>>>>
>>>>> Can you explain to us what you are thinking?
>>>> I think the argument is that the define-tag and access-control-tag options should not be multiple entries but single entries with multiple tags space separated in the "" section.
>>>
>>> At least the access-control-tag option has to be able to be used multiple times. If you have three categories defined, one with green selected another with blue and the last with orange then there has to be at least three access-control-tags because each of the subnets has a different category assigned to it.
>>>
>>> I also found a similar situation outlined in the unbound documentation where they have four access-control-tags defined.
>>>
>>> https://unbound.docs.nlnetlabs.nl/en/latest/topics/filtering/tags-views.html#tags
>>>
>>> Regards,
>>>
>>> Adolf.
>>>
>>>>>
>>>>>> On 24 Mar 2026, at 21:03, Jon Murphy <jon.murphy@ipfire.org> 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"
>>>> Tried this but it made no difference. I suspect this might be that unbound needs to reload the config file if it has been changed and running unbound reload results in the dnsbl.conf file being updated with what is on the WUI page, so it goes back to the version before it was manually edited.
>>>> However this made me wonder what would happen if I only had the porn entry selected and not both the porn and gambling.
>>>> The result, with the browser network option set to No Proxy was that all porn sites were now blocked.
>>>> I then wondered what would happen if I chose two different categories where the working gambling one was after another category. So I tested out Dating and Gambling.
>>>> First tested out Dating on its own.
>>>> It blocked for academysingles.com and loopylove.com
>>>> Then I enabled both Dating and Gambling. In this case the two dating urls were still blocked but now all the urls that I had previously used, when testing out Gambling and Porn categories together, were no longer blocked.
>>>> If I disabled the Dating category then the Gambling sites were blocked again.
>>>> This was also found in the DNS: Unbound logs.
>>>> So it looks like if there are multiple categories selected then only the urls from the first category get blocked.
>>>> Regards,
>>>> Adolf.
>>>>>>
>>>>>>
>>>>>> 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" <michael.tremer@ipfire.org>
>>>>>> To "Adolf Belka" <adolf.belka@ipfire.org>
>>>>>> Cc development@lists.ipfire.org; dbl@lists.ipfire.org
>>>>>> 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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>
>>
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Feedback on issues with DNSFW in CU201 Testing
2026-04-10 10:09 ` Adolf Belka
@ 2026-04-10 16:46 ` Jon Murphy
2026-04-10 18:25 ` Adolf Belka
2026-04-15 21:24 ` Jon Murphy
0 siblings, 2 replies; 18+ messages in thread
From: Jon Murphy @ 2026-04-10 16:46 UTC (permalink / raw)
To: IPFire: Development-List; +Cc: Michael Tremer, Adolf Belka
[-- Attachment #1: Type: text/plain, Size: 18218 bytes --]
The recent update allows more than one category and seems to work OK (still testing).
Found a new issue; In the Firewall DNS > Access Control area > Custom Source a CIDR notation of 192.168.74.0/24 works OK, but the subnet mask notation of 192.168.74.0/255.255.255.0 throws this error:
Apr 10 11:25:45 ipfireAPU2 unbound: [1694:6] error: netblock too large: 192.168.74.0/255.255.255.0
Apr 10 11:25:45 ipfireAPU2 unbound: [1694:6] error: cannot parse netblock: 192.168.74.0/255.255.255.0
Apr 10 11:26:48 ipfireAPU2 dhcpd: execute_statement argv[0] = /usr/sbin/unbound-dhcp-leases-client
> On Apr 10, 2026, at 5:09 AM, Adolf Belka <adolf.belka@ipfire.org> wrote:
> Hi Michael,
>
> On 10/04/2026 11:33, Adolf Belka wrote:
> > Hi Michael,
> > On 09/04/2026 12:20, Michael Tremer wrote:
> > > Hello Adolf,
> > >
> > > Could you please let me know is this fixes the problem?
> > It has solved the problem when the browser is set up to use No Proxy or System Proxy and the PC has no proxy set up.
> > I was able to select Advertising, Dating, Gambling, Pornography, Shopping and Streaming at the same time and trying to access URL's from the lists of those zones caused the access to be blocked. Yaaah. Entries for all these categories found in the unbound log.
> > Unfortunately when I changed the browser to use IPFire as the web proxy (Conventional mode) by selecting Manual proxy configuration in the browser and specifying the IPFire IP all accesses to the selected categories listed above were allowed to be accessed except for the url for the shopping site. That was still blocked and in the unbound log there was an entry for the shopping site but no entries for any of the other category url's I had just accessed and that were allowed.
> > So problem is fixed for when the IPFire web proxy is not used by the browser but there is still an issue when working via the proxy.
> > I will check some more shopping site url's to see if the shopping site issue is consistent for multiple url's or only that one. I thought it might be that the url no longer exists but it is in the unbound logs getting blocked by the DNSFW. So the question would be why that url gets blocked by the DNSFW via the web proxy when the other Category url's are not shown in the unbound log at all.
>
> Further follow-up. After the test above with the web proxy being used where the web sites were allowed to be accessed, I left the browser open with the opened tabs.
>
> Although the sites were not blocked by DNSFW via the web proxy, except for the shopping url, DNSFW did then stop some Mozilla telemetry accesses via the ads zone.
>
> 11:22:13 unbound: [1741:0] info: rpz: applied [shopping.rpz.ipfire.org (http://shopping.rpz.ipfire.org/)] 1000islandsphotoart.com (http://1000islandsphotoart.com/). rpz-nxdomain 127.0.0.1@42131 1000islandsphotoart.com (http://1000islandsphotoart.com/). A IN
> 11:38:12 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org (http://ads.rpz.ipfire.org/)] *.telemetry.mozilla.org (http://telemetry.mozilla.org/). rpz-nxdomain 192.168.200.10@45618 incoming.telemetry.mozilla.org (http://incoming.telemetry.mozilla.org/). A IN
> 11:40:12 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org (http://ads.rpz.ipfire.org/)] *.telemetry.mozilla.org (http://telemetry.mozilla.org/). rpz-nxdomain 192.168.200.10@47126 incoming.telemetry.mozilla.org (http://incoming.telemetry.mozilla.org/). A IN
> 11:42:20 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org (http://ads.rpz.ipfire.org/)] *.telemetry.mozilla.org (http://telemetry.mozilla.org/). rpz-nxdomain 192.168.200.10@50709 incoming.telemetry.mozilla.org (http://incoming.telemetry.mozilla.org/). A IN
> 11:46:20 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org (http://ads.rpz.ipfire.org/)] *.telemetry.mozilla.org (http://telemetry.mozilla.org/). rpz-nxdomain 192.168.200.10@46388 incoming.telemetry.mozilla.org (http://incoming.telemetry.mozilla.org/). A IN
> 11:54:20 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org (http://ads.rpz.ipfire.org/)] *.telemetry.mozilla.org (http://telemetry.mozilla.org/). rpz-nxdomain 192.168.200.10@53250 incoming.telemetry.mozilla.org (http://incoming.telemetry.mozilla.org/). A IN
> 11:55:25 unbound: [1741:0] info: rpz: applied [shopping.rpz.ipfire.org (http://shopping.rpz.ipfire.org/)] 1000islandsphotoart.com (http://1000islandsphotoart.com/). rpz-nxdomain 127.0.0.1@42131 1000islandsphotoart.com (http://1000islandsphotoart.com/). A IN
> 11:55:31 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org (http://ads.rpz.ipfire.org/)] ads.mozilla.org (http://ads.mozilla.org/). rpz-nxdomain 192.168.200.10@43432 ads.mozilla.org (http://ads.mozilla.org/). A IN
> 11:55:31 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org (http://ads.rpz.ipfire.org/)] *.telemetry.mozilla.org (http://telemetry.mozilla.org/). rpz-nxdomain 192.168.200.10@48485 incoming.telemetry.mozilla.org (http://incoming.telemetry.mozilla.org/). A IN
>
> The first line was the blocked shopping url after changing the browser to use the IPFire web proxy.
> The second shopping block was when I cam back and tried the shopping url again to see if it was still blocked.
> All the other mozilla related blocks must be the Firefox browser trying to open some things on the web pages that had previously been opened.
>
> Regards,
>
> Adolf.
>
>
> > Regards,
> > Adolf.
> > >
> > > https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=e3c11ae3436b578432df0058eee229f262791254
> > >
> > > Best,
> > > -Michael
> > >
> > > > On 25 Mar 2026, at 13:43, Adolf Belka <adolf.belka@ipfire.org> wrote:
> > > >
> > > > Hi Michael & Jon,
> > > >
> > > > On 25/03/2026 12:58, Adolf Belka wrote:
> > > > > Hi Michael and Jon,
> > > > > On 25/03/2026 10:30, Michael Tremer wrote:
> > > > > > Hello Jon,
> > > > > >
> > > > > > Why would it be necessary to manually change the configuration?
> > > > > >
> > > > > > Can you explain to us what you are thinking?
> > > > > I think the argument is that the define-tag and access-control-tag options should not be multiple entries but single entries with multiple tags space separated in the "" section.
> > > >
> > > > At least the access-control-tag option has to be able to be used multiple times. If you have three categories defined, one with green selected another with blue and the last with orange then there has to be at least three access-control-tags because each of the subnets has a different category assigned to it.
> > > >
> > > > I also found a similar situation outlined in the unbound documentation where they have four access-control-tags defined.
> > > >
> > > > https://unbound.docs.nlnetlabs.nl/en/latest/topics/filtering/tags-views.html#tags
> > > >
> > > > Regards,
> > > >
> > > > Adolf.
> > > >
> > > > > >
> > > > > > > On 24 Mar 2026, at 21:03, Jon Murphy <jon.murphy@ipfire.org> 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"
> > > > > Tried this but it made no difference. I suspect this might be that unbound needs to reload the config file if it has been changed and running unbound reload results in the dnsbl.conf file being updated with what is on the WUI page, so it goes back to the version before it was manually edited.
> > > > > However this made me wonder what would happen if I only had the porn entry selected and not both the porn and gambling.
> > > > > The result, with the browser network option set to No Proxy was that all porn sites were now blocked.
> > > > > I then wondered what would happen if I chose two different categories where the working gambling one was after another category. So I tested out Dating and Gambling.
> > > > > First tested out Dating on its own.
> > > > > It blocked for academysingles.com and loopylove.com
> > > > > Then I enabled both Dating and Gambling. In this case the two dating urls were still blocked but now all the urls that I had previously used, when testing out Gambling and Porn categories together, were no longer blocked.
> > > > > If I disabled the Dating category then the Gambling sites were blocked again.
> > > > > This was also found in the DNS: Unbound logs.
> > > > > So it looks like if there are multiple categories selected then only the urls from the first category get blocked.
> > > > > Regards,
> > > > > Adolf.
> > > > > > >
> > > > > > >
> > > > > > > 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" <michael.tremer@ipfire.org>
> > > > > > > To "Adolf Belka" <adolf.belka@ipfire.org>
> > > > > > > Cc development@lists.ipfire.org; dbl@lists.ipfire.org
> > > > > > > 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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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.
Jon
--
Jon Murphy
murphy.jon@me.com
847-774-3550 (cell)
--
[-- Attachment #2: Type: text/html, Size: 57513 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Feedback on issues with DNSFW in CU201 Testing
2026-04-10 16:46 ` Jon Murphy
@ 2026-04-10 18:25 ` Adolf Belka
2026-04-15 21:24 ` Jon Murphy
1 sibling, 0 replies; 18+ messages in thread
From: Adolf Belka @ 2026-04-10 18:25 UTC (permalink / raw)
To: Jon Murphy, Michael Tremer; +Cc: IPFire: Development-List
Hi Jon & all,
Update on my earlier status after discussion with @Michael.
On 10/04/2026 18:46, Jon Murphy wrote:
> The recent update allows more than one category and seems to work OK (still testing).
>
> Found a new issue; In the Firewall DNS > *Access Control* area > *Custom Source* a CIDR notation of 192.168.74.0/24 works OK, but the subnet mask notation of 192.168.74.0/255.255.255.0 throws this error:
>
> Apr 10 11:25:45 ipfireAPU2 unbound: [1694:6] error: netblock too large: 192.168.74.0/255.255.255.0
> Apr 10 11:25:45 ipfireAPU2 unbound: [1694:6] error: cannot parse netblock: 192.168.74.0/255.255.255.0
> Apr 10 11:26:48 ipfireAPU2 dhcpd: execute_statement argv[0] = /usr/sbin/unbound-dhcp-leases-client
>
>
>
>> On Apr 10, 2026, at 5:09 AM, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>
>> Hi Michael,
>>
>> On 10/04/2026 11:33, Adolf Belka wrote:
>>> Hi Michael,
>>> On 09/04/2026 12:20, Michael Tremer wrote:
>>>> Hello Adolf,
>>>>
>>>> Could you please let me know is this fixes the problem?
>>> It has solved the problem when the browser is set up to use No Proxy or System Proxy and the PC has no proxy set up.
>>> I was able to select Advertising, Dating, Gambling, Pornography, Shopping and Streaming at the same time and trying to access URL's from the lists of those zones caused the access to be blocked. Yaaah. Entries for all these categories found in the unbound log.
>>> Unfortunately when I changed the browser to use IPFire as the web proxy (Conventional mode) by selecting Manual proxy configuration in the browser and specifying the IPFire IP all accesses to the selected categories listed above were allowed to be accessed except for the url for the shopping site. That was still blocked and in the unbound log there was an entry for the shopping site but no entries for any of the other category url's I had just accessed and that were allowed.
>>> So problem is fixed for when the IPFire web proxy is not used by the browser but there is still an issue when working via the proxy.
The reason for the problem when I used the web proxy was that I had selected the green zone ACL in the DNSFW categories I tested except for the Shopping category which was the default setting.
When you select one of the zones ACL, such as Green, this now applies the blocking only to pc's connecting to the internet from the green zone but if you have green selected that excludes the firewall itself. Therefore any browsing without a proxy tries to go straight to the internet and gets blocked. If browsing via the web proxy then the path goes from the pc in the green zone to the web proxy on the firewall (not part of the green zone) and therefore does not get blocked.
The simplest approach is to leave each of the categories in their default acl status. This will ensure that however the traffic tries to access the internet, it will be detected and blocked.
With the default acl status for each of the categories I then had correct blocking of any url from the category lists with or without the web proxy being used.
This confirms that the fix works for correcting the use of multiple categories in DNSFW.
Regards,
Adolf.
>>> I will check some more shopping site url's to see if the shopping site issue is consistent for multiple url's or only that one. I thought it might be that the url no longer exists but it is in the unbound logs getting blocked by the DNSFW. So the question would be why that url gets blocked by the DNSFW via the web proxy when the other Category url's are not shown in the unbound log at all.
>>
>> Further follow-up. After the test above with the web proxy being used where the web sites were allowed to be accessed, I left the browser open with the opened tabs.
>>
>> Although the sites were not blocked by DNSFW via the web proxy, except for the shopping url, DNSFW did then stop some Mozilla telemetry accesses via the ads zone.
>>
>> 11:22:13 unbound: [1741:0] info: rpz: applied [shopping.rpz.ipfire.org <http://shopping.rpz.ipfire.org/>]1000islandsphotoart.com <http://1000islandsphotoart.com/>. rpz-nxdomain 127.0.0.1@421311000islandsphotoart.com <http://1000islandsphotoart.com/>. A IN
>> 11:38:12 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org <http://ads.rpz.ipfire.org/>] *.telemetry.mozilla.org <http://telemetry.mozilla.org/>. rpz-nxdomain 192.168.200.10@45618incoming.telemetry.mozilla.org <http://incoming.telemetry.mozilla.org/>. A IN
>> 11:40:12 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org <http://ads.rpz.ipfire.org/>] *.telemetry.mozilla.org <http://telemetry.mozilla.org/>. rpz-nxdomain 192.168.200.10@47126incoming.telemetry.mozilla.org <http://incoming.telemetry.mozilla.org/>. A IN
>> 11:42:20 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org <http://ads.rpz.ipfire.org/>] *.telemetry.mozilla.org <http://telemetry.mozilla.org/>. rpz-nxdomain 192.168.200.10@50709incoming.telemetry.mozilla.org <http://incoming.telemetry.mozilla.org/>. A IN
>> 11:46:20 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org <http://ads.rpz.ipfire.org/>] *.telemetry.mozilla.org <http://telemetry.mozilla.org/>. rpz-nxdomain 192.168.200.10@46388incoming.telemetry.mozilla.org <http://incoming.telemetry.mozilla.org/>. A IN
>> 11:54:20 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org <http://ads.rpz.ipfire.org/>] *.telemetry.mozilla.org <http://telemetry.mozilla.org/>. rpz-nxdomain 192.168.200.10@53250incoming.telemetry.mozilla.org <http://incoming.telemetry.mozilla.org/>. A IN
>> 11:55:25 unbound: [1741:0] info: rpz: applied [shopping.rpz.ipfire.org <http://shopping.rpz.ipfire.org/>]1000islandsphotoart.com <http://1000islandsphotoart.com/>. rpz-nxdomain 127.0.0.1@421311000islandsphotoart.com <http://1000islandsphotoart.com/>. A IN
>> 11:55:31 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org <http://ads.rpz.ipfire.org/>]ads.mozilla.org <http://ads.mozilla.org/>. rpz-nxdomain 192.168.200.10@43432ads.mozilla.org <http://ads.mozilla.org/>. A IN
>> 11:55:31 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org <http://ads.rpz.ipfire.org/>] *.telemetry.mozilla.org <http://telemetry.mozilla.org/>. rpz-nxdomain 192.168.200.10@48485incoming.telemetry.mozilla.org <http://incoming.telemetry.mozilla.org/>. A IN
>>
>> The first line was the blocked shopping url after changing the browser to use the IPFire web proxy.
>> The second shopping block was when I cam back and tried the shopping url again to see if it was still blocked.
>> All the other mozilla related blocks must be the Firefox browser trying to open some things on the web pages that had previously been opened.
>>
>> Regards,
>>
>> Adolf.
>>
>>
>>> Regards,
>>> Adolf.
>>>>
>>>> https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=e3c11ae3436b578432df0058eee229f262791254
>>>>
>>>> Best,
>>>> -Michael
>>>>
>>>>> On 25 Mar 2026, at 13:43, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>>>>
>>>>> Hi Michael & Jon,
>>>>>
>>>>> On 25/03/2026 12:58, Adolf Belka wrote:
>>>>>> Hi Michael and Jon,
>>>>>> On 25/03/2026 10:30, Michael Tremer wrote:
>>>>>>> Hello Jon,
>>>>>>>
>>>>>>> Why would it be necessary to manually change the configuration?
>>>>>>>
>>>>>>> Can you explain to us what you are thinking?
>>>>>> I think the argument is that the define-tag and access-control-tag options should not be multiple entries but single entries with multiple tags space separated in the "" section.
>>>>>
>>>>> At least the access-control-tag option has to be able to be used multiple times. If you have three categories defined, one with green selected another with blue and the last with orange then there has to be at least three access-control-tags because each of the subnets has a different category assigned to it.
>>>>>
>>>>> I also found a similar situation outlined in the unbound documentation where they have four access-control-tags defined.
>>>>>
>>>>> https://unbound.docs.nlnetlabs.nl/en/latest/topics/filtering/tags-views.html#tags
>>>>>
>>>>> Regards,
>>>>>
>>>>> Adolf.
>>>>>
>>>>>>>
>>>>>>>> On 24 Mar 2026, at 21:03, Jon Murphy <jon.murphy@ipfire.org> 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"
>>>>>> Tried this but it made no difference. I suspect this might be that unbound needs to reload the config file if it has been changed and running unbound reload results in the dnsbl.conf file being updated with what is on the WUI page, so it goes back to the version before it was manually edited.
>>>>>> However this made me wonder what would happen if I only had the porn entry selected and not both the porn and gambling.
>>>>>> The result, with the browser network option set to No Proxy was that all porn sites were now blocked.
>>>>>> I then wondered what would happen if I chose two different categories where the working gambling one was after another category. So I tested out Dating and Gambling.
>>>>>> First tested out Dating on its own.
>>>>>> It blocked for academysingles.com and loopylove.com
>>>>>> Then I enabled both Dating and Gambling. In this case the two dating urls were still blocked but now all the urls that I had previously used, when testing out Gambling and Porn categories together, were no longer blocked.
>>>>>> If I disabled the Dating category then the Gambling sites were blocked again.
>>>>>> This was also found in the DNS: Unbound logs.
>>>>>> So it looks like if there are multiple categories selected then only the urls from the first category get blocked.
>>>>>> Regards,
>>>>>> Adolf.
>>>>>>>>
>>>>>>>>
>>>>>>>> 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" <michael.tremer@ipfire.org>
>>>>>>>> To "Adolf Belka" <adolf.belka@ipfire.org>
>>>>>>>> Cc development@lists.ipfire.org; dbl@lists.ipfire.org
>>>>>>>> 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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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.
>
> Jon
>
>
> --
> Jon Murphy
> murphy.jon@me.com
> 847-774-3550 (cell)
> --
>
>
>
>
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Feedback on issues with DNSFW in CU201 Testing
2026-04-10 16:46 ` Jon Murphy
2026-04-10 18:25 ` Adolf Belka
@ 2026-04-15 21:24 ` Jon Murphy
2026-04-20 11:51 ` Michael Tremer
1 sibling, 1 reply; 18+ messages in thread
From: Jon Murphy @ 2026-04-15 21:24 UTC (permalink / raw)
To: IPFire: Development-List; +Cc: Adolf Belka, Michael Tremer
[-- Attachment #1: Type: text/plain, Size: 19450 bytes --]
One more new issue:
If a domain is added to a custom block similar to `*.apple.com (http://apple.com)` then an additional `*.` is added. So this:
> *.news-events.apple.com
> news-events.apple.com
>
>
> *.zip
>
>
becomes this in the custom.zone file:
> $ORIGIN _custom.rpz.local.
> news-events.apple.com CNAME .
>
>
> *.news-events.apple.com CNAME .
>
>
> *.news-events.apple.com CNAME .
>
>
> *.*.news-events.apple.com CNAME .
>
>
> *.zip CNAME .
>
>
> *.*.zip CNAME .
>
>
So there should be a check for a beginning `*.` and then not add an additional asterisks.
—
Jon
> On Friday, Apr 10, 2026 at 11:46 AM, Jon Murphy <jon.murphy@ipfire.org (mailto:jon.murphy@ipfire.org)> wrote:
> The recent update allows more than one category and seems to work OK (still testing).
>
> Found a new issue; In the Firewall DNS > Access Control area > Custom Source a CIDR notation of 192.168.74.0/24 works OK, but the subnet mask notation of 192.168.74.0/255.255.255.0 throws this error:
>
> Apr 10 11:25:45 ipfireAPU2 unbound: [1694:6] error: netblock too large: 192.168.74.0/255.255.255.0
> Apr 10 11:25:45 ipfireAPU2 unbound: [1694:6] error: cannot parse netblock: 192.168.74.0/255.255.255.0
> Apr 10 11:26:48 ipfireAPU2 dhcpd: execute_statement argv[0] = /usr/sbin/unbound-dhcp-leases-client
>
>
>
> > On Apr 10, 2026, at 5:09 AM, Adolf Belka <adolf.belka@ipfire.org> wrote:
> > Hi Michael,
> >
> > On 10/04/2026 11:33, Adolf Belka wrote:
> > > Hi Michael,
> > > On 09/04/2026 12:20, Michael Tremer wrote:
> > > > Hello Adolf,
> > > >
> > > > Could you please let me know is this fixes the problem?
> > > It has solved the problem when the browser is set up to use No Proxy or System Proxy and the PC has no proxy set up.
> > > I was able to select Advertising, Dating, Gambling, Pornography, Shopping and Streaming at the same time and trying to access URL's from the lists of those zones caused the access to be blocked. Yaaah. Entries for all these categories found in the unbound log.
> > > Unfortunately when I changed the browser to use IPFire as the web proxy (Conventional mode) by selecting Manual proxy configuration in the browser and specifying the IPFire IP all accesses to the selected categories listed above were allowed to be accessed except for the url for the shopping site. That was still blocked and in the unbound log there was an entry for the shopping site but no entries for any of the other category url's I had just accessed and that were allowed.
> > > So problem is fixed for when the IPFire web proxy is not used by the browser but there is still an issue when working via the proxy.
> > > I will check some more shopping site url's to see if the shopping site issue is consistent for multiple url's or only that one. I thought it might be that the url no longer exists but it is in the unbound logs getting blocked by the DNSFW. So the question would be why that url gets blocked by the DNSFW via the web proxy when the other Category url's are not shown in the unbound log at all.
> >
> > Further follow-up. After the test above with the web proxy being used where the web sites were allowed to be accessed, I left the browser open with the opened tabs.
> >
> > Although the sites were not blocked by DNSFW via the web proxy, except for the shopping url, DNSFW did then stop some Mozilla telemetry accesses via the ads zone.
> >
> > 11:22:13 unbound: [1741:0] info: rpz: applied [shopping.rpz.ipfire.org (http://shopping.rpz.ipfire.org/)] 1000islandsphotoart.com (http://1000islandsphotoart.com/). rpz-nxdomain 127.0.0.1@42131 1000islandsphotoart.com (http://1000islandsphotoart.com/). A IN
> > 11:38:12 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org (http://ads.rpz.ipfire.org/)] *.telemetry.mozilla.org (http://telemetry.mozilla.org/). rpz-nxdomain 192.168.200.10@45618 incoming.telemetry.mozilla.org (http://incoming.telemetry.mozilla.org/). A IN
> > 11:40:12 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org (http://ads.rpz.ipfire.org/)] *.telemetry.mozilla.org (http://telemetry.mozilla.org/). rpz-nxdomain 192.168.200.10@47126 incoming.telemetry.mozilla.org (http://incoming.telemetry.mozilla.org/). A IN
> > 11:42:20 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org (http://ads.rpz.ipfire.org/)] *.telemetry.mozilla.org (http://telemetry.mozilla.org/). rpz-nxdomain 192.168.200.10@50709 incoming.telemetry.mozilla.org (http://incoming.telemetry.mozilla.org/). A IN
> > 11:46:20 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org (http://ads.rpz.ipfire.org/)] *.telemetry.mozilla.org (http://telemetry.mozilla.org/). rpz-nxdomain 192.168.200.10@46388 incoming.telemetry.mozilla.org (http://incoming.telemetry.mozilla.org/). A IN
> > 11:54:20 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org (http://ads.rpz.ipfire.org/)] *.telemetry.mozilla.org (http://telemetry.mozilla.org/). rpz-nxdomain 192.168.200.10@53250 incoming.telemetry.mozilla.org (http://incoming.telemetry.mozilla.org/). A IN
> > 11:55:25 unbound: [1741:0] info: rpz: applied [shopping.rpz.ipfire.org (http://shopping.rpz.ipfire.org/)] 1000islandsphotoart.com (http://1000islandsphotoart.com/). rpz-nxdomain 127.0.0.1@42131 1000islandsphotoart.com (http://1000islandsphotoart.com/). A IN
> > 11:55:31 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org (http://ads.rpz.ipfire.org/)] ads.mozilla.org (http://ads.mozilla.org/). rpz-nxdomain 192.168.200.10@43432 ads.mozilla.org (http://ads.mozilla.org/). A IN
> > 11:55:31 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org (http://ads.rpz.ipfire.org/)] *.telemetry.mozilla.org (http://telemetry.mozilla.org/). rpz-nxdomain 192.168.200.10@48485 incoming.telemetry.mozilla.org (http://incoming.telemetry.mozilla.org/). A IN
> >
> > The first line was the blocked shopping url after changing the browser to use the IPFire web proxy.
> > The second shopping block was when I cam back and tried the shopping url again to see if it was still blocked.
> > All the other mozilla related blocks must be the Firefox browser trying to open some things on the web pages that had previously been opened.
> >
> > Regards,
> >
> > Adolf.
> >
> >
> > > Regards,
> > > Adolf.
> > > >
> > > > https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=e3c11ae3436b578432df0058eee229f262791254
> > > >
> > > > Best,
> > > > -Michael
> > > >
> > > > > On 25 Mar 2026, at 13:43, Adolf Belka <adolf.belka@ipfire.org> wrote:
> > > > >
> > > > > Hi Michael & Jon,
> > > > >
> > > > > On 25/03/2026 12:58, Adolf Belka wrote:
> > > > > > Hi Michael and Jon,
> > > > > > On 25/03/2026 10:30, Michael Tremer wrote:
> > > > > > > Hello Jon,
> > > > > > >
> > > > > > > Why would it be necessary to manually change the configuration?
> > > > > > >
> > > > > > > Can you explain to us what you are thinking?
> > > > > > I think the argument is that the define-tag and access-control-tag options should not be multiple entries but single entries with multiple tags space separated in the "" section.
> > > > >
> > > > > At least the access-control-tag option has to be able to be used multiple times. If you have three categories defined, one with green selected another with blue and the last with orange then there has to be at least three access-control-tags because each of the subnets has a different category assigned to it.
> > > > >
> > > > > I also found a similar situation outlined in the unbound documentation where they have four access-control-tags defined.
> > > > >
> > > > > https://unbound.docs.nlnetlabs.nl/en/latest/topics/filtering/tags-views.html#tags
> > > > >
> > > > > Regards,
> > > > >
> > > > > Adolf.
> > > > >
> > > > > > >
> > > > > > > > On 24 Mar 2026, at 21:03, Jon Murphy <jon.murphy@ipfire.org> 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"
> > > > > > Tried this but it made no difference. I suspect this might be that unbound needs to reload the config file if it has been changed and running unbound reload results in the dnsbl.conf file being updated with what is on the WUI page, so it goes back to the version before it was manually edited.
> > > > > > However this made me wonder what would happen if I only had the porn entry selected and not both the porn and gambling.
> > > > > > The result, with the browser network option set to No Proxy was that all porn sites were now blocked.
> > > > > > I then wondered what would happen if I chose two different categories where the working gambling one was after another category. So I tested out Dating and Gambling.
> > > > > > First tested out Dating on its own.
> > > > > > It blocked for academysingles.com and loopylove.com
> > > > > > Then I enabled both Dating and Gambling. In this case the two dating urls were still blocked but now all the urls that I had previously used, when testing out Gambling and Porn categories together, were no longer blocked.
> > > > > > If I disabled the Dating category then the Gambling sites were blocked again.
> > > > > > This was also found in the DNS: Unbound logs.
> > > > > > So it looks like if there are multiple categories selected then only the urls from the first category get blocked.
> > > > > > Regards,
> > > > > > Adolf.
> > > > > > > >
> > > > > > > >
> > > > > > > > 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" <michael.tremer@ipfire.org>
> > > > > > > > To "Adolf Belka" <adolf.belka@ipfire.org>
> > > > > > > > Cc development@lists.ipfire.org; dbl@lists.ipfire.org
> > > > > > > > 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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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.
> Jon
>
>
> --
> Jon Murphy
> murphy.jon@me.com
> 847-774-3550 (cell)
> --
>
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 60082 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Feedback on issues with DNSFW in CU201 Testing
2026-04-15 21:24 ` Jon Murphy
@ 2026-04-20 11:51 ` Michael Tremer
0 siblings, 0 replies; 18+ messages in thread
From: Michael Tremer @ 2026-04-20 11:51 UTC (permalink / raw)
To: Jon Murphy; +Cc: IPFire: Development-List, Adolf Belka
Hello Jon,
I pushed a fix for this problem:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=a7f578e949a385e79f1b39f5ac19d7fea32f4bed
The fix however is to check if a user has entered a valid domain name. “*.domain.tld” is not a valid FQDN and therefore won’t be saveable.
This has been ported to Core Update 201 and I hope that we can finally bring the testing stage of this release to an end.
-Michael
> On 15 Apr 2026, at 22:24, Jon Murphy <jon.murphy@ipfire.org> wrote:
>
> One more new issue:
>
> If a domain is added to a custom block similar to `*.apple.com` then an additional `*.` is added. So this:
>
> *.news-events.apple.com
> news-events.apple.com
> *.zip
>
> becomes this in the custom.zone file:
>
> $ORIGIN _custom.rpz.local.
> news-events.apple.com CNAME .
> *.news-events.apple.com CNAME .
> *.news-events.apple.com CNAME .
> *.*.news-events.apple.com CNAME .
> *.zip CNAME .
> *.*.zip CNAME .
>
> So there should be a check for a beginning `*.` and then not add an additional asterisks.
>
>
> —
> Jon
>
>
> On Friday, Apr 10, 2026 at 11:46 AM, Jon Murphy <jon.murphy@ipfire.org> wrote:
> The recent update allows more than one category and seems to work OK (still testing).
>
> Found a new issue; In the Firewall DNS > Access Control area > Custom Source a CIDR notation of 192.168.74.0/24 works OK, but the subnet mask notation of 192.168.74.0/255.255.255.0 throws this error:
>
> Apr 10 11:25:45 ipfireAPU2 unbound: [1694:6] error: netblock too large: 192.168.74.0/255.255.255.0
> Apr 10 11:25:45 ipfireAPU2 unbound: [1694:6] error: cannot parse netblock: 192.168.74.0/255.255.255.0
> Apr 10 11:26:48 ipfireAPU2 dhcpd: execute_statement argv[0] = /usr/sbin/unbound-dhcp-leases-client
>
>
>
>> On Apr 10, 2026, at 5:09 AM, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>
>> Hi Michael,
>>
>> On 10/04/2026 11:33, Adolf Belka wrote:
>>> Hi Michael,
>>> On 09/04/2026 12:20, Michael Tremer wrote:
>>>> Hello Adolf,
>>>>
>>>> Could you please let me know is this fixes the problem?
>>> It has solved the problem when the browser is set up to use No Proxy or System Proxy and the PC has no proxy set up.
>>> I was able to select Advertising, Dating, Gambling, Pornography, Shopping and Streaming at the same time and trying to access URL's from the lists of those zones caused the access to be blocked. Yaaah. Entries for all these categories found in the unbound log.
>>> Unfortunately when I changed the browser to use IPFire as the web proxy (Conventional mode) by selecting Manual proxy configuration in the browser and specifying the IPFire IP all accesses to the selected categories listed above were allowed to be accessed except for the url for the shopping site. That was still blocked and in the unbound log there was an entry for the shopping site but no entries for any of the other category url's I had just accessed and that were allowed.
>>> So problem is fixed for when the IPFire web proxy is not used by the browser but there is still an issue when working via the proxy.
>>> I will check some more shopping site url's to see if the shopping site issue is consistent for multiple url's or only that one. I thought it might be that the url no longer exists but it is in the unbound logs getting blocked by the DNSFW. So the question would be why that url gets blocked by the DNSFW via the web proxy when the other Category url's are not shown in the unbound log at all.
>>
>> Further follow-up. After the test above with the web proxy being used where the web sites were allowed to be accessed, I left the browser open with the opened tabs.
>>
>> Although the sites were not blocked by DNSFW via the web proxy, except for the shopping url, DNSFW did then stop some Mozilla telemetry accesses via the ads zone.
>>
>> 11:22:13 unbound: [1741:0] info: rpz: applied [shopping.rpz.ipfire.org] 1000islandsphotoart.com. rpz-nxdomain 127.0.0.1@42131 1000islandsphotoart.com. A IN
>> 11:38:12 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org] *.telemetry.mozilla.org. rpz-nxdomain 192.168.200.10@45618 incoming.telemetry.mozilla.org. A IN
>> 11:40:12 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org] *.telemetry.mozilla.org. rpz-nxdomain 192.168.200.10@47126 incoming.telemetry.mozilla.org. A IN
>> 11:42:20 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org] *.telemetry.mozilla.org. rpz-nxdomain 192.168.200.10@50709 incoming.telemetry.mozilla.org. A IN
>> 11:46:20 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org] *.telemetry.mozilla.org. rpz-nxdomain 192.168.200.10@46388 incoming.telemetry.mozilla.org. A IN
>> 11:54:20 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org] *.telemetry.mozilla.org. rpz-nxdomain 192.168.200.10@53250 incoming.telemetry.mozilla.org. A IN
>> 11:55:25 unbound: [1741:0] info: rpz: applied [shopping.rpz.ipfire.org] 1000islandsphotoart.com. rpz-nxdomain 127.0.0.1@42131 1000islandsphotoart.com. A IN
>> 11:55:31 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org] ads.mozilla.org. rpz-nxdomain 192.168.200.10@43432 ads.mozilla.org. A IN
>> 11:55:31 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org] *.telemetry.mozilla.org. rpz-nxdomain 192.168.200.10@48485 incoming.telemetry.mozilla.org. A IN
>>
>> The first line was the blocked shopping url after changing the browser to use the IPFire web proxy.
>> The second shopping block was when I cam back and tried the shopping url again to see if it was still blocked.
>> All the other mozilla related blocks must be the Firefox browser trying to open some things on the web pages that had previously been opened.
>>
>> Regards,
>>
>> Adolf.
>>
>>
>>> Regards,
>>> Adolf.
>>>>
>>>> https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=e3c11ae3436b578432df0058eee229f262791254
>>>>
>>>> Best,
>>>> -Michael
>>>>
>>>>> On 25 Mar 2026, at 13:43, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>>>>
>>>>> Hi Michael & Jon,
>>>>>
>>>>> On 25/03/2026 12:58, Adolf Belka wrote:
>>>>>> Hi Michael and Jon,
>>>>>> On 25/03/2026 10:30, Michael Tremer wrote:
>>>>>>> Hello Jon,
>>>>>>>
>>>>>>> Why would it be necessary to manually change the configuration?
>>>>>>>
>>>>>>> Can you explain to us what you are thinking?
>>>>>> I think the argument is that the define-tag and access-control-tag options should not be multiple entries but single entries with multiple tags space separated in the "" section.
>>>>>
>>>>> At least the access-control-tag option has to be able to be used multiple times. If you have three categories defined, one with green selected another with blue and the last with orange then there has to be at least three access-control-tags because each of the subnets has a different category assigned to it.
>>>>>
>>>>> I also found a similar situation outlined in the unbound documentation where they have four access-control-tags defined.
>>>>>
>>>>> https://unbound.docs.nlnetlabs.nl/en/latest/topics/filtering/tags-views.html#tags
>>>>>
>>>>> Regards,
>>>>>
>>>>> Adolf.
>>>>>
>>>>>>>
>>>>>>>> On 24 Mar 2026, at 21:03, Jon Murphy <jon.murphy@ipfire.org> 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"
>>>>>> Tried this but it made no difference. I suspect this might be that unbound needs to reload the config file if it has been changed and running unbound reload results in the dnsbl.conf file being updated with what is on the WUI page, so it goes back to the version before it was manually edited.
>>>>>> However this made me wonder what would happen if I only had the porn entry selected and not both the porn and gambling.
>>>>>> The result, with the browser network option set to No Proxy was that all porn sites were now blocked.
>>>>>> I then wondered what would happen if I chose two different categories where the working gambling one was after another category. So I tested out Dating and Gambling.
>>>>>> First tested out Dating on its own.
>>>>>> It blocked for academysingles.com and loopylove.com
>>>>>> Then I enabled both Dating and Gambling. In this case the two dating urls were still blocked but now all the urls that I had previously used, when testing out Gambling and Porn categories together, were no longer blocked.
>>>>>> If I disabled the Dating category then the Gambling sites were blocked again.
>>>>>> This was also found in the DNS: Unbound logs.
>>>>>> So it looks like if there are multiple categories selected then only the urls from the first category get blocked.
>>>>>> Regards,
>>>>>> Adolf.
>>>>>>>>
>>>>>>>>
>>>>>>>> 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" <michael.tremer@ipfire.org>
>>>>>>>> To "Adolf Belka" <adolf.belka@ipfire.org>
>>>>>>>> Cc development@lists.ipfire.org; dbl@lists.ipfire.org
>>>>>>>> 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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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.
>
>
> Jon
>
>
> --
> Jon Murphy
> murphy.jon@me.com
> 847-774-3550 (cell)
> --
>
>
>
>
>
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2026-04-20 11:51 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-03-20 12:30 Feedback on issues with DNSFW in CU201 Testing Adolf Belka
2026-03-20 15:56 ` Michael Tremer
2026-03-20 16:59 ` Adolf Belka
2026-03-23 11:10 ` Michael Tremer
2026-03-23 12:22 ` Adolf Belka
2026-03-23 14:41 ` Michael Tremer
2026-03-24 21:03 ` Re[2]: " Jon Murphy
2026-03-25 9:30 ` Michael Tremer
2026-03-25 11:58 ` Adolf Belka
2026-03-25 13:43 ` Adolf Belka
2026-04-09 10:20 ` Michael Tremer
2026-04-10 9:33 ` Adolf Belka
2026-04-10 10:09 ` Adolf Belka
2026-04-10 16:46 ` Jon Murphy
2026-04-10 18:25 ` Adolf Belka
2026-04-15 21:24 ` Jon Murphy
2026-04-20 11:51 ` Michael Tremer
2026-03-25 15:17 ` Jon Murphy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox