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