ADBLOCKING
Now that we’ve secured our DNS, we can move on to improving the quality of our experience on the internet by configuring DNS ad blocking. With the 20.7 version of OPNSense it’s quite easy. Simply go to Services -> Unbound DNS -> Blacklist. Click Enable and select one or more items from the DNSBL drop down. Or if you prefer, paste the URLs of your preferred list in the URLs field. I prefer the Stephen Black list as it is composed of multiple lists and is also the default list for the Pi Hole. Click Save and you’re done.
ADBLOCK LIST UPDATE
Now that we’ve configured the block list, we want to make sure that it updates when new domains are found. This doesn’t happen automatically when you configure it but is easy to add. Go to System -> Settings -> Cron. Once there you’ll click on the + button and create a new job. The default options are fine and will update the block list daily at midnight. Select “Download Unbound DNSBLs and restart” from the Command list and provide a descriptive comment in the Description field. There may be two items with the same name in the Command field. Either one should work but you should check back after each update to ensure it’s correctly configured once the bug is fixed. If you wish to investigate further, you will want to look at /var/cron/tabs/nobody and you should see /usr/local/sbin/configctl unbound dnsbl
DNS LOCKDOWN
Now that we’ve configured our DNS to block malware and ads, we’re all set, right? Because anyone on the network can configure their device to use a different DNS and they will completely bypass all of the work that we’ve done. Roku, for example, comes configured to use Google DNS in addition to that provided by DHCP. Firefox defaults to a DoH setup.
Now we have two choices. We can either redirect all DNS queries to our server or we can simply block all queries except for our server. Since the server hands out a DNS configuration with every DHCP lease, I choose to block the queries. It also makes for easier troubleshooting as you don’t query one server but resolve a different one.
In order to block the servers you’ll need to go to Firewall -> Rules -> Floating. This ensures that you’ll block DNS on all interfaces. Click on the Add button and we’ll configure the rule as follows. Select Block as the Action. Select all appropriate interfaces. Select IPv4+IPv6 for your TCP/IP Version. Select TCP/UDP as the Protocol. Select Invert and This Firewall for your Destination. The Destination port is DNS. Provide an appropriate description and click Save. Once that’s done, click on the Clone button for the rule you just made. Change the Port to 853 and give it an appropriate description. Then click on Apply Changes.
You can easily test the standard DNS block by using nslookup like we tested the original Quad9 setup. However, in order to test the DoT block you will need to install kdig or a similar tool. It is part of the knot-dnsutils package so you will need to install that. Then you can make a DoT call to determine if you are able to connect.
DNS OVER HTTPS LOCKDOWN
Due to the way DoH works it’s not as simple to block. Since it runs over HTTPS you can’t just block 443 as that will block all of the internet. As far as I can tell there isn’t a list of DoH servers available so you will have to handle them manually and determine yourself if it’s worth the effort.
Most DoH connections use standard DNS to bootstrap the connection in order to know which DoH server to use. For example, they will query dns.google.com. Obviously, you can add dns.google.com and other DoH domains to your DNS domain block list and that will cover most cases. However, some DoH servers will accept connections via IP. Which means that in order to stop those you will need to completely block all traffic to the IP.
I’m still contemplating how I want to handle DoH, so please pass along any ideas or suggestions you may have.
Thank you! Very helpful and nice article! Good job.
Thanks. Glad I could help.
Nice 2 articles, but you lost me on the firewall rules. If I understand correctly, those 2 rules would block all DNS traffic on the LAN to the firewall.
Here is what you wrote:
“Now we have two choices. We can either redirect all DNS queries to our server or we can simply block all queries except for our server. Since the server hands out a DNS configuration with every DHCP lease, I choose to block the queries….”
If you are running Unbound on the firewall, wouldn’t you want all DNS queries on the LAN to go to the firewall (so DHCP DNS server = firewall), and block any other DNS traffic from leaving the LAN?
Please ignore earlier comment – I think I get it (the invert rule part I missed)
Awesome. Glad you were able to get it working.
It does seem a bit overkill to try to block all DoH traffic, but the only way I can think of doing it is to keep track of the DHCP leases of your new/untrusted devices such as smartTV’s and log their HTTPS traffic, and after that try to make DoH calls to those IPs.
But I guess you would like to lock down those devices from phoning home anyway, which they can do over your own DNS server.
I’ll agree that it’s a bit overkill, hence why I haven’t put a lot of effort towards it. I’ve considered writing an OPNSense plugin that will only allow outbound traffic to IPs that have been returned by Unbound. Not sure how feasible it is.
The block lists actually help decently well with devices phoning home.
That is an excellent idea. It is elegant, and keeps our blacklists completely useful.Jay
Since we already know the big players of DoH and DoT, can we just create an alias for that IPs and block/reject them altogether with firewall rule?
I’ve been doing that with their dns entries currently. But that doesn’t help with hard coded IPs so I will probably implement what you’re suggesting. Especially now that I know OPNSense can pull aliases from an online list.
Hi, thanks for the guide! Much appreciated.
I have one small issue though. When I implement the floating Rule under “DNS LOCKDOWN”, my Chromecast disconnects from my network, and I cannot join it to the wifi again. If I disable the Floating rule, it’s OK again. Changing upstream DNs to 8.8.8.8 and disabling DoT doesn’t help.
It’s obviously some sneaky Google shit at work… Any ideas on how to solve it, while still preserving DNS intercept and security?
Not sure what you mean about the chromecast disconnecting from the wifi and being unable to join. Nothing in the guide should affect your wifi.
You’ll need to look at your wifi setup and determine if it’s actually not connected or just complaining about no connectivity. Probably have to do a packet capture to figure out what it’s trying to do and why.
Hi
I have prepared these steps, but YouTube ads still appear that have not been blocked, even though I chose (Block YouTube ads) from the list
my regards
I’m not sure exactly what you mean when you say you chose “Block YouTube ads”. Are you referring to the Blocklist.site Youtube entry in the drop down?
This guide seems to work great. However I have 1 issue. I have one host running a static IP and have a couple ports forwarded for it. It’s hard to explain but it more or less half breaks it. This host is a headless server that doesn’t require any ad blocking or DNS lock. Is there a way to whitelist this 1 single device?
The easiest method is to configure the host to use your upstream DNS and add the host as an exception to your DNS blocking rules.