As early “influencer” of @jon’s work, just some thoughts.
I’m using a home environment with some PCs and SmartTVs, but I think the concept is interesting for greater networks also.
More and more sites switch to HTTPS, which makes it difficult to filter traffic with URL Filter ( SquidGuard ).
More and more admins therefore tend to use appliances like PIHole, which are DNS filters. But this demands big efforts to rule internal DNS traffic.
The RPZ concept allows to place this filtering into IPFire, our internet access gateway, which should solely used as DNS source of the internal network.
The selection of the lists, which are updated automagical by unbound, demands some effort. But I trust in our community for good proposals and verification of these. Jon has collected a good set yet, I think.
My tests with this feature don’t show a significant increase of system load.
What environment?
home
Estimated users?
5+
What value does this have to you?
blocking DOH
securing DNS
What types of things are you hoping to block?
DOH
ads
What did you use in the past?
Pihole
And why did you change?
Having DNS in 2 locations.
Not the greatest to manage.
What would you like to see for RPZ in the future?
A plugin or as core part of IPfire
A WUI
Copy the rpz-n-n-1.ipfire file to the /opt/pakfire/tmp/ directory. (Speak up if you need assistance with this!)
Then:
# go to this directory:
cd /opt/pakfire/tmp/
# uncompress the file:
tar xvf rpz-n-n.ipfire
# check to make sure there are files there:
ls -l /opt/pakfire/tmp
# copy this one file to a new location
cp -v ROOTFILES /opt/pakfire/db/rootfiles/rpz
# - to update from a past version -
NAME=rpz ./update.sh
# - or for a new install -
NAME=rpz ./install.sh
hello, I’m trying it on my application
I took the liberty of doing the translations in Italian if you want to include it in the package rpz.it.zip (893 Byte)
Just a little annotation.
The ‘Apply’ button in the WUI activates the changes. I have added this to the wiki article, yet.
Because this means a reload/restart of unbound the problem of long update periods shows up. But usually there is no need to change the config very often, therefore we can neglect this issue.
Does “Save” also launch unbound-control reload ? Looking in the /var/log/messages it seems it does but I do not see the [OK] after it
Oct 18 09:28:05 black-x86-64 unbound: info: rpz: make config file "00-rpz.conf"
Oct 18 09:28:05 black-x86-64 unbound: info: rpz: create zonefile for "allowlist"
Oct 18 09:28:05 black-x86-64 unbound: info: rpz: make config file "block.rpz.conf"
Oct 18 09:28:05 black-x86-64 unbound: info: rpz: create zonefile for "blocklist"
Oct 18 09:28:42 black-x86-64 unbound: info: rpz: check for errors with "unbound-checkconf"
Oct 18 09:28:45 black-x86-64 unbound: info: rpz: run "unbound-control reload"
Can we have an Reload button near Apply? unbound-control reload is much, much faster than restart of the unbound.
From what I see in the logs, Apply does a restart of the unbound, which is more time consuming: 3 seconds for a Intel(R) N100 x4 machine with 8GB RAM and nVME disk
Oct 18 09:28:45 black-x86-64 unbound: [31035:0] info: service stopped (unbound 1.19.3).
Oct 18 09:28:45 black-x86-64 unbound: [31035:0] info: server stats for thread 0: 153 queries, 54 answers from cache, 99 recursions, 0 prefetch, 0 rejected by ip ratelimiting
Oct 18 09:28:45 black-x86-64 unbound: [31035:0] info: server stats for thread 0: requestlist max 12 avg 1.31313 exceeded 0 jostled 0
Oct 18 09:28:45 black-x86-64 unbound: [31035:0] info: average recursion processing time 0.168153 sec
Oct 18 09:28:45 black-x86-64 unbound: [31035:0] info: histogram of recursion processing times
Oct 18 09:28:45 black-x86-64 unbound: [31035:0] info: [25%]=0.0766537 median[50%]=0.13703 [75%]=0.235334
Oct 18 09:28:45 black-x86-64 unbound: [31035:0] info: lower(secs) upper(secs) recursions
Oct 18 09:28:45 black-x86-64 unbound: [31035:0] info: 0.008192 0.016384 1
Oct 18 09:28:45 black-x86-64 unbound: [31035:0] info: 0.032768 0.065536 19
Oct 18 09:28:45 black-x86-64 unbound: [31035:0] info: 0.065536 0.131072 28
Oct 18 09:28:45 black-x86-64 unbound: [31035:0] info: 0.131072 0.262144 33
Oct 18 09:28:45 black-x86-64 unbound: [31035:0] info: 0.262144 0.524288 17
Oct 18 09:28:45 black-x86-64 unbound: [31035:0] info: 1.000000 2.000000 1
Oct 18 09:28:45 black-x86-64 unbound: [31035:0] notice: Restart of unbound 1.19.3.
Oct 18 09:28:45 black-x86-64 unbound: [31035:0] notice: init module 0: respip
Oct 18 09:28:45 black-x86-64 unbound: [31035:0] notice: init module 1: validator
Oct 18 09:28:45 black-x86-64 unbound: [31035:0] notice: init module 2: iterator
Oct 18 09:28:48 black-x86-64 unbound: [31035:0] info: start of service (unbound 1.19.3).
Hi,
All the rpz-config and rpz-make actions are performed with the --no-reload option. So you should be able to edit multiple times without unbound restarting.
The “Apply” button then runs rpz-config reload which (I think) finally does the unbound-control reload.
I can answer that far from the WUI side, @jon knows better what happens in the scripts
Apologies if I am asking a really stupid question, what EXACTLY does this rpz add-on do, in layman’s terms if possible, please? I have been following this thread but I am still not sure what it actually does, LOL. Please forgive an old man.
