Hello Adolf,

What is the output of unbound-control list_auth_zones?

-Michael

> On 20 Mar 2026, at 16:59, Adolf Belka <[email protected]> wrote:
> 
> Hi Michael,
> 
> On 20/03/2026 16:56, Michael Tremer wrote:
>> Hello Adolf,
>> I am copying the DBL list, too.
> 
> Good idea. I was just thinking of it being related to Testing issue.
>> So this is obviously not normal, but we can debug this step by step:
>> First of all, we should check if Unbound was able to successfully fetch the 
>> DNS zones. Gambling has clearly been downloaded, but it seems that the Porn 
>> list might not. You can check in /var/cache/unbound if there is the zone 
>> file. If yes, then you can try to resolve a couple of things on the console 
>> and check if they are being blocked:
> 
> I should have already mentioned this but forgot. It was one of the first 
> things I checked and I have just re-confirmed now. The porn zone file is 
> present. It was updated at 11:40 CET and the Gambling zone was updated at 
> 12:53 CET.
> 
> I also checked that the zone file contained the url's being used and it did 
> and does.
> 
>> # dig @localhost some.porn.website.com <http://some.porn.website.com/>
>> You should see NXDOMAIN if the domain exists and has been blocked and you 
>> should see the log entries just like gambling.
> 
> Got
> 
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 54293
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
> 
> So NXDOMAIN is in the answer but there was nothing additional in the unbound 
> log. The last entry in it was from 12:58:50 when I did the tests with the 
> gambling sites and if there was an entry it should have a timestamp for 
> around 17:45
> 
>> This rules out anything that is going wrong between the browser and Unbound.
>> In case of the URL filter, it simply seems that squidguard is not seeing the 
>> requests. You might as well try something like:
> 
> With the URL Filter enabled and DNSFW disabled then the URL Filter blocks and 
> logs both the Gambling and Porn site accesses. Sorry if that came across as 
> differently in my mail. The URL Filter works fine for me with both CU200 and 
> CU201 Testing.
> 
>> # http_proxy=http://1.2.3.4:800 <http://1.2.3.4:800/> 
>> https_proxy=http://1.2.3.4:800 <http://1.2.3.4:800/> wget -d 
>> http://some.porn.website.com <http://some.porn.website.com/>
>> The squidguard.log should also contain some interesting information if 
>> something didn’t go as planned.
>> -Michael
>>> On 20 Mar 2026, at 12:30, Adolf Belka <[email protected]> wrote:
>>> 
>>> Hi All,
>>> 
>>> I am having issues with getting DNSFW to work properly, it fails in many 
>>> conditions to block things from the list.
>>> 
>>> The dbl list works fine for me in the URL Filter for both CU200 and CU201 
>>> Testing.
>>> 
>>> For my testing I created a new install of CU201 Testing and just went 
>>> straight to DNSFW and enabled the Gambling and Pornography categories and 
>>> Saved.
>>> 
>>> Then selected the Green network for both categories using the pencil edit 
>>> option.
>>> 
>>> In this setup I had no Web Proxy enabled.
>>> 
>>> I then cleared the browser cache and set the Browser to No Proxy.
>>> 
>>> I then tested out nl.onecasino.com and www.xnxx.com in Firefox and in 
>>> Netsurf
>>> 
>>> The gambling site was blocked and gave the message
>>> 
>>> Unable to connect
>>> Firefox can’t establish a connection to the server at nl.onecasino.com.
>>> 
>>> For the porn site it was not blocked but opened up.
>>> I tried with two other gambling and porn sites. All three gambling sites 
>>> were blocked. All three porn sites were allowed through.
>>> 
>>> In the DND: Unbound System Logs I found
>>> 
>>> 12:52:26 unbound: [1820:0]  info: rpz: applied [gambling.rpz.ipfire.org] 
>>> *.postcodeloterij.nl. rpz-nxdomain 192.168.200.11@44247 
>>> www.postcodeloterij.nl. A IN
>>> 12:52:26 unbound: [1820:0]  info: rpz: applied [gambling.rpz.ipfire.org] 
>>> *.postcodeloterij.nl. rpz-nxdomain 192.168.200.11@44356 
>>> www.postcodeloterij.nl. HTTPS IN
>>> 12:51:32 unbound: [1820:0]  info: rpz: applied [gambling.rpz.ipfire.org] 
>>> *.onecasino.com. rpz-nxdomain 192.168.200.11@55955 nl.onecasino.com. A IN
>>> 12:51:32 unbound: [1820:0]  info: rpz: applied [gambling.rpz.ipfire.org] 
>>> *.onecasino.com. rpz-nxdomain 192.168.200.11@49136 nl.onecasino.com. HTTPS 
>>> IN
>>> 12:50:41 unbound: [1820:0]  info: rpz: applied [gambling.rpz.ipfire.org] 
>>> *.hollandcasino.nl. rpz-nxdomain 192.168.200.11@47229 
>>> welkom.hollandcasino.nl. A IN
>>> 12:50:41 unbound: [1820:0]  info: rpz: applied [gambling.rpz.ipfire.org] 
>>> *.hollandcasino.nl. rpz-nxdomain 192.168.200.11@43346 
>>> welkom.hollandcasino.nl. HTTPS IN
>>> 
>>> So the blocked gambling sites were in the logs but not any of the 
>>> pornography sites  had tested.
>>> 
>>> Then tried the browser with the Network Settings set to Use system proxy 
>>> settings and the same result occurred.
>>> 
>>> I then turned on the Web Proxy with conventional connection on port 800. 
>>> Saved and restarted and then Cleared the web proxy cache.
>>> Then I cleared the browser cache and set the Network Settings to Manual 
>>> proxy configuration with the IP of my IPFire system being tested.
>>> 
>>> I then tested the same three gambling URL's and Porn URL's.
>>> All of the sites were opened up.
>>> In the DNS: Unbound system log there were no new entries.
>>> In the Proxy Logs there were entries for the gambling and porn sites.
>>> 
>>> I have also tested the browser out using the web proxy with the Automatic 
>>> proxy configuration URL accessing the wpad file via dhcp and that also had 
>>> the same results as using the Manual proxy configuration option.
>>> 
>>> I have repeated a lot of my tests multiple times, also with repeated new 
>>> installs and for me, as long as I ensured I had cleared the web proxy and 
>>> browser caches, always came up with the same results as I have described 
>>> above.
>>> 
>>> It would be good to know if any of you also experience the same effect or 
>>> if it works without problems for yourselves.
>>> 
>>> Regards,
>>> 
>>> Adolf.
>>> 
>>> 
> 
> 


Reply via email to