From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [IPv6:::1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4fgrBk6WnHz339t for ; Wed, 25 Mar 2026 15:18:06 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [IPv6:2001:678:b28::25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (secp384r1 raw public key) server-digest SHA384 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail01.haj.ipfire.org", Issuer "R12" (not verified)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4fgrBg4R4tz2xHh for ; Wed, 25 Mar 2026 15:18:03 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4fgrBd4Cn1z3Rv for ; Wed, 25 Mar 2026 15:18:01 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1774451881; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/t+R2tCl2xbkKz/zwTA2+Iaq1uA8iaZOi0jeJLleD50=; b=jawX8J2jS0DoMBc5tz4j5UyC+53kfKV4oG66A2rdXpB78Hz6zzpdvB0VNffsMSyrBbnhrZ FAC49GKdGLJXgXCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1774451881; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/t+R2tCl2xbkKz/zwTA2+Iaq1uA8iaZOi0jeJLleD50=; b=n/lDe8dkDdX42GCvONaEDs9MGtot8wen6GZtJb4cJs84u8la4uGwGMgUTiFqd5/DFXRvDK m9kcwFWrwx1B3eEO5q6hlS0vIjgJ+P2MUPSQZmqhpN6G2NFSdTUEfFSuXH1WFNw5THTb1A nz3dfUASfTcFi4vaMSuu86hhM4bb4CwDClMIbCXO4XYf116ae2mdw+Oy01s2c0wzSrVc8p X01LLGahTkXtA5c9W4NkS+Gs/Z0dhTq2hpGK9YELAoruBeRu8awSkj/S4aqIwudtGLt+WJ Yes5qzYYkX247Fjiol9suNrfq6l2jS8c6P/fh3l4TJe7mxzjxwiNaSy43Nx2Uw== From: "Jon Murphy" To: "IPFire: Development-List" Subject: Re: Feedback on issues with DNSFW in CU201 Testing Date: Wed, 25 Mar 2026 15:17:54 +0000 Message-Id: In-Reply-To: References: <9786EB04-D529-48D2-9BB6-AEF37B246714@ipfire.org> <99E8DC3B-30D7-43D5-AEBE-34B01E2953A0@ipfire.org> <12445407-95ac-457d-b0fe-0f74a3d2eb21@ipfire.org> <8A994F8C-FB85-487E-9799-98CED1881E1F@ipfire.org> Reply-To: "Jon Murphy" Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable I think the init.d unbound code may be incorrect as it creates the=20 dnsbl.conf file and I did a manual change of the dnsbl.conf file as a=20 test. After I made the manual changes, RPZ started to work with=20 multiple categories (e.g. ads, dating, doh) Each `local network=3D"${COLOR_NETADDRESS}/$"` probably needs=20 their own access-control-tag. =3D=3D=3D # this section was added at the end of the dnsbl.conf file (it needs to=20 be after the `define-tag:` lines) server: access-control-tag: 192.168.74.0/24 "ads.rpz.ipfire.org=20 dating.rpz.ipfire.org doh.rpz.ipfire.org gambling.rpz.ipfire.org=20 games.rpz.ipfire.org" # green access-control-tag: 192.168.75.0/24 "ads.rpz.ipfire.org=20 dating.rpz.ipfire.org doh.rpz.ipfire.org gambling.rpz.ipfire.org=20 games.rpz.ipfire.org" # blue =3D=3D=3D This will allow the RPZ to work on more than one (or maybe two)=20 categories. ------ Original Message ------ >From "Michael Tremer" To "Jon Murphy" Cc "Adolf Belka" ; "IPFire: Development-List"=20 ; dbl@lists.ipfire.org Date 3/25/2026 4:30:32=E2=80=AFAM 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 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.i= pfire.org" >> >> >> Separate "access-control-tag" don=E2=80=99t seem to work. > >What is this supposed to mean? > >-Michael > >> >> The above changes allows RPZ to work as expected. >> >> >> >> ------ Original Message ------ >> From "Michael Tremer" >> To "Adolf Belka" >> Cc development@lists.ipfire.org; dbl@lists.ipfire.org >> Date 3/23/2026 9:41:07=E2=80=AFAM >> 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=E2=80=99t quite know what could be going wrong now. >>> >>> -Michael >>> >>>> On 23 Mar 2026, at 12:22, Adolf Belka 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 202= 6-03-23T13:04:47 >>>> gambling.rpz.ipfire.org serial 1773997205 since 17742674= 87 2026-03-23T13:04:47 >>>> >>>> Regards, >>>> >>>> Adolf. >>>> >>>>> -Michael >>>>>> On 20 Mar 2026, at 16:59, Adolf Belka wrot= e: >>>>>> >>>>>> 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 ste= p: >>>>>>> First of all, we should check if Unbound was able to successfully= fetch the DNS zones. Gambling has clearly been downloaded, but it seems tha= t 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 th= e 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 an= d it did and does. >>>>>> >>>>>>> # dig @localhost 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, ADDITIONA= L: 1 >>>>>> >>>>>> So NXDOMAIN is in the answer but there was nothing additional in th= e 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 timestam= p for around 17:45 >>>>>> >>>>>>> This rules out anything that is going wrong between the browser an= d 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 cam= e across as differently in my mail. The URL Filter works fine for me with b= oth CU200 and CU201 Testing. >>>>>> >>>>>>> # http_proxy=3Dhttp://1.2.3.4:800 https_prox= y=3Dhttp://1.2.3.4:800 wget -d http://some.porn.websi= te.com >>>>>>> The squidguard.log should also contain some interesting informatio= n if something didn=E2=80=99t go as planned. >>>>>>> -Michael >>>>>>>> On 20 Mar 2026, at 12:30, Adolf Belka wr= ote: >>>>>>>> >>>>>>>> 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 a= nd 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 pen= cil 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 an= d in Netsurf >>>>>>>> >>>>>>>> The gambling site was blocked and gave the message >>>>>>>> >>>>>>>> Unable to connect >>>>>>>> Firefox can=E2=80=99t 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 gamblin= g 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.ipfi= re.org] *.postcodeloterij.nl. rpz-nxdomain 192.168.200.11@44247 www.postcod= eloterij.nl. A IN >>>>>>>> 12:52:26 unbound: [1820:0] info: rpz: applied [gambling.rpz.ipfi= re.org] *.postcodeloterij.nl. rpz-nxdomain 192.168.200.11@44356 www.postcod= eloterij.nl. HTTPS IN >>>>>>>> 12:51:32 unbound: [1820:0] info: rpz: applied [gambling.rpz.ipfi= re.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.ipfi= re.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.ipfi= re.org] *.hollandcasino.nl. rpz-nxdomain 192.168.200.11@47229 welkom.hollan= dcasino.nl. A IN >>>>>>>> 12:50:41 unbound: [1820:0] info: rpz: applied [gambling.rpz.ipfi= re.org] *.hollandcasino.nl. rpz-nxdomain 192.168.200.11@43346 welkom.hollan= dcasino.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 syste= m proxy settings and the same result occurred. >>>>>>>> >>>>>>>> I then turned on the Web Proxy with conventional connection on po= rt 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 si= tes. >>>>>>>> >>>>>>>> I have also tested the browser out using the web proxy with the A= utomatic 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 repea= ted new installs and for me, as long as I ensured I had cleared the web pro= xy and browser caches, always came up with the same results as I have descr= ibed above. >>>>>>>> >>>>>>>> It would be good to know if any of you also experience the same e= ffect or if it works without problems for yourselves. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Adolf. >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >>> >>> > >