Unbound service routinely stopping/crashing following 20.7.7 update

[dinguz]

I also noticed that unbound wasn't restarted after the upgrade 20.7.6 -> 20.7.7, I had to do that manually. Is this intentional?

[miruoy]

Setting the interfaces manually appears to have stabilized the issue. Will report back if the situation changes.

Spoke too soon It just crashed again.

Reverted to unbound 20.7.6 as suggested by Franco

[guest25283]

I can confirm I have the same behaviour. This however only seems to happen when I reboot the firewall, not throughout the day.

Starting Unbound manually solves it for now.
Hope that a fix is available soon.

[deejacker]

Changing and then reverting the interfaces didn’t resolve anything for me, experienced another Unbound service stop shortly afterwards.

[guest15389]

It would be better to pull this update as it completely breaks the system and makes it unusable since DNS crashes over and over.

[mimugmail]

It would be better to pull this update as it completely breaks the system and makes it unusable since DNS crashes over and over.

opnsense-revert -r 20.7.6 unbound

[crowbarz]

I think @Animosity022 meant stop offering the broken unbound 1.13.0 package in System > Firmware > Updates, or releasing 20.7.7_2 with unbound pinned at 1.12.0, or withdrawing 20.7.7_1 altogether (I get there are security issues resolved in this release so that might not be the best option).

Is it possible to at least add a note in the release notes warning people about this issue if they are using unbound in their configuration? So they can then make a more informed decision about whether to upgrade or not.

My backup firewall hasn't been upgraded yet, and 20.7.7_1 with unbound 1.13.0 is still being offered when I check for upgrades. So even if I read the release notes carefully, if I hit upgrade on that firewall, it would be guaranteed to break until unbound is manually reverted (after figuring out unbound had crashed and then finding this thread).

[guest25283]

related?
https://github.com/NLnetLabs/unbound/issues/376

Meanwhile, I reverted to Unbound 1.12.0 using the command that was posted here.
However, it looks like a patch is now included in FreeBSD-ports, based on the latest reply on GitHub.
@franco any chance to include this in a hotfix release, before you guys start to enjoy your much deserved Christmas break? :-) (otherwise indeed a good idea to update the release notes post. Could save some frustration).

[guest15389]

It would be better to pull this update as it completely breaks the system and makes it unusable since DNS crashes over and over.

opnsense-revert -r 20.7.6 unbound

I was saying to stop pushing a patch that bricks your router.

[alexroz]

Same here.
I updated my opnsense instance to v 20.7.7_1  yesterday.
Today my unbound 1.13.0 crashed, and I can't start it back.
Rollback to unbound 1.12.0 with

Code: [Select]

opnsense-revert -r 20.7.6 unbound command didn't help.
I had no choice but completely disable unbound.
ְAny suggestions for alternative stable local DNS?

[franco]

I was saying to stop pushing a patch that bricks your router.

That's not a reasonable way to describe a choice to update or revert. If Unbound wants 1.13.0 out being the only way to deal with a CVE it should make sure it works. Users need to accept the possibility that this is mostly the case, but not always.


Cheers,
Franco

[guest15389]

I was saying to stop pushing a patch that bricks your router.

That's not a reasonable way to describe a choice to update or revert. If Unbound wants 1.13.0 out being the only way to deal with a CVE it should make sure it works. Users need to accept the possibility that this is mostly the case, but not always.


Cheers,
Franco

If an update breaks a device and makes it not functional and the vendor understands the problem being caused (3rd party or not), they usually remove the broken update so it stops creating more havoc for people since it was not intended to break the device.

[franco]

If an update breaks a device and makes it not functional and the vendor understands the problem being caused (3rd party or not), they usually remove the broken update so it stops creating more havoc for people since it was not intended to break the device.

There is a distinction I think is being missed here: "affects all people" vs. "affects some people".

Also, "break a device" is used opportunistically here. The device isn't bricked. The admin can still do something (if actually necessary, see first point).

Also maybe this is a bit unexpected: there is no clean rollback of published repositories with FreeBSD package manager. It can break your dependency chain worst case, deinstalling the core package leaving the device really really dead in the water. It's not a risk to take vs. first point.

There are more points, but I fear they are not relevant to the desires of the perfect consumer of the perfect project.


Cheers,
Franco

[Archanfel80]

Affected our firewalls too, from 12 of 10. So its pretty much affect almost everyone, not just a few people.
Disabled unbound and using dnsmasq solve the issue.

[lar.hed]

ְAny suggestions for alternative stable local DNS?

I would say DNSCrypt-proxy. That is what I use since I have (other) problems with Unbound (mainly DNSBL and network port going up/down with complete restart of Unbound and as a result DNS outage). However it is not as integrated with OPNsense...