thanks I’ll try to check the configuration
even if I don’t think it’s a memory problem, with htop it only increases the CPU usage from 10-15% to 100%
Hi Jon, The wiki does not say where one downloads the RPZ code from? e.g. “rpz-beta-0.1.nn-nn.ipfire.tar” Pat
Since it is in beta mode it is better to come from the Community. Eventually it should come from the official channels via Pakfire.
Here is the current version:
2 Likes
I added a link into the wiki and will try to hold it uptodate.
4 Likes
The functionality to add devices able to bypass the filters is definitely a plus.
Scenario: Wife is playing some free games on her iPhone. Those games rely on advertisements to give you extra bonuses, timers…
She’s mad if she loses those ads.
Meanwhile I don’t care about those I hate ads. I’m installing uBlock Origin on all my devices that can have it. I would love to add the filtering capability to devices that don’t support that.
1 Like
Hot off the press - a simple update…
rpz-beta-0.1.18-18.ipfire on 2025-02-01
rpz.cgi:
- new feature: added a mod key to force a unbound restart
rpz-config and rpz-make:
- new feature: added action for unbound restart
rpz-config unbound-restartrpz-metrics
- simple reformatting
- rename far right column from “last update” to “last download”
rpz-beta-0.1.18-18.ipfire.tar (40 KB)
3 Likes
Ive installed the new version you just put out and it seems the whitelist is ignoring anything that doesn’t have a * as in domain.com
09:56:50 unbound: [12007:0] info: rpz: applied [allow] *.nist.gov. rpz-passthru 192.168.4.65@54083 time-c-g.nist.gov. AAAA IN
09:56:50 unbound: [12007:0] info: rpz: applied [allow] *.nist.gov. rpz-passthru 192.168.4.65@54083 time-c-g.nist.gov. A IN
09:56:50 unbound: [12007:0] info: rpz: applied [NSAspy] nist.gov. rpz-nxdomain nist.gov. DS IN
09:56:50 unbound: [12007:0] info: rpz: applied [allow] *.nist.gov. rpz-passthru 192.168.4.65@42980 time-c-g.nist.gov. AAAA IN
09:56:50 unbound: [12007:0] info: rpz: applied [allow] *.nist.gov. rpz-passthru 192.168.4.65@42980 time-c-g.nist.gov. A IN
09:56:46 unbound: [12007:0] info: rpz: applied [hagezi_doh] dns.google. rpz-nxdomain 192.168.4.21@54086 dns.google. HTTPS IN
09:56:46 unbound: [12007:0] info: rpz: applied [hagezi_doh] dns.google. rpz-nxdomain 192.168.4.21@65224 dns.google. A IN
09:56:30 unbound: [12007:0] info: rpz: applied [hagezi_doh] dns.google. rpz-nxdomain 192.168.4.21@55071 dns.google. HTTPS IN
09:56:30 unbound: [12007:0] info: rpz: applied [hagezi_doh] dns.google. rpz-nxdomain 192.168.4.21@58638 dns.google. A IN
09:56:29 unbound: [12007:0] info: rpz: applied [hagezi_doh] dns.google. rpz-nxdomain 192.168.4.21@52201 dns.google. A IN
09:56:29 unbound: [12007:0] info: rpz: applied [hagezi_doh] dns.google. rpz-nxdomain 192.168.4.21@54615 dns.google. HTTPS IN
09:56:29 unbound: [12007:0] info: rpz: applied [hagezi_doh] dns.google. rpz-nxdomain 192.168.4.21@54783 dns.google. A IN
09:56:25 unbound: [12007:0] info: rpz: applied [allow] *.apple-dns.net. rpz-passthru 192.168.4.238@49428 gateway.fe2.apple-dns.net. A IN
09:56:25 unbound: [12007:0] info: rpz: applied [hagezi_ultimate] *.thecatmachine.com. rpz-nxdomain 192.168.4.238@65116 x.thecatmachine.com. A IN
09:56:25 unbound: [12007:0] info: rpz: applied [hagezi_ultimate] *.thecatmachine.com. rpz-nxdomain 192.168.4.238@53969 x.thecatmachine.com. HTTPS IN
my whitelist
apple.com
google.com
dns.google
apple-dns.net
dropbox.com
nist.gov
amazon.com
googleapis.com
sync.afraid.org
*.dns.google
*.facebook.com
*.apple.com
*.icloud.com
*.amazon.com
*.microsoft.com
*.nvidia.com
*.dropbox.com
*.nist.gov
*.apple-dns.net
*.google.com
*.apple.com
I did NAME=rpz ./update.sh to update the working version i was using that you released before this one
EDIT: ok so i fixed the issue with the whitelist, apparently unbound-control stop and then start took care of it… not sure why the reload didnt work but now all the allow domains are being processed
1 Like
I think this is a problem of sequence of application of the RPZ lists…
Unbound takes the last occurence of a rule for a domain pattern.
I haven’t found a way to influence the sequence, yet.
For the RPZ addon it should be
<external RPZ lists> <block list> <allow list>
This implies, that external lists don’t contain PASSTHRU and a second rule for ‘example.com’ from allow list supersedes the block rule for ‘example.com’ in an external list.
1 Like
Since the new version, you can hold down the shift key to execute a ‘restart’ instead of a ‘reload’ 
3 Likes
RPZ seems to be “first come, first serve”. It finds the first occurrence of the domain, then uses its CNAME action (NXDOMAIN or PASSTHRU), and then stops looking.
So the current order is:
<allow list> <all other lists>
I had some other behaviours, unfortunately. I’ve allowed some patterns from Hagezi’s Multi list ( same domain pattern! ). But often the block action is triggered instead of the allow action. 
If you’ve done an unbound restart and still see a block happen instead of the allowlist, please let me know the details:
- rpz list used,
- the items in the allowlist,
- the domain visited,
- and the message log entries.
I do see this happen once every month or two using the Apply button (unbound reload), but I am making lots of changes to the various list as I try different things.
A unbound restart did solve the problem.
I’ll watch the situation, especially after an automatic update of the RPZ files.
1 Like
This morning Multi list was updated.
The allow/block behaviour since unbound restart hasn’t changed.
Info about the case:
- allow list entry:
logs.netflix.com
line in allow.rpz :logs.netflix.com CNAME rpz-passthru. - used RPZ list:
https://raw.githubusercontent.com/hagezi/dns-blocklists/main/rpz/multi.txt
I added this to my allowlist and did an unbound restart (not a reload).
Please send the unbound rpz message logs from the time you did the manual unbound restart. The beginning looks like:
Feb 4 10:37:21 ipfire unbound: [5995:0] info: service stopped (unbound 1.22.0).
I used this in the past:
grep -e rpz -e unbound -e "info: service stopped" /var/log/messages
Then send as a DM.
hello and good day
sorry for the question, but I updated the system with the latest version, and I wanted to ask why the modification to the configuration web page recommended by @siosios in post 254 has not been included
mine is just out of curiosity
jon has something different in mind other then what i hacked into the cgi on my post and will be added when he has it worked out and ready for everyone.