Frequent unbound restarts

Gertjan · Mar 4, 2021, 9:28 AM

@audiaddict said in Frequent unbound restarts:

this is a Ziggo (vodafone) ISP modem that I have no control over really. It's set to bridge.

Then you would be sending them some words like

Geachte support, Is het mogelijk om de lease van iet wat meer dan 60 seconden te krijgen ?

@audiaddict said in Frequent unbound restarts:

Can you confirm by disabling the registering of DNS entries under DNS resolver - this should not cause these DNSresolver restarts?

After answering the same question, some 1000+ forum messages, from the last 2 years or so.
Yes, I can confirm.
This was the issue with 2.4.5-p1.

How 2.5.0 works these days : dono.
I can see it's still HUPped. Maybe its not restarting anymore, but just re reading the config files, and among them, the modified /etc/hosts file that contains (updated) DHCP client IP hostname information.

Cn you imagine what happens if you had a client device that was asking for a new lease every 30 seconds ??
It would totally explode unbound ..... as ir would have to handle the HUP alll the time.

Believe me :
Make static DHCP MAC leases for your devices that need a fixed IP - host name relation.
Un check the option.
Done.

I have de activated that option several years ago.
unbound is rock solid.

edit :

Mar  3 08:43:58 Porsche dhclient[10769]: Cannot open or create pidfile: No such file or directory

isn't good.

jasonArloUser · Mar 4, 2021, 3:22 PM

@gertjan But the issue is this is mis-implemented. No HUP needs to be sent here and if so all that needs to happen is use the command specified above to reload the local zone (the only one which could possibly be affected by DHCP leases). I can't think of a single other product anywhere that has this problem because every other vendor knows how to deal with DHCP leases adding DNS names.

Gertjan · Mar 4, 2021, 3:22 PM

@jasonarlouser said in Frequent unbound restarts:

No HUP needs to be sent here and if so ....

Please check the "vendors" instruction : the ones who make and maintain unbound.
The question is : when is the local /etc/hosts file re read in ?
Or, you might bask : is there another way to communicate a running unbound process the presence of a new local host + IP ? (answer : yes, there is ..... )

Back, in the dark ages, the manual was : look up in the C source code why HUP was needed, and what it does when one is received, etc.
It's time I make this tour again, see how the more recent unbound version behave.
But I'm registering unknown device's DHCP leases any more in my DNS. All the devices I need to contact have chosen host names, and chosen IP's addresses.
Same thing for IPv6.
So, it became a non issue for me.

Anyway, the unbound+DHCP leases thing is an ongoing discussion for a couple of years now.

In the past of pfSense :
dnsmasq was used before, but considered to light - and has no DNSSEC support.
So, unbound came up ... and was choosen.
"bind" might be used, but was often left out as to - far to - big.

jwt · Apr 23, 2021, 4:16 AM

This post is deleted!

jwt · Apr 23, 2021, 4:18 AM

@brad-edmondson said in Frequent unbound restarts:

@lutel Still broken as you can see.

It is actually working in OpnSense, which was previously a pfSense fork but now refactored and based on HardenedBSD rather than FreeBSD.

This aged well.

brad.edmondson · Apr 23, 2021, 3:10 PM

@jwt Sorry, I don't follow.

Are you referencing the wireguard fiasco? Or was there some other news that put this into an updated context? An unbound regression in OpnSense 21.1.5?

On WireGuard, AFAIK OpnSense has a userspace daemon similar to what pfSense has offered for a while, not the in-kernel implementation that was apparently borked and then yanked.

EDIT:
Are you referring to this OpnSense forum post? I think that's isolated as that user had other problems when upgrading w/ unsupported packages (not to say unbound is unsupported, just that theirs seems like a complicated configuration).

To be fair I did suffer from some constant unbound restarts on my own OpnSense box yesterday, but I haven't updated that machine from 21.1.4 to 21.1.5 yet so I'm 99% sure that was down to my toggling the ramdisk option for /var and losing unbound data at reboot. (I had read the option as /var/log ramdisk, which I assumed would have no ill effects. The /var option not so much since it encompasses so much more.)

sotirone · Mar 16, 2022, 8:55 PM

Is there any news on this?

thiasaef · Mar 17, 2022, 2:59 PM

@sotirone still broken.

Gertjan · Mar 17, 2022, 1:12 PM

... or, if you have a couple of minutes :
Create Static DHCP MAC leases for every device you need to know by name and IPv4.
When done; do the magic click in the Unbound resolver settings page, then Save & Apply, and you just unbroke the issue.

thiasaef · Mar 17, 2022, 1:12 PM

@gertjan

https://redmine.pfsense.org/issues/5413 (unfixed in 2.6.0)
https://redmine.pfsense.org/issues/12613 (unfixed in 2.6.0, unless you apply the patch manually)
https://redmine.pfsense.org/issues/12612 (unfixed in 2.6.0, unless you apply the patch manually)

Both patches are half-assed workarounds. Sorry for the harsh words, but it is what it is.

Gertjan · Mar 17, 2022, 1:48 PM

I didn't say the issue(s) do not exist.
I highlighted a workaround. And no need to undo it when things get sorted out.

Btw : when IPv6 takes over, static MAC DHCP becomes even more important.

Issue 12613 : wasn't aware of this one. My main switches, as pfSense, are fed by an UPS. And no one is ripping out cables here.
Issue 12612 : my pfSense uses DHCP on it's WAN interface. But guess what ?! I gave it a static DHCP MAC lease, set up in the OSP router"s settings.
Anyway, both 12613 and 12612 have a click solution now ;)

thiasaef · Mar 17, 2022, 1:54 PM

@gertjan rc.newwanip events also happen when you power cycle devices connected directly to a LAN interface:

