ALERT: Stopping the services associated with pfblockerNG (pfb_dnsbl & pfb_filter) while Unbound / DNS Resolver is running will cause crazy things to happen, including breaking the DNS Resolver service on your device temporarily.
Don’t do this!
Instead, first remove any custom options you’ve implemented with this guide to do with pfBlockerNG from your DNS Resolver Custom Options field.
Then in Firewall → pfBlockerNG deselect Enable pfBlockerNG from the General Settings page and click save.
Navigate to Services→DNS Resolver.
Add the following to the Custom Options.
server:
access-control-view: 192.168.10.0/24 bypass
access-control-view: 192.168.20.0/24 dnsbl
view:
name: "bypass"
view-first: yes
view:
name: "dnsbl"
view-first: yes
include: /var/unbound/pfb_dnsbl.*conf
NOTE: In this example, we have network 192.168.10.x set to an Unbound view that does not include our pfBlockerNG DNSBL configuration.
This means all the Unbound commands generated by pfBlockerNG are not referenced when a client in 192.168.10.x queries pfSense, so DNS queries go through unchanged.
For the 192.168.20.x network, the entries are included and redirected to the pfBlockerNG sinkhole.
It is important to note that you can use these entries in any CIDR notation that fall within your network topology.
To filter content for a specific IP, you could specify 192.168.10.5/32 for example.
server:
access-control-view: 192.168.10.0/24 bypass
access-control-view: 192.168.20.0/24 dnsbl
view:
name: "bypass"
view-first: yes
view:
name: "dnsbl"
view-first: yes
include: /var/unbound/pfb_dnsbl.*conf
local-data: "www.google.com 60 IN A 216.239.38.120"
local-data: "www.youtube.com 60 IN A 216.239.38.119"
local-data: "www.bing.com 60 IN A 204.79.197.220"
local-data: "duckduckgo.com 60 IN A 107.20.240.232"
NOTE: The entries added in the dnsbl view force all clients in this group (192.168.20.x) to the SafeSearch address for each of the four services included.
We have to add them here as adding them as a Host Override on the DNS Resolver configuration page would enforce them for all clients.
server:
access-control-view: 192.168.10.0/24 bypass
access-control-view: 192.168.20.0/24 dnsbl
access-control-view: 192.168.30.0/24 forward
view:
name: "bypass"
view-first: yes
view:
name: "dnsbl"
view-first: yes
include: /var/unbound/pfb_dnsbl.*conf
view:
name: "forward"
view-first: yes
forward-addr: 1.1.1.1
forward-addr: 8.8.8.8
NOTE: The forward view forwards requests to a couple of DNS servers on the Internet.
server:
access-control-view: 192.168.10.0/24 bypass
access-control-view: 192.168.20.0/24 dnsbl
access-control-view: 192.168.30.0/24 forward
access-control-view: 192.168.40.0/24 tls
view:
name: "bypass"
view-first: yes
view:
name: "dnsbl"
view-first: yes
include: /var/unbound/pfb_dnsbl.*conf
view:
name: "forward"
view-first: yes
forward-addr: 1.1.1.1
forward-addr: 8.8.8.8
view:
name: "tls"
view-first: yes
tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt
forward-tls-upstream: yes
forward-addr: 1.1.1.1@853#cloudflare-dns.com
forward-addr: 1.1.1.1
NOTE: To use DNS over TLS, you will need to specify tls-cert-bundle option that points to the local system's root certificate authority bundle, allow unbound to forward TLS requests and also specify any number of servers that allow DNS of TLS.
For each server you will need to specify that the connection port using @, and you will also need to indicate which is its domain name with #. Even though it looks like an comment the hashtag name allows for the TLS authentication name to be set for stub-zones and with unbound-control forward control command. There should not be any spaces between the @ and # markups.