Unbound DNS hard restarts (clearing cache) on LAN link disable

[S1ardust]

Hi everyone,

I am running OPNsense on my network for some weeks now and I am facing an annoying issue where Unbound DNS performs a hard restart (losing its entire cache and resetting uptime to 0) every time my Windows 11 client disconnects from the LAN.

For reasons, I programmatically disable the network adapter on the Windows 11 client multiple times a day via Disable-NetAdapter.

The Phenomenon & Root Cause
Whenever the client disconnects, the virtualized OPNsense (running on Hyper-V) registers a physical link-loss on the LAN interface (hn1). The subsequent link-up triggers the system script /usr/local/etc/rc.newwanip, which forces a global Unbound restart.

Log output
From "System -> Log Files -> General" (or via clog /var/log/system.log):

Code Select Expand

hn1: link state changed to DOWN  (When disabling the client adapter)
hn1: link state changed to UP    (When re-enabling the client adapter)
[... followed by rc.newwanip triggering the Unbound restart ...]

Network Topology
You cannot view this attachment.

What I Have Already Tried (Without Success)

To prevent the Unbound restart on link-up, I have already tested the following:

• Tested the setting "Flush DNS cache during reload"
• Prevent interface removal: Activated under "Interfaces -> [LAN]".
• Unbound Network Interfaces: Bound to "All" instead of specific interfaces.
• System Tunables: Set com.opnsense.disable_interface_cycle = 1.
• ...

Any advice or pointers would be highly appreciated!

Thank you

[Patrick M. Hausen]

Use a switch?

[S1ardust]

Use a switch?

Thanks for the suggestion! Unfortunately, using a switch is not an option in my setup, so I need to find a solution that works without one.

Is there perhaps another way to prevent the LAN link state change from triggering the Unbound restart?

[meyergru]

You could try to hide the "physical" link-state changes from OPNsense by assigning LAN to a bridge interface, with hn1 as a bridge member and an additional virtual interface that stays permanently up.

A bridge containing only hn1 probably won't help, as the bridge itself will go down when its last active member goes down.

A LAGG might be another option, although the same caveat probably applies if it only has a single active member.

You may need to create the "dummy" interface on Hyper-V, though, as I do not see any valid interface type on OpnSense (modulo epair, which you cannot create with the web UI).

[nero355]

All those workarounds/solutions are nice and all, but why does this happen in the first place ?!

Whenever I see this issue popping up for someone I am always glad I don't run Unbound on OPNsense itself : It would drive me mad...

[franco]

> Unbound DNS performs a hard restart (losing its entire cache

Unbound hasn't lost its cache on restart by default for many years...

community/21.7/21.7:o unbound: allow to retain cache on service reload


Cheers,
Franco

[S1ardust]

Hi everyone,

Unbound hasn't lost its cache on restart by default for many years...

quick update on this. I tested franco's hint via SSH to check if the cache is actually wiped.
Here is what I did BEFORE triggering the adapter disconnect:

Code Select Expand

myusername@myhostname:~ # drill @127.0.0.1 www.wikipedia.org
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 242
;; flags: qr rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; www.wikipedia.org.   IN      A

;; ANSWER SECTION:
www.wikipedia.org.      86400   IN      CNAME   dyna.wikimedia.org.
dyna.wikimedia.org.     169     IN      A       185.15.59.224

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 166 msec
;; SERVER: 127.0.0.1
;; WHEN: Mon Sep 21 08:31:19 2026
;; MSG SIZE  rcvd: 80

myusername@myhostname:~ # unbound-control -c /var/unbound/unbound.conf dump_cache | grep "www.wikipedia.org"
www.wikipedia.org.      86373   IN      CNAME   dyna.wikimedia.org.
msg www.wikipedia.org. IN A 33152 1 142 3 2 0 0 -1
www.wikipedia.org. IN CNAME 0

Then I ran Disable-NetAdapter / Enable-NetAdapter on my Windows client.
After the link came back up and Unbound restarted, I checked the cache again:

Code Select Expand

myusername@myhostname:~ # unbound-control -c /var/unbound/unbound.conf dump_cache | grep "www.wikipedia.org"
www.wikipedia.org.      86171   IN      CNAME   dyna.wikimedia.org.

Result:
The entry is still there, and the TTL just counted down normally. It seems franco is right – the actual DNS cache seems to survive the link-reactive restart.

Apparently, only the web GUI counters under "Services: Unbound DNS: Statistics" get fully reset to zero during this process.

Is my logic/conclusion here correct, or am I missing something?
If it's just the statistics being flushed, I can probably live with that.

Thanks for the help!

[franco]

Yes, Unbound restarts and this zeros the (runtime) statistics.  Unbound DNS reporting may be something more persistent you want to consider.


Cheers,
Franco

[S1ardust]

Dear Franco,

thank you for pointing me into the right direction.
Knowing that the actual DNS cache remains intact is a huge relief, as that was my main concern.