Unbound DNS Resolver intermittently unresponsive on specific LAN interfaces — pfSense Plus 26.03.1

litsiew

Environment: pfSense Plus 26.03.1-RELEASE (amd64), Kea DHCP backend, dual WAN (SingTel + Starhub 10G) in a balanced gateway group, UniFi switches/APs for L2/WiFi.

Symptom:
Clients on guest-type interfaces intermittently cannot resolve any DNS names via Unbound. nslookup against the pfSense interface IP returns consistent timeouts (“DNS request timed out… Server: Unknown”) for a period, then resolution starts working again with no corresponding config change, then fails again later — unpredictably, sometimes within the same hour.

What works:
Main LAN and a separate IoT VLAN (also 802.1Q tagged, same physical trunk/parent interface, same Unbound instance) resolve DNS reliably with no observed failures throughout testing.

What was tested, to rule out a config cause:

•	Original guest VLAN (tag 60, long-standing, accumulated firewall ruleset) — fails intermittently
•	Brand-new guest VLAN (tag 62) built from scratch — new subnet, new DHCP scope, minimal 1-2 rule firewall ruleset, new Unbound interface binding — fails identically and intermittently, ruling out stale/accumulated config as the cause
•	Wireless (UniFi AP) and a directly wired client on the same VLAN (bypassing WiFi/AP entirely) — same failure on both
•	DHCP (Kea) always hands out correct gateway/DNS/IP — confirmed via ipconfig /all every time, never wrong
•	Unbound shows “running” in Status → Services throughout
•	Network Interfaces / Outgoing Network Interfaces tried as both explicit list and “All”
•	Access Lists confirmed empty (default permissive)
•	Firewall rules tested at every restriction level, including a fully-open rule — no change
•	Floating rules checked — none apply to the affected interfaces
•	Hardware Checksum Offloading disabled, rebooted — no change
•	DHCP “DNS Registration” and “Early DNS Registration” set to Disable on both old and new guest interfaces — no durable change; appeared to help briefly on both occasions before failing again
•	Packet capture on the affected interface during a failure window showed DNS queries leaving the client toward pfSense, zero responses returned, over ~9 minutes of continuous capture
•	Confirmed via direct nslookup against pfSense’s main LAN IP, from the main LAN, that Unbound answers correctly and quickly during the same window the guest interface was failing — ruling out a fully crashed/dead Unbound process

Timing: Issue first noticed roughly 2 weeks ago, coinciding with a pfSense update (exact prior version not confirmed). No clear interval pattern identified yet between failures.

Question: Given Unbound works reliably on some LAN-type interfaces and intermittently fails on others (regardless of how recently/minimally those interfaces were configured), is there a known interaction — gateway monitoring (dpinger) events, scheduled Unbound reloads, or per-interface socket/binding issues — that could cause this kind of isolated, self-resolving, self-recurring DNS failure?

Happy to provide packet captures, config excerpts, or further logs on request. Thanks!

litsiew

Update: I have an ISP (although in bridge mode) with packet-losses. Found that the DNS-override in PfSense interfered with my guest network internet. Disabling it helped get Internet back, but the brand new guest VLAN (tag 62) still suffered intermittent issues; cause unclear.

Gertjan

@litsiew

What you can check :
Resolver listens on all interfaces ?

Fact-check if it really does :

[26.03.1-RELEASE][root@pfSense.bhf.tld]/root: sockstat | grep unbound
unbound unbound    71193  3 udp6    *:53                  *:*
unbound unbound    71193  4 tcp6    *:53                  *:*
unbound unbound    71193  5 udp4    *:53                  *:*
unbound unbound    71193  6 tcp4    *:53                  *:*
unbound unbound    71193  9 tcp4    127.0.0.1:953         *:*
unbound unbound .....
.......

This command shows on what interfaces, what protocol and what port unbound, the resolver, is listening.
My example shows : all interfaces = . all protocols = TCP and UDP, and port 53.

Check for all LAN type pfSense interfaces the firewall rules.
Example : my LAN interface :

this rule, or equivalent, like a main pass rule, should be placed on every LAN type interface.

And last but least :
How often does your resolver restart ?

[26.03.1-RELEASE][root@pfSense.bhf.tld]/root: grep 'Restart' /var/log/resolver.log
......
<29>1 2026-06-09T13:48:52.549050+02:00 pfSense.bhf.tld unbound 28853 - - [28853:0] notice: Restart of unbound 1.25.1.
<29>1 2026-06-09T13:53:07.660209+02:00 pfSense.bhf.tld unbound 60525 - - [60525:0] notice: Restart of unbound 1.25.1.
<29>1 2026-06-17T12:54:53.001794+02:00 pfSensebhf.tld unbound 21239 - - [21239:0] notice: Restart of unbound 1.25.1.

If the resolver (unbound) restarts ones or twice per week, that's ok.
Several times each hour, or more often ? Yeah, that's a problem, as a stopped (during restart) resolver can't server DNS requests,and a restart can take some time.

Next test :
On the LAN and all other LAN type devices, check that the DHCP lease obtained the IP of the pfSense interface as it's DNS.
For example, on my LAN I have a PC, so :
ipconfig /all
.....```

Serveurs DNS. . . . . . . . . . . . . : 2a01:cb19:dead:beef:77ff:fe29:392c
192.168.1.1

and 192.168.1.1 is (of course) my pfSense LAN IP, where unbound is listening.
Do this for all your devices ^^

last but not least : when you install a browser, it won't use the Resolver (== pfSense) as a DNS source, but it will use some "DoH/DoT/DoQ " = this will by pass the pfSense resolver entirely.

litsiew

@Gertjan
Resolver listens on ALL interfaces, confirmed for both Network Interfaces and Outgoing Network Interfaces.

Fact-check:

yes, all firewall rules have the allow port 53 (DNS) pass.

Resolver restarts:

Yes, checked that all LAN use pfSense interface as DNS.

I am sharing a snippet of the resolver log as well. Screenshot 2026-06-24 at 12.02.58 AM.png

while I think these were due to testing (changing settings on my network), may be useful for sharing purposes.

Thank you!

Gertjan

Looks all fine to me.

@litsiew said in Unbound DNS Resolver intermittently unresponsive on specific LAN interfaces — pfSense Plus 26.03.1:

snippet of the resolver log

That log only shows the resolver stops + several stats when stopped, and the start.

You can see what the resolver actually does (== receive DNS requests from LANs) when you ask pfSense to show that info : on the resolver advanced page :

Be warned : don't keep that setting active for long, as with setting 3 or higher, unbound (resolver) will produce massive amounts of log lines.

Another test : Diagnostics > Packet Capture
Look for DNS requests coming into the pfSense LAN interface :

and hit start.
You have to check all your LAN type interface one by one.

You can look for requests from specific LAN hosts : just enter their LAN IP.
Or : DNS requests NOT addressed to pfSense - the LAN interface, but some other DNS server.
Etc etc.

giuliafw70

One useful split test is to capture and log at the same time during a failure window. If packet capture on the guest interface shows the query arriving at the firewall, enable Unbound verbosity briefly and filter for that client IP. If Unbound logs the query, the problem is probably the lookup/upstream path or a SERVFAIL-type condition. If Unbound does not log it at all, then something before the local socket is eating it, and I’d look harder at the per-interface rules/state table for that VLAN rather than the resolver config.

litsiew

@Gertjan and @giuliafw70, thank you both! Guest network has been stable several days now. Will reopen if it recurs.