Unbound restarting 20-30 times a day without any reason
-
Added to what is mentioned above :
@Piktor10 said in Unbound restarting 20-30 times a day without any reason:
That is all, I see in the logfiles. No reason, why unbound is restarting so often, nothing about what is causing it.
Has someone any idea?
Knowing what you know now :
read again :
and this is exactly what you see happening.
This is the reason.By default, this option in not checked.
'Then, some one came along, and checked it ..."Take note ; the future replacement of the ISC DHCP, KEA, will also have this functionality, and the DHCP host name will get communicated to unbound (DNS° without a DNS restart.
Until that moment : for all your important 'server type' devices, devices you have to name by host name, us a static DHCP MAC lease.And Check this one :
as this option will not restart unbound, as they are ... static ^^
-
"For me reloading and flushing a resolution cache" was not a synonym for restarting the resolver!
Even, when I was reading that after unchecking, I have not understand this as a warning, that the whole resolver restarts! The only possible delay I saw in this warning, that the resolver can't answer the next queries from its cache, as that was flushed! -
@Piktor10 said in Unbound restarting 20-30 times a day without any reason:
"For me reloading and flushing a resolution cache" was not a synonym for restarting the resolver!
Even, when I was reading that after unchecking, I have not understand this as a warning, that the whole resolver restarts!Actually, unbound is send a reload signal.
A couple of years ago, it was discoverer (open source !) that unbound, upon receiving a 'reload' actually ... restarts. -
@Gertjan Thats, what I figured out now as well. Seeing in the dhcpd.log the HUPs beeing sent.
So I would recommend, to change the wording in the warning to the current behaviour, and write restart instead of reload.Next question: How that shall be fixed by using kea instead of dhcpd? Unbound still needs to get this data, without restarting.
I am also now further, why this happens to my pfSense since some weeks, even when that configuration was in place for years. My network got recently at least 4 mobile devices using new mac addresses for connection, once they were connected anywhere else. They don't remember mac addresses for certain WLANs or router macs. Because of this, I had to throw away static associations for those mobile devices. This is in timely coincidence, to the growing number of restarts.
-
@Piktor10 said in Unbound restarting 20-30 times a day without any reason:
Next question: How that shall be fixed by using kea instead of dhcpd? Unbound still needs to get this data, without restarting.
Believe it or not, after 10+ years of waiting, this is exactly one of the reasons KEA was introduced ! (IMHO)
A couple of weeks ago, a Netgate software développer acknowledged here on this forum that he started the implantation of just this very issue.
Kea that signals unbound the presence of a (new) lease without restarting unbound.@Piktor10 said in Unbound restarting 20-30 times a day without any reason:
My network got recently at least 4 mobile devices using new mac addresses for connection, once they were connected anywhere else. They don't remember mac addresses for certain WLANs or router macs. Because of this, I had to throw away static associations for those mobile devices. This is in timely coincidence, to the growing number of restarts.
Not entirely pfSense's fault.
When, you, the pfSense admin, decides to add a DHCP Static MAC lease, it would be wise to check if the MAC in question is a randomized MAC, or not. The owner of the device should be willing to shut down this randomization on your network. So, see it as a win-win situation, check that randomisation is off. -
@Piktor10 said in Unbound restarting 20-30 times a day without any reason:
Next question: How that shall be fixed by using kea instead of dhcpd? Unbound still needs to get this data, without restarting.
unboundhas a control channel app that can update some parameters without restarting the daemon. But that control channel app needs to be called from within the DHCP server code. Currently the ISC DHCP daemon is not coded to do that. The new Kea DHCP daemon can be modified to do that, and that's what pfSense intends to do. Since the current ISC DHCP daemon will eventually be obsoleted, there is no point to expending developer resources to modify it. Better to put the effort into the replacement product - Kea. -
Some one, and yes, even me, could have taken this https://github.com/NoThrowForwardIt/pfsense-tools/blob/master/pfPorts/dhcpleases/files/dhcpleases.c as a starting point, and rewrite it so it takes in account the "unbound-control" parameters, so things could haven been done 'properly' ages ago.
The actual solution : check if the ISC DHCPd 'dhcpleases' file was changed, and if so, shoot at unbound.
It did pass the KIS test
-
@bmeeks
Curious. I typically run pfSense in small-ish networks is it worth it keeping DHCP Registration enabled? I haven't noticed a performance hit but also the only benefit is knowing what IP is what when i nslookup. -
@michmoor said in Unbound restarting 20-30 times a day without any reason:
@bmeeks
Curious. I typically run pfSense in small-ish networks is it worth it keeping DHCP Registration enabled? I haven't noticed a performance hit but also the only benefit is knowing what IP is what when i nslookup.The decision point would be the number of DHCP clients and thus the number of DHCP lease renewals per interval (say per hour or per day). Each lease renewal results in an
unboundrestart with the current design when "Register DHCP leases in the DNS Resolver" is enabled. Each restart means DNS is unavailable until theunbounddaemon gets back up and running. With a plain vanilla install that can be fairly quick, but if you use DNSBL, then the restart time can be much longer. Even still, enough restarts per time interval can still be very disruptive on a network as you have no DNS for an appreciable interval of time.I, too, like to have my local DHCP clients registered in DNS. Because I have a Windows AD domain internally, I just use that for both DHCP and DNS. My
unboundsetup only resolves for pfSense itself and has a domain override for my AD domain that points back to my AD DNS servers so pfSense can resolve my local LAN hosts.This problem with restarting
unboundis not a good design choice in my view, but it is what it is. I have a pfSense install on an SG-6100 at a local church, and I had to disable the DHCP lease registration option there otherwise DNS became essentially unusable due to the frequent restarts initiated by lease allocations and renewals on the network. -
@bmeeks said in Unbound restarting 20-30 times a day without any reason:
This problem with restarting unbound is not a good design choice in my view, but it is what it is. I have a pfSense install on an SG-6100 at a local church, and I had to disable the DHCP lease registration option there otherwise DNS became essentially unusable due to the frequent restarts initiated by lease allocations and renewals on the network.
how many devices on the network?
-
@michmoor said in Unbound restarting 20-30 times a day without any reason:
how many devices on the network?
There is no universal precise number. It will depend primarily on the DHCP lease time. And then the number of devices comes into play. If you have a DHCP lease time of 1 hour with 1 device on the network,
unboundwould be seeing a restart once every 30 minutes (assuming the single device renewed its lease at the 50% point of the lease duration). Double the number of devices and the restarts could double in that 30 minute window. Depends on how far apart each lease start time was. Say you have 10 devices getting DHCP addresses and they all start up at staggered times. Then each of the 10 would be renewing its lease at a slightly different minute during the 1 hour lease duration. That could result in lots ofunboundrestarts over the hour.Play different scenarios in your head and you can quickly see how this can become more and more of a problem. Of course 1 hour is a ridiculously low lease time, but 4 or 6 hours may not be unheard of for say a Guest Wireless network or some other network where user devices frequently come and go and you don't have a huge scope available.
Run the DHCP lease time up to days and the problem gets smaller but still does not disappear. If at any instance in time
unboundis restarting when a client requests a DNS lookup, that lookup is going to fail. -
@bmeeks
alright alright...i suppose i have to give myself extra work and spin up a separate DNS server at home...But seriously, i do like having all my pieces in one place , one firewall. All depends on the use case.
-
@michmoor said in Unbound restarting 20-30 times a day without any reason:
i have to give myself extra work and spin up a separate DNS server at home...
The situation existed for ... many years.
In a couple of weeks, months, with the next version of pfSense, this will be addressed.I've been using static MAC leases for my devices that I wanted to know by 'name' like printers, NAS etc.
Register DHCP leases in the DNS Resolver" has been set to default value : NOT set.
Never had any DHCP/DNS issues. -
@Gertjan
Oh i was joking when i wrote that. Im not going to do that. haha.Just to show how often the HUP process was bouncing on my system until i turned off DNS registration. The picture below is expanded over 5 days but rest assured it was restarting every few minutes. Small network so no impact but i can see it being a problem with several 100 endpoints.
-
@michmoor said in Unbound restarting 20-30 times a day without any reason:
but i can see it being a problem with several 100 endpoints.
Things will get even better when you 'some' Wifi connected devices that roam among several APs.
DHCP will fire away every x seconds .... and as much unbound restarts.Quickly, unbound is more busy 'restarting' as actually doing 'DNS' for you.
