Just wanted to say thanks OP! I found this thread from an online search engine. I’m re-visiting IPFire after a few years and also noticed Unbound restarting every time a new DHCP lease was given on LAN.
Checking the RFC2136 box, leaving the key values blank, and then clicking “save” resolved the issue for me.
Doing this will not only stop the Unbound restarts, but it will stop DHCP from sending new lease information (IP address & hostname) to the Unbound DNS.
If you use local hostnames to access devices (like https://ipfire.localdomain:444), then this will stop working. If you only use IP addresses, then you will be ok.
Ah! I see what you mean, they are still resolving but not with the specified domain in the DHCP config. I added a secret as shown in the wiki and I’ll re-test.
I don’t recall this being an issue the last time I tried IPFire. I wonder what changed? All my local DNS lookups worked fine and passed the domain name suffix specified in the DHCP server configuration.
Precisely spoken, activating RFC2136 means the unbound-leases-bridge is deactivated and dhcpd itself sends (name, IP) information to DNS server using the RFC2136 protocol.
But unbound doesn’t support RFC2136. Therefore it is necessary to have another DNS server in the network. ( As explained in the wiki article cited )
The restart of unbound is caused by the reload request of unbound-leases-bridge.
An alternative approach is discussed in the dev list and bugzilla.
I must admit the more I read the more confused I get. If I’m understanding Bernhard and Jon’s comments correctly, enabling RFC2136 deactivates the unbound-leases-bridge and will instead require another DNS server on the LAN to send client DNS registrations.
In my case, I’d like to just use IPFire for both local client name DNS resolution and also as a DHCP server for a small LAN. So it seems as though I need to disable RFC2136 and instead go back to using the unbound-leases-bridge?
My question then comes back to this: Will using the unbound-leases-bridge cause Unbound to restart each time a DHCP lease is handed out to a LAN client?
I’m seeing Unbound restart each time a local LAN client renews a DHCP lease from IPFire. In some cases if there are multiple clients that renew their DHCP leases in close succession this will cause a brief outage scenario where unbound temporarily stops serving requests as it is continually restarted. Another issue is that each time Unbound restarts it loses its cache, as a result DNS performance isn’t as good as it could be if Unbound was undisturbed.
I had hoped to keep DNS in place for the local LAN as I do use it for easy access to systems on the LAN but it seems there isn’t an easy option to do this and still have Unbound consistently running without restarts.
I have contributed to Jon’s fix and it is the way to go long term.
Just before that, I worked on a fix to stop unbound restarting and submitted it as a diff for review. It got feedback and amended a couple of times. Unfortunately I’ve heard nothing back for a couple of weeks so don’t know how to progress it any further. You can see the diff at [PATCH] Stop unbound-dhcp-leases-bridge from continually restarting unbound - Development - lists.ipfire.org at the bottom. My fix should be considered as a sticky plaster (band-aid) on the current implementation as it just amends unbound-dhcp-leases-bridge so it does not restart unbound if /etc/unbound/dhcp-leases.conf does not change.
As it is a single file change it is much easier to implement than Jon’s changes so should be relatively easy for anyone to do and revert if they don’t like it. I am not sure if the bug report is the right place to upload it, so I have put a copy at https://www.howitts.co.uk/unbound-dhcp-leases-bridge. You are welcome to it. Jon’s approach is way better long term. and I am running it now after having proved my method.
FWIW unbound should not be losing its cache on restarts. My understanding is that, when it reloads, an option is used to keep the cache.
You could always bump an email thread on the dev mailing list if some time has gone by without a response.
Just keep in mind that things can occur that consume the focus of the devs and a couple that have impacted the recent period are:
There has been a lot of work over the last couple of weeks on the CU185 Testing release from some issues found with the change to Suricata 7. There were also some security issues identified that had to be fixed. The CU185 Testing issues should be at an end now with CU185 coming to release status soon.
There have also been reports occurring of updates to openvpn clients causing existing client connection definitions to stop working that then needed changes to the client configs. Therefore there has been a lot of work to bring the IPFire OpenVPN system from the 2.5.x series to the 2.6.x series and this move requires some significant changes to the IPFire code. This includes aspects such as using cipher negotiation, removing compression options and migrating the subnet methodology so that several deprecated options can be dealt with.
The big challenge here is to make all these changes while making sure that all existing users systems, using older options don’t break but provide a migration path and ensuring that IPFire is able to work with the newer openvpn client versions. This is still ongoing work as it will be a large change.
On top of the above the devs also have to deal with their day jobs so that they can pay their bills.to continue living and have time to work on IPFire.
I understand all this which is why I am being patient. I did bump the thread after a couple of weeks last week (albeit without adding any more to it, Jon), but Ill hang on a bit before bumping it again.