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.
Hello, I’ve upgraded to the latest Core release (186) but I am still seeing occasional Unbound restarts. They are not as frequent as before and only seem to happen when my windows clients request lease. I can manually trigger wifi on/off on android devices on the network and Unbound will not restart.
I did see on the IPFire blog that the Unbound restart issue should be resolved with Core186. Is there any other configuration changes I need to apply to prevent the Unbound restarts when LAN clients request a DHCP lease?
Unbound restarts still happen every time a lease starts, stops or is renewed. There is a proposed patch from me to reduce the restarts, but it has been superseded by another much better solution. Mine was only a sticky plaster.
Unfortunately the new patch still has an issue which seems easily fixable but development has stalled due to the developer’s priorities. I’d love it to see the light of day.
The problem is based by the communication mechanisms.
Currently the unbound-dhcp-leases-bridge transfers information sampled from dhcpd to config files for unbound, which is directed to reload in case of modifications. The amentioned fixes try to minimize this reload.
The operation reload of unbound generates a restart. It isn’t known why.
There are proposals by @jon and @ms. Main difference is
using another communications channel dhcpd <—> unbound-dhcp-leases-bridge, which signals modifications of the dhcp db immediately
modifications to the unbound db are not made by reload but unbound operations to define or remove DNS records.
This minimizes the restarts to the number necessary.
Unfortunately the unbound local name db not only consists of dhcp leases, but static host definitions also. Therefore it is necessary to examine these parts also.
I’m using the proposal of @ms at the moment. It reduces the restarts nearly to 0. I can monitor this through the update of my RPZ config files ( RPZ is another story ), mainly those with an update period of one day.
The @ms approach has a couple of issues. @jon has bumped into more restarts with it. Also there is a bit of a hole in the logic. See the Bugzilla report, comments 150-154. I have a fix for it, removing some of the startup functions from unbound-dhcp-leases-bridge and running a separate unbound-dhcp-leases program (attached to the bug) before the start or reload of unbound.
It just needs someone to incorporate my file into the patch set and remove some of the code from @ms 's patch. I could produce the massive diff in my own repos, but don’t have the knowledge to break down the patches into smaller diffs, or necessarily know how to put the update into the distro because restarts and stopping of bits will need to be forced during the updates.
Whether @ms nor me demand the new bridge cited in bugzilla is complete and error free.
It just implements @jon 's proposal in the original Python version.
I only saw one mentioning, without examining the reason. As stated before, there are some more unbound restart/reload events.
This shows the flaw in administration of local names.
For example a host can send his name in DHCP communication, the DHCP WUI allows a name specification in the fixed leases definition. Which name is valid and should be announced to unbound in case of different values ( including the empty host name in DHCP REQ/ACK )?
Thinking about it, I am not sure it is particularly safe this way as, if unbound restarts, it will revert to the earlier dhcp-leases.conf which is no longer valid. Possibly my approach was safer, running a separate script on dhcp reload or start.
If unbound restarts, perhaps through user intervention or any other reason, Unbound will read the file that unbound-dhcp-leases-bridge wrote when it started during the dhcpd start up. This could be days earlier and will miss any updates written by unbound-dhcp-leases-bridge to the socket, so anything that has changed since unbound-dhcp-leases-bridge wrote dhcp-leases.conf will be lost as dhcp-leases.conf is only maintained during the unbound-dhcp-leases-bridge leases start and never written to again.
Much safer would be to write dhcp-leases.conf just before unbound starts. This will always pick up the latest picture.
At that point there is no need to write dhcp-leases.conf on dhcpd start in unbound-dhcp-leases-bridge.
To proceed with the current solution where all updates since dhcpd started could be lost due to an unbound restart is, in my opinion, not the right way to go. It has nothing to do with a flaw in administration of local names. The flaw is in the current logic.
), mainly those with an update period of one day.