I used to use Pi-Hole as my network wide ad-blocker and for local DNS so I can have some like nas.homeserver.lan for all my services I host at home, but I recently learned about Unbound DNS in OPNsense and switched to it, I use DNS over TLS with quad9 for my upstream DNS, I also have various blocklists enabled,
- Abuse.ch - ThreatFox IOC
- AdGuard List
- EasyList
- EasyPrivacy
- Steven Black List
- YoYo List
- Ads Blocklist
- NSFW Blocklist
- Threat Intelligence Feeds
- Fake - scams / fakes
- Pop-Up Ads
- Badware Hoster blocking
and I have various overrides mimicking what I had in Pi-Hole for all my services such as nas.homeserver.lan also added few of my domains for split horizon DNS so the traffic can stay local when I am at home. I also have a floating rule that blocks all port 53 traffic on all my interfaces/VLANs except WAN and and WG interfaces and I also have a destination NAT rule that forwards all port 53 traffic to 127.0.0.1 to force all traffic via Unbound basically.
Now everything works fine, except every few mins, IDK if it crashes or what but DNS resolutions keep failing and I see SERVFAIL error in the Unbound logs and the only solution to this is to restart the Unbound DNS service couple of times and the cycle continues of it crashing and me restarting it fix the issue.
I have attached some photos for my various settings and rules I have regarding this.
Try disabling the firewall rules for a try. It might be the case that you created a loop where Unbound tries to query itself when it makes upstream queries.
Quote from: meyergru on July 08, 2026, 02:52:38 PMTry disabling the firewall rules for a try. It might be the case that you created a loop where Unbound tries to query itself when it makes upstream queries.
You mean the floating rule that blocks all port 53 traffic for all interfaces? or the destination NAT rule?
Both could be blocking Unbound Traffic when slightly wrong.
Quote from: meyergru on July 09, 2026, 11:02:41 AMBoth could be blocking Unbound Traffic when slightly wrong.
Without both, client might use their own DNS, which is not what I want. I want all devices to my unbound DNS. Perhaps something I can tweak or filter out in the firewall rule to fix this?
I proposed to ,,try" disabling These rules in the absence of you having presented your exact rules, which in Turn prevents anyone from inspecting them for any potential errors.
If Unbound works without them being enabled, it would prove something is wrong and then we can start looking. So basically, this is just a quick and Dirty Test, not a permanent Solution.
My idea about the problem:
When you restart Unbound or a client makes a new request, your destination NAT intercepts it, forwards it to 127.0.0.1 and a state is created. The client receives his answer.
However, Unbound itself needs to communicate with the outside world (upstream DNS or root server) via port 53. Depending on how your floating rule is configured, Unbound will block its own outbound requests. As soon as Unbound needs to update an entry or fetch a new request from the Internet, it will be blocked by the floating rule; it enters an error state, logs a "SERVFAIL", and DNS resolution fails until you restart the service (which clears the status records).
Maybe it's worth trying to adjust the floating rule so that all requests that are not made to the firewall are blocked: using the "Invert" function in the destination:
• Destination: [X] Invert
• Target: This Firewall (self)
Here is my entire floating rule for blocking port 53 and the destination NAT rule for forwarding port 53 traffic to 127.0.0.1, for all 9 VLANs I have,(https://i.postimg.cc/8cTH4hGZ/2026-07-09-21-06.png) (https://i.postimg.cc/KjmNfnbJ/2026-07-09-21-07.png)(https://i.postimg.cc/d3Xh3Y5j/2026-07-09-21-11.png)
Let me know if anything else is needed as well.
What about a rule permitting the redirected traffic?
Also, assuming you have not permitted DNS elsewhere, that floating block rule may be redundant.
I'm not sure this is a case where the rule should be using direction OUT.
Can you try this rule but direction IN, and have a ready-made pass for where the traffic will flow into the firewall. It seems for first post you are sending it to loopback so I expect not needed but I might not see the whole picture.
Just a suggestion, instead of redirecting all DNS queries to 127.0.0.1, you could create a VLAN interface and assign it a static IP address. Note, I've set this interface with a /32 network address.
(https://forum.opnsense.org/index.php?action=dlattach;attach=56479;image)
Configure your DHCP Server's DNS entry with this address.
When this is all working, then you could tackle the firewall rules to only access to DNS servers you define, be it internal and external.
Attached are notes to configure Unbound on OPNsense and forward all queries to Quad9. The notes were from a default installation of OPNsense 26.1.7,
It may assist with getting your environment working better. Once its working, you can look at tightening the configurations further.
I've not got any notes regarding firewall rules so I'll add screenshots in a separate post of the firewall rules and include some Unbound screenshots.
My Unbound Settings.
More to come.
Firewall settings.
Outbound NAT for internal DNS servers.
Appreciate all the suggestions and comments. I added a source of "This Firewall" and checked the invert source for both the destination NAT and floating rule, and I still have the issue.(https://i.postimg.cc/L5sxpCkY/2026-07-12-05-56.png)(https://i.postimg.cc/MHG9SP0v/2026-07-12-05-57.png)
You accidentally inverted the Source instead of the Destination, and your Floating Rule is currently filtering outbound traffic (which is still blocking Unbound from reaching the internet).
Here is how both rules need to be configured:
1. Correct Destination NAT Configuration
Interface: Select all your local Interfaces/VLANs (do NOT select WAN or WireGuard).
Protocol: TCP/UDP
Source: any (Leave this completely default, do not invert!).
Port: *
Destination / Invert: Check the [X] (Invert) box.
Destination: Select This Firewall (self).
Port: 53 (domain)
Redirect Target IP: 127.0.0.1
Redirect Target Port: 53 (domain)
Filter Rule Association: Set this to Pass
Your current rule applies to traffic where the Source is not the firewall. We want it to apply to any client whose Destination is not the firewall.
2. Correct Floating Rule Configuration
If you still want to use the Floating Rule as a fallback block for port 53, it must only block incoming traffic from clients, never outbound traffic from Unbound.
Action: Block or Reject
Quick: Checked [X] (Apply immediately)
Interface: Select your local Interfaces/VLANs (do NOT select WAN, WireGuard, or Loopback).
Direction: Change this to IN (Currently, it is set to OUT, which blocks Unbound from hitting WAN!).
Protocol: IPv4 TCP/UDP
Source: any (Do not invert!).
Port: *
Destination / Invert: Check the [X] (Invert) box.
Destination: Select This Firewall (self).
Port: 53 (DOMAIN)
By setting Source: ! This Firewall, your rule was trying to match packets where the sender wasn't the firewall. We need to match packets where the intended target (Destination) isn't the firewall.
Your Floating Rule had the <- arrow (Outbound). This meant whenever Unbound itself tried to send a DNS request out to the internet via WAN, the firewall blocked it. Changing the direction to IN ensures it only blocks clients trying to push unauthorized DNS traffic into your local interfaces.
Quote from: RES217AIII on July 12, 2026, 08:02:21 AMYou accidentally inverted the Source instead of the Destination, and your Floating Rule is currently filtering outbound traffic (which is still blocking Unbound from reaching the internet).
Here is how both rules need to be configured:
1. Correct Destination NAT Configuration
Interface: Select all your local Interfaces/VLANs (do NOT select WAN or WireGuard).
Protocol: TCP/UDP
Source: any (Leave this completely default, do not invert!).
Port: *
Destination / Invert: Check the [X] (Invert) box.
Destination: Select This Firewall (self).
Port: 53 (domain)
Redirect Target IP: 127.0.0.1
Redirect Target Port: 53 (domain)
Filter Rule Association: Set this to Pass
Your current rule applies to traffic where the Source is not the firewall. We want it to apply to any client whose Destination is not the firewall.
2. Correct Floating Rule Configuration
If you still want to use the Floating Rule as a fallback block for port 53, it must only block incoming traffic from clients, never outbound traffic from Unbound.
Action: Block or Reject
Quick: Checked [X] (Apply immediately)
Interface: Select your local Interfaces/VLANs (do NOT select WAN, WireGuard, or Loopback).
Direction: Change this to IN (Currently, it is set to OUT, which blocks Unbound from hitting WAN!).
Protocol: IPv4 TCP/UDP
Source: any (Do not invert!).
Port: *
Destination / Invert: Check the [X] (Invert) box.
Destination: Select This Firewall (self).
Port: 53 (DOMAIN)
By setting Source: ! This Firewall, your rule was trying to match packets where the sender wasn't the firewall. We need to match packets where the intended target (Destination) isn't the firewall.
Your Floating Rule had the <- arrow (Outbound). This meant whenever Unbound itself tried to send a DNS request out to the internet via WAN, the firewall blocked it. Changing the direction to IN ensures it only blocks clients trying to push unauthorized DNS traffic into your local interfaces.
OK here is my destination NAT rule now, (https://i.postimg.cc/wjcW3qD7/2026-07-12-12-42.png)(https://i.postimg.cc/wjcW3qDv/2026-07-12-12-43.png)
and here is the floating rule, (https://i.postimg.cc/xCkyGnbD/2026-07-12-12-46.png)(https://i.postimg.cc/rmdCGMR3/2026-07-12-12-47.png)
Are these correct now? And this will force all clients to use Unbound as their DNS even if they set some custom DNS manually? Like android phones have hardcoded 8.8.8.8 DNS I think.. and the destination NAT rule will forward all the traffic for port 53 that we block via floating to Unbound?
The rules look "O.K." now. I told you to first check if your rules cause the problems in my first answer (https://forum.opnsense.org/index.php?msg=269879), for somehow I guessed that you redirected "all" port 53 traffic, creating an endless loop like explained here (https://forum.opnsense.org/index.php?msg=262022).
What can you learn of this? Your rule of thumb should be: If you experience problems, show your rules, because often times, they are the cause of it. See also the "READ THIS FIRST" article (https://forum.opnsense.org/index.php?topic=42985.0) in the tutorial section.
That being said, your current rules alone will not help you with either DoT or DoH, which are the default in many browsers now.
There is a discussion about this (https://forum.opnsense.org/index.php?topic=9245.0) also in the tutorial section.
Basically, you can block port 853 for DoT, but you need a blocklist for known DoH services because you cannot block port 443.
Also, there are a few more kinks in your rules, because they apply to IPv6 as well, see this (https://forum.opnsense.org/index.php?msg=246513).
On a side note: I have given up on the "block any other DNS than my own" game, because you cannot win it.
Quote from: apoorv569 on July 07, 2026, 07:25:14 PMI used to use Pi-Hole as my network wide ad-blocker and for local DNS so I can have some like nas.homeserver.lan for all my services I host at home, but I recently learned about Unbound DNS in OPNsense and switched to it
Why did you decide to do so ?
Quoteand I have various overrides mimicking what I had in Pi-Hole for all my services such as nas.homeserver.lan also added few of my domains for split horizon DNS so the traffic can stay local when I am at home. I also have a floating rule that blocks all port 53 traffic on all my interfaces/VLANs except WAN and and WG interfaces and I also have a destination NAT rule that forwards all port 53 traffic to 127.0.0.1 to force all traffic via Unbound basically.
To avoid any weird issues like the ones explaned in previous posts where your main DNS Resolver is not able to reach the Internet there is one simple solution :
Make sure the network it uses is not involved in the Redirecting NAT and Firewall Rules at all :)
Network used by Pi-Hole + Unbound : 192.168.x.x/24
Networks with active Redirecting NAT and Firewall Rules : 10.0.x.x/24
And if you need your Pi-Hole to contact OPNsense DNSmasqd for DNS Records then just use Conditional Forwarding and you are DONE! ;)
Quote from: apoorv569 on July 12, 2026, 09:21:33 AMLike Android phones have hardcoded 8.8.8.8 DNS I think..
Actually that's a very weird story which seems to work like this as far as I have got to know it over the years :
- Give your Android Clients just 1 DNS IP Address and there is a huge chance that Android will attach 8.8.8.8 and 8.8.4.4 to the list.
So your DNS configuration looks like this eventually :
192.168.x.x
8.8.8.8
8.8.4.4
- Give your Android Clients 2 DNS IP Addresses and there is a huge chance that Android will just use those two.
- Give your Android Clients 4 DNS IP Addresses and it seems the Google DNS Servers are completely ignored.
But...
Should your DNS Server(s) go OFFLINE then it's right back to 8.8.8.8 and 8.8.4.4 and your Android Clients won't even notice the issue ?!?!
Quote from: lmoore on July 09, 2026, 11:16:54 PMJust a suggestion, instead of redirecting all DNS queries to 127.0.0.1, you could create a VLAN interface and assign it a static IP address. Note, I've set this interface with a /32 network address.
I think you meant to say Virtual IP Address ?!
Quote from: meyergru on July 12, 2026, 10:16:22 AMOn a side note: I have given up on the "block any other DNS than my own" game, because you cannot win it.
Still no reason to do as much as we can and prevent the stuff we CAN prevent :)
Quote from: nero355 on July 12, 2026, 07:41:38 PMQuoteJust a suggestion, instead of redirecting all DNS queries to 127.0.0.1, you could create a VLAN interface and assign it a static IP address. Note, I've set this interface with a /32 network address.
I think you meant to say Virtual IP Address ?!
For now it is. I plan to make changes down the track and have some services on a DMZ network. I moved the DNS block lists from an internal server to OPNsense and as I don't want to be using redirection for DNS requests, it was assigned to a dummy DMZ interface. The DNS servers in DHCP were updated.
I only redirect Googles DNS IPv4 address to an internal DNS server. This is to cater for an entertainment device that when viewing content always queries 8.8.8.8, even though it has a valid DNS server entry from DHCP.
I've noticed that when my Internet stops working, for example when the local utility power goes out and the batteries for the vDSL equipment have been exhausted, Windows 10 & 11 detect a failure to resolve names via the configured DNS servers and attempt to connect to 8.8.8.8 & 8.8.4.4.
Quote from: meyergru on July 12, 2026, 10:16:22 AMBasically, you can block port 853 for DoT, but you need a blocklist for known DoH services because you cannot block port 443.
The easiest way to block ports 53 & 853 is to create rules which blocks connections to a negated (Invert Destination) destination address to ExternalTrustedIPv4DNSServers.
Firewall rules to block Internal & firewall itself to External untrusted DNS servers - ports 53 & 853;
(https://forum.opnsense.org/index.php?action=dlattach;attach=56590)
Firewall rules to allow connections to Internal DNS servers and Internal DNS servers to trusted External servers;
(https://forum.opnsense.org/index.php?action=dlattach;attach=56592)
Firewall rules to block connections to DNS servers using port 443 (DOH) - I think the last Group rule was made redundant.
(https://forum.opnsense.org/index.php?action=dlattach;attach=56594)
I don't know how best to measure the effectiveness of blocking connections to DOH, however, I have noticed iPhones getting blocked when they attempt to connect to Apple's DOH servers.
One user on my network has decided to use another DNS server geographically located a very long way away - the device fails to connect to the DNS server via my network so it is taken off the network and connected via the devices mobile network.
For completeness, the redirection of Google DNS;
(https://forum.opnsense.org/index.php?action=dlattach;attach=56596)
Also, the Source NAT rule for outbound DNS queries, note the use of a tag. The appropriate rule will add the tag to the traffic going to the trusted external DNS servers.
(https://forum.opnsense.org/index.php?action=dlattach;attach=56598)
Quote from: lmoore on July 13, 2026, 08:10:02 AMWindows 10 & 11 detect a failure to resolve names via the configured DNS servers and attempt to connect to 8.8.8.8 & 8.8.4.4.
That's funny because there is some Cloudflare DNS registered somewhere in the Registry of Windows 10 that contacts it from time to time for whatever reason...
I guess they could not decide which competitor they liked more ?! :P
Quote from: nero355 on July 13, 2026, 04:05:08 PMThat's funny because there is some Cloudflare DNS registered somewhere in the Registry of Windows 10
Perhaps its not Windows itself but some other application installed on the computer which has hard coded DNS server entries to use.
To satisfy my curiosity I will at some point perform a packet capture of the two Google DNS server addresses and then drop the Internet connection and flush DNS caches and wait to see what happens.
Quote from: lmoore on July 13, 2026, 05:14:22 PMPerhaps its not Windows itself but some other application installed on the computer which has hard coded DNS server entries to use.
No it's really Windows 10 itself but I can't remember what it was about...
Grab a Window 10 PC or Laptop and search for it with regedit.msc and you will probably find it :)
Quote from: nero355 on July 13, 2026, 11:16:37 PMNo it's really Windows 10 itself but I can't remember what it was about
I've not found anything on Windows 10, however, Windows 11 has 'DoHWellKnownServers' in the registry. Perhaps this is what you are thinking of.
Last night I blocked connections on one of my networks to the DNS server address on OPNsense. Checking this morning, there were no queries either from Windows-10 or Windows-11 to the Google DNS servers.
Quote from: lmoore on July 14, 2026, 04:39:00 AMPerhaps this is what you are thinking of.
I will let you know once I figure out what it was :)
Quote from: meyergru on July 12, 2026, 10:16:22 AMThe rules look "O.K." now. I told you to first check if your rules cause the problems in my first answer (https://forum.opnsense.org/index.php?msg=269879), for somehow I guessed that you redirected "all" port 53 traffic, creating an endless loop like explained here (https://forum.opnsense.org/index.php?msg=262022).
What can you learn of this? Your rule of thumb should be: If you experience problems, show your rules, because often times, they are the cause of it. See also the "READ THIS FIRST" article (https://forum.opnsense.org/index.php?topic=42985.0) in the tutorial section.
That being said, your current rules alone will not help you with either DoT or DoH, which are the default in many browsers now.
There is a discussion about this (https://forum.opnsense.org/index.php?topic=9245.0) also in the tutorial section.
Basically, you can block port 853 for DoT, but you need a blocklist for known DoH services because you cannot block port 443.
Also, there are a few more kinks in your rules, because they apply to IPv6 as well, see this (https://forum.opnsense.org/index.php?msg=246513).
On a side note: I have given up on the "block any other DNS than my own" game, because you cannot win it.
It worked for a while but seems to be happening again. I'm wondering that there are so many queries being made per second that upstream limits or times out or something..
Queries for what names? Also, there are some settings on "Services: Unbound DNS: Advanced" that should NOT be applied, like "Strict QNAME Minimization" - there are warnings in their help texts.
Quote from: apoorv569 on July 15, 2026, 07:39:48 AMI'm wondering that there are so many queries being made per second that upstream limits or times out or something
Two suggestions for you to check;
1 - OPNsense Web GUI: Do you have
Traffic Reporting -> Traffic open, maybe in another tab, and if so close it.
2 - Open
Interface -> Neighbors - Automatic Discovery and disable it if it's enabled.
Quote from: apoorv569 on July 15, 2026, 07:39:48 AMIt worked for a while but seems to be happening again.
Did you set up your environment as per these Configuration notes (https://forum.opnsense.org/index.php?action=dlattach;attach=56470) and the screen shots in this message (https://forum.opnsense.org/index.php?msg=269984) as your starting point, before adding all the extras as per your original screen shots?
I can only suggest going back to basic rules to allow DNS to work properly from wherever before clamping down, as each rule applied to block DNS needs to be properly tested. Perhaps disable the DNS redirection for now and do this last, once everything else is working.
[Edit] Updated link to
Configuration notes.
Quote from: meyergru on July 15, 2026, 09:07:45 AMQueries for what names? Also, there are some settings on "Services: Unbound DNS: Advanced" that should NOT be applied, like "Strict QNAME Minimization" - there are warnings in their help texts.
I disabled the floating rule and destination NAT rule and also turned off string qname minimization and the problem still exists.
Quote from: lmoore on July 15, 2026, 02:57:41 PMQuote from: apoorv569 on July 15, 2026, 07:39:48 AMI'm wondering that there are so many queries being made per second that upstream limits or times out or something
Two suggestions for you to check;
1 - OPNsense Web GUI: Do you have Traffic Reporting -> Traffic open, maybe in another tab, and if so close it.
2 - Open Interface -> Neighbors - Automatic Discovery and disable it if it's enabled.
Quote from: apoorv569 on July 15, 2026, 07:39:48 AMIt worked for a while but seems to be happening again.
Did you set up your environment as per these Configuration notes (https://forum.opnsense.org/index.php?action=dlattach;attach=56480) and the screen shots in this message (https://forum.opnsense.org/index.php?msg=269984) as your starting point, before adding all the extras as per your original screen shots?
I can only suggest going back to basic rules to allow DNS to work properly from wherever before clamping down, as each rule applied to block DNS needs to be properly tested. Perhaps disable the DNS redirection for now and do this last, once everything else is working.
What does traffic reporting and neighbor discovery has to do with DNS? Genuinely curious.
Where are the logs of Unbound crashing and is it a segfault or is it still running but not processing requests or is it exiting? I must be getting old.
Cheers,
Franco
Quote from: apoorv569 on July 18, 2026, 07:55:51 AMWhat does traffic reporting and neighbor discovery has to do with DNS
PTR queries.
I've just enabled Neighbour Discovery on my firewall but there aren't any PTR queries occurring. When this feature was first delivered I'm sure it was generating PTR queries.
If you open Traffic Reporting and click on the 'Top Talkers' tab you will see the list of hosts and their DNS names, assuming they could be resolved.
I run a local proxmox server at home for self hosting various applications. And I have noticed this multiple times now, when I turn off my proxmox server for any reason, my Unbound server on OPNsense works fine with no issues. Like I have my server off for 2 days now, and I faced absolutely no issues, not a single time, but when I turn my server back on, it will eventually start to crash or whatever happens. I don't have the NAT rule, nor the floating rule and neither do I have the qname option turned on. At this point it has to be OPNsense that has a bug or my system running OPNsense is unable to processes that many queries, which I doubt, so it must be a bug from OPNsense side.
EDIT: My entire OPNsense box seems like crashed.. this is the second time it happened.. by crash I mean randomly disappears, I can't ping it, all links go down, the switch shows only yellow light no green.. I have a port on the OPNsense box for emergency situations and I could not get a shell or anything via that either, I had to hard reboot.. not implying that its happening because of Unbound BTW.