/rc.newwanip: rc.newwanip: on (IP address: 192.168.120.30) (interface: LAN[lan]) (real interface: igb1).

Anyway, both 12613 and 12612 have a click solution now ;)

Yes, one that force restarts Unbound, which is the topic of this thread. ;)

Gertjan · Mar 17, 2022, 2:06 PM

Not the topic, I know, but :

@thiasaef said in Frequent unbound restarts:

/rc.newwanip: rc.newwanip: on (IP address: 192.168.120.30) (interface: LAN[lan]) (real interface: igb1).

A rc.newWANip IP event on a LAN interface ?
The WAN is called LAN here ?
ok ....
Something else ?

The the WAN or whatever LAN/OPT/... NIC receives a LINK DOW / LINK UP event, the attached processes have to restart to take into account the new system configuration. That's somewhat logic, right ? And badly enough, that's how unbound is works.
As said earlier, maybe I'm just lucky here, as all implied devices, ISP router, pfSense, switches, are using an UPS so power isn't an issue. So no "LINK DOW / LINK UP" for me.

thiasaef · Mar 17, 2022, 2:15 PM

@gertjan the name of the event is simply misleading. Read https://redmine.pfsense.org/issues/12612 carefully and you will see that I am correct.

the attached processes have to restart

Only if you do not implement it properly. Unbound did not need to be restarted on 2.4.5-p1 with the exact same configuration and it also does not need to be restarted in such a case if you install it on Linux and apply the same configuration there.

So no "LINK DOW / LINK UP" for me.

It's fine that you don't care about the bug, but trying to convince me that link downs on the LAN side are something that shouldn't happen is going nowhere.

Gertjan · Mar 17, 2022, 3:33 PM

@thiasaef I do care. But I'm human, so I care probably a bit more about issues that impact my own installation.

The question exists on the https://www.nlnetlabs.nl support forum to implement the hardware event directly in the unbound process, like bind (named) : no more restarts, interfaces that come and go are dynamically are updated by the the process** itself. Netgate can't (or won't) rewrite unbound for that. And they really can't replace unbound for bind as then they would have to 'support' the entire thing (bind=huge as it is also a domain name server etc)

** if this is even possible. FreeBSD is used here, and known to be pretty secure. Hardware network events can an impact on the system configuration and is thus security related.
If would be a big deal if a WAN interface get attached as a LAN type.
So, the final decision is pushed out of the kernel, to the 'user' - the admin. The admin can decide to keep the interfaces up == no more events.
This is me thinking out loud.

Btw : I'm like you : just another pfSense user.

Anyway : the subject is "Frequent unbound restarts ".
Issue 12613 has a patch.
Issue 12612 has a patch.
Issue 5413 is ongoing, so I dealt with it 'my way'.
The first post from myself about this "5413" issue are dating from 2016 (?), when Netgate/pfSense switched from DNSmasq to unbound. All my networks are small - 50 devices @max that I have to know by name and IP, so I "Static MACced" them all, and disable DHCP Registration.
The latest pfBlocker-devel release also call for this measure :

🔒 Log in to view

and I repeat : disabling this option will stop unbound from being restarted because of DHCP LAN events.

Some solutions have been proposed here : https://redmine.pfsense.org/issues/5413 but, IMHO, one is missing : a python 'DHCP-leases' scripts that reads the DHCP leases file. And also checks the time stamp of the DHCP-leases file, and read it again if a lease was added, disappeared, or got changed. Even with several thousands of DHCP leases, this file will not grow indefinitely (the number of leases is always a known max range).
This python script should also rewrite the /etc/hosts file - as unbound reads it upon restart.

I know it would work, as the entire DNSBL is now based on a python script unbound extension.

It would be a great if some one could find a better solution as what is currently in place :

https://github.com/pfsense/FreeBSD-ports/blob/devel/sysutils/dhcpleases/files/dhcpleases.c line 604 : kill (HUP) unbound upon a DHCP server event.

I'm a (former) 'c' man myself, I can read Python but don't feel up to even experiment with it.

thiasaef · Mar 17, 2022, 4:54 PM

Netgate can't (or won't) rewrite unbound for that.

I agree and I would not whine about it if a) 2.4.5-p1 was suffering from the same issue (which it did not) or if b) it would not work on Linux either (which it does).

I'm a (former) 'c' man myself

Me too, which is why I can smell half-assed bug fixes from miles away.

Whattteva · Oct 24, 2022, 5:00 AM

@thiasaef said in Frequent unbound restarts:

Netgate can't (or won't) rewrite unbound for that.

I agree and I would not whine about it if a) 2.4.5-p1 was suffering from the same issue (which it did not) or if b) it would not work on Linux either (which it does).

Six months ago, I installed pfSense. It seemed pretty solid and for a time, I was a happy camper. And then, I discovered the DHCP lease DNS registration option and the ad blocker. I was so happy because it solved all my problems with having to configure clients manually and it comes in very handy as I have a habit of changing my VM's around on Proxmox all the time. Of course, I started experiencing these mysterious lengthy DNS resolutions and drove me nuts for months.

I call BS on Netgate having to fix Unbound. Last week, I got fed up with it and made the jump to OPNsense. I configured it with the same exact checkbox for DHCP lease DNS registrations and... it doesn't affect Unbound. It doesn't constantly restart and DNS resolutions are now rock solid (no more waiting for 30+ seconds every so often). Clearly, they're doing something right and someone can correct me, but I doubt they're maintaining their own version of Unbound.

I'm a (former) 'c' man myself

Me too, which is why I can smell half-assed bug fixes from miles away.

The fact that this bug has been open since 2017 with no end in sight quite possibly drove me away from pfSense for good.