Unbound seems to be restarting frequently
-
On my hardware at least, this stops Unbound from restarting until a config change is made to DHCP. When the DHCP config change is applied, Unbound gets restarted, and then starts doing the same old restart every hour or less deal, until the pfSense box is rebooted. On a fresh reboot with no config changes Unbound has run for about 15 days without restarting (longest I've gone without a config change lately).
The issue is not in the package, it's in the scripts controlling it. The way the scripts are written now, they insert data into Unbound's config files, then restart the service for Unbound to reload those config files and pull in the changes. Dnsmasq is handled the same way, except it will hold its cache and re-read config files upon getting a SIGHUP.
The right way to handle local DNS changes, for Unbound at least, would basically be to do the opposite of what is being done now. Rather than write to the config files and bounce the service, you would use unbound-control to tell Unbound about the new local DNS changes and let it write the config files.
The code is almost completely written already, all that needs to be done is for someone that knows what to change and has the time to change it, to go through all the Unbound functions and replace config file writes with unbound-control command calls that use almost identical syntax. For example, instead of writing local-data-ptr to a file like this and bouncing the service (how it's done now):
$unbound_entries .= "local-data: \"{$host['fqdn']} {$type} {$host['ipaddr']}\"\n";
You would do something like this and not ever restart the service:
$unbound_cmd .= "unbound-control local_data {$host['fqdn']} {$type} {$host['ipaddr']}";
Same thing with removing local DNS entries, every unbound-control add command has a corresponding remove command, local_data_remove for this example.
If Unbound doesn't write the entries to the config files in case of a user forced service stop / restart, then the code in use now is already maintaining consistency in the config files. Or you could simply re-add all the local DNS records with unbound-control calls on service start. Either way would work fine.
If memory serves, this was a lot of the reasoning behind using Unbound over Dnsmasq. Because Dnsmasq has nothing like unbound-control to insert and remove DNS records, and even make live config changes, without doing a full config reload / service restart. Why this was not carried over to implementation is beyond me. Ask the man upstairs.
Also, clearly, some functions are being called in the wrong place, and this needs to be cleaned up as well. The DHCP register check boxes on the forwarder page should have no effect on the resolver what so ever, but it appears they absolutely do, as noted above. Also, the same DHCP register check boxes on the resolver page seem to only write these items to the Unbound config files without restarting the service, which is only half right the way it is currently implemented (you would expect a service restart to follow). This all needs to be changed to use unbound-control anyways, but should be noted on the fix Unbound to do list with everything else.
Thank you and good night :D
-
The issue is not in the package, it's in the scripts controlling it. The way the scripts are written now, they insert data into Unbound's config files, then restart the service for Unbound to reload those config files and pull in the changes. Dnsmasq is handled the same way, except it will hold its cache and re-read config files upon getting a SIGHUP.
The right way to handle local DNS changes, for Unbound at least, would basically be to do the opposite of what is being done now. Rather than write to the config files and bounce the service, you would use unbound-control to tell Unbound about the new local DNS changes and let it write the config files.
Whilst this sounds promising, have you code read unbound to check what unbound-control local_data and unbound-control local_data_remove actually do? If these commands force a cache flush, then there is no gain and potential losses in your proposed approach. If unbound uses a cache walk to discard affected RR(s), a different potential performance issue arises if this process is blocking, especially if unbound is started with no local RRs and they are added one at a time using unbound-control. If cache discard takes place via a non-blocking cache walk or no cached RR removal takes place, the possibility of race conditions exists, as stale RR data will be served for an indeterminate but potentially significant time.
Rather than using unbound-control to insert all RRs on startup, a hybrid approach is possible - start unbound with the current state in the configuration files, then use unbound-control for subsequent changes.
One complexity in implementing your proposed approach is a frustrating non-orthogonality in the local_data and local_data_remove commands. local_data adds a single RR. local_data_remove removes all RRs for the given name - which might include both A and AAAA records for the same name (and, if local_data_remove for PTR records is called by the name rather than the IP address, this means IPv4 and/or IPv6 PTR records pointing to that name will also be removed). IPv4 and IPv6 address allocation use entirely separate processes that have no guarantees on temporal relationship. There are circumstances where you might want to remove just one RR, which means you have to remove all RRs for the name then re-add any wanted RRs.
If there are advantages to using unbound-control, it might be better to add support for unbound control to pfSense by generating a new unbound configuration as at present, then diffing it with the old configuration. If there are changes solely in local data (i.e. in dhcpleases_entries.conf and/or host_entries.conf), pfSense could use the output of the diff to make appropriate calls to unbound-control, otherwise replace the old configuration with the new and send unbound a SIGHUP. This approach has the advantage of ensuring consistency (for example by ensuring explicitly configured local-data is not accidentally removed) and is easily removed if unbound gets saner SIGHUP behaviour in the future. One implementational complexity is the need to call unbound-control local_data for any explicit local-data and local-data-ptr in unbound.conf after you call unbound-control local_data_remove for the same name.
Another possibility is to use an entirely separate DNS server for local zone(s), defining them in Unbound as stub zones. There is potential advantage here in terms of being able to DNSSEC sign these zones. However, when data changes, stale data would be cached in Unbound that would require carefully targeted calls to unbound-control flush_type or a costly (because of the cache walk) unbound-control flush_zone to remove.
-
The issue is not in the package, it's in the scripts controlling it. The way the scripts are written now, they insert data into Unbound's config files, then restart the service for Unbound to reload those config files and pull in the changes. Dnsmasq is handled the same way, except it will hold its cache and re-read config files upon getting a SIGHUP.
The right way to handle local DNS changes, for Unbound at least, would basically be to do the opposite of what is being done now. Rather than write to the config files and bounce the service, you would use unbound-control to tell Unbound about the new local DNS changes and let it write the config files.
Whilst this sounds promising, have you code read unbound to check what unbound-control local_data and unbound-control local_data_remove actually do? If these commands force a cache flush, then there is no gain and potential losses in your proposed approach. If unbound uses a cache walk to discard affected RR(s), a different potential performance issue arises if this process is blocking, especially if unbound is started with no local RRs and they are added one at a time using unbound-control. If cache discard takes place via a non-blocking cache walk or no cached RR removal takes place, the possibility of race conditions exists, as stale RR data will be served for an indeterminate but potentially significant time.
Answers to all of your questions are in plain text here:
https://www.unbound.net/documentation/unbound-control.htmlNo, but the fact that local add / remove commands only process local data space makes it pretty clear.
No race condition exists. Simply process 1 unbound-control command at a time. unbound-control returns completion. At the rate they execute I would guess even with lots of local custom entries (say 200+), which even the documentation states not to use Unbound on its own as a full hosted DNS solution, this would happen very quickly. Since it would only happen on service start, the impact would be even more who gives a fuck sort of minimal. Ditto for local removals. Cap it off with the "well what if 500+ DHCP client releases happen at the end of the day" answer of "if your pfSense hardware can handle serving 500+ clients all day, it can easily handle removing 500+ local DNS entries quickly".
Rather than using unbound-control to insert all RRs on startup, a hybrid approach is possible - start unbound with the current state in the configuration files, then use unbound-control for subsequent changes.
Yup, I gave that as 1 of 2 possible ways to go.
One complexity in implementing your proposed approach is a frustrating non-orthogonality in the local_data and local_data_remove commands. local_data adds a single RR. local_data_remove removes all RRs for the given name - which might include both A and AAAA records for the same name (and, if local_data_remove for PTR records is called by the name rather than the IP address, this means IPv4 and/or IPv6 PTR records pointing to that name will also be removed). IPv4 and IPv6 address allocation use entirely separate processes that have no guarantees on temporal relationship. There are circumstances where you might want to remove just one RR, which means you have to remove all RRs for the name then re-add any wanted RRs.
Since we are only dealing with local FQDN and localHost.localDomain records, also a non issue. If there are multiple records pointing to the same FQDN / localHost.localDomain and a DHCP event causes them to need removal, now we only need to issue a single unbound-control remove command. If that breaks ANYTHING local DNS wise (it won't), than very very worst case scenario, we continue to bounce the service only on custom static override changes (please don't do this).
If there are advantages to using unbound-control, it might be better to add support for unbound control to pfSense by generating a new unbound configuration as at present, then diffing it with the old configuration. If there are changes solely in local data (i.e. in dhcpleases_entries.conf and/or host_entries.conf), pfSense could use the output of the diff to make appropriate calls to unbound-control, otherwise replace the old configuration with the new and send unbound a SIGHUP. This approach has the advantage of ensuring consistency (for example by ensuring explicitly configured local-data is not accidentally removed) and is easily removed if unbound gets saner SIGHUP behaviour in the future. One implementational complexity is the need to call unbound-control local_data for any explicit local-data and local-data-ptr in unbound.conf after you call unbound-control local_data_remove for the same name.
Yes, to the "somebody with the time needs to test this", I would agree with my own previous post.
No to the rest. You're over thinking it now. Forget SIGHUP for Unbound. Consistency is already being maintained in config files by current code. We need to dump the service restart bullshit, or dump Unbound. Love it or leave it. It will never work correctly if you aren't smart enough to maintain local records without bouncing the service or dumping the non-local cache needlessly.
Another possibility is to use an entirely separate DNS server for local zone(s), defining them in Unbound as stub zones. There is potential advantage here in terms of being able to DNSSEC sign these zones. However, when data changes, stale data would be cached in Unbound that would require carefully targeted calls to unbound-control flush_type or a costly (because of the cache walk) unbound-control flush_zone to remove.
I thought about that, so have others, and some have implemented it, it's not hard with current RELEASE stock packages. Use dnsmasq for local DNS, add domain overrides to Unbound to point to dnsmasq's local custom port. Domain overrides bypass Unbound's cache, so removing stale entries is a non-issue. The issue here is that it is not the right solution. It's an unnecessary workaround at best, and that's not what anyone wants to see time spent on. We would rather see time spent on correct implementation.
For the same reason, completely forget about commands issuing full cache walks too. Even on fast hardware, churning through a potential 1GB of tables, even in RAM, is just stupid when you have the option of not ever doing that.
Edit: Added considerations for pfSense hardware capacity & localHost.localDomain scenario. No methods changed.
-
Is it just me who's finding similar masturbation absurd? Why not fix the braindead SIGHUP handling instead?
-
Because if you had thought it through you would realize there's nothing to fix as far as Unbound itself goes. The design of Unbound is to not need absurd (old) things like custom SIGHUP handling because it has something far more versatile, unbound-control.
unbound-control is Unbound's SIGHUP replacement, just infinitely more useful, since you can feed it parameters and get success / failure returns. Far more securely and gracefully at that.
RTFM my friend.
To repeat again, and again, Unbound was picked for this reason. If the devs now regret that decision because they are stuck on using replaced for a good reason functions like throwing SIGHUP's all over the place, they should pick something older and worse than Unbound as the resolver.
And that would be sad, because Unbound is a GREAT caching DNS resolver when you use it correctly.
-
Is it just me who's finding similar masturbation absurd? Why not fix the braindead SIGHUP handling instead?
Because that would itself be absurd.
You are the master of solutions to problems that should never have existed in the first place. If I ever score a "paid by the line" coding position you are my first hire.
-
-
P.S. As for hires - not interested, thanks. ::)
Oh don't worry, I refuse pay by line type jobs. And all of my clients prefer dealing with people who know what they're doing. That was the point, but you missed it.
Don't forget, last time we did this, as soon as someone who knew what they were talking about finally chimed in, I believe it was something to the tune of "I think you are spot on here". Yup, it was.
As far as helping you, I think this is a good start:
http://www.goodtherapy.org/therapy-for-control-issues.html -
Perhaps, can you send me further personal shit, hire offers and shrink doctor recommendations via PM? It will get safely ignored there; plus it won't produce useless noise for other forum users here that noone's interested in reading.
Alternatively, just STFU and start coding.
-
Perhaps, can you send me further personal shit, hire offers and shrink doctor recommendations via PM? It will get safely ignored there; plus it won't produce useless noise for other forum users here that noone's interested in reading.
Alternatively, just STFU and start coding.
Because God forbid anyone else actually realize what a fucktard you are, right?
Ohhh, did you bump your head? Take your own advice there kiddo.
If you want to be a "I don't understand this so I'm going to troll and shit all over it" dick, on a non-technical and personal level, publicly. Then I will continue to hand you your ass, publicly. Perhaps your masturbation comment (really all of your comments) are more appropriate as a PM, since they do indeed fit your "useless noise for other forum users here that noone's interested in reading" category.
And again with the control issues. Seriously, get help. Your attitude is one only a mother on heroine could love.
-
Lick my swamp.
-
Snappy comeback.
-
Bug opened: https://redmine.pfsense.org/issues/5413
-
-
How many people having this issue are using a config that used to use the forwarder rather than the resolver? And how many of those people still have the top 3 DHCP options checked in the forwarder, even though the forwarder is disabled?
If this is the case, humor me here… go to the DNS forwarder page, check the top enable box to enable access to the 3 DHCP options boxes below it, uncheck all 3 DHCP options boxes, then uncheck the top enable box (so we don't unwantingly enable the forwarder), click the save button, verify that all 3 DHCP options boxes for the forwarder are now unchecked and disabled once the page reloads, and reboot pfSense for sanity.
Please post back as to what effect this has on Unbound reloads… either the same, less frequently, or eliminates them all together.
For me this stopped the repeated "unbound: service stopped", "unbound: start of service" messages 2-3 times per minute. Thanks - this was a longstanding issue.
It fit because this installation was previously dnsmasq, switched to unbound some time ago.
Specifically, the relevant part of the config export looked like this before:
<dnsmasq><regdhcpstatic><custom_options><domain_needed><no_private_reverse><interface></interface></no_private_reverse></domain_needed></custom_options></regdhcpstatic></dnsmasq>
and like this after:
<dnsmasq><custom_options><domain_needed><no_private_reverse><interface></interface></no_private_reverse></domain_needed></custom_options></dnsmasq>
It also took a reboot.
A more subtle issue for me is that machines seem to lose DNS resolution (maybe all connectivity?) for about 5 seconds every time their DHCP lease expires and is renewed. For now I've just lengthened DHCP leases significantly - they were short for testing. Separate issue I guess.
-
I had to go back to DNS Forwarder (dnsmasq) because of this. Thank God it's still inthere and only a checkbox away.
-
I know a bug report is not really the place for arguing about the merits of a solution, but I respectfully maintain some of my caution in https://forum.pfsense.org/index.php?topic=89589.msg568394#msg568394 , especially in relation to ky41083's assertion that there is no need ever to restart Unbound.
Changes in local-data can be handled via unbound-control as ky41083 says - though the inability to remove just the A or AAAA record will likely require some care, as both can exist for the same local host and there is no guaranteed temporal relationship between changes in A and AAAA. In particular, DHCP and DHCPv6 are entirely separate and not synchronous.
Unlike ky41083, I cannot see any alternative to restarting Unbound if there are configuration changes made to Unbound beyond changes to local data, as SIGHUP and unbound-control reload unfortunately amount to a reload at present (i.e. cache flush and re-read of the configuration files). unbound-control does not allow for on-the-fly reconfiguration of all aspects of Unbound. This is why I suggested a diff based approach on the forums as one possibility.
These are, of course, implementation points. I agree that Unbound should be reconfigured on-the-fly whenever possible. In time, I hope that Unbound will get saner SIGHUP handling, but this will likely be a lot of work.
Unfortunately, I have no time to work on this issue at present.
You are under thinking the problem and over thinking the solution.
Quickly now…
DHCPv4 & DHCPv6 are entirely separate and not synchronous, agreed. DNS records are only removed when a lease expires, right? How many milliseconds do you think will differ between v4 and v6 leases being obtained by the same host? So deleting just the A or just the AAAA record, vs removing them both at the same time, matters how much, in the real world? Milliseconds, that you can no longer resolve an internal host via DNS, which has been off for (DHCP lease period) anyhow.
If this causes issues for you, make your DHCPv4 & DHCPv6 lease expiration times identical, or fix your DHCP clients that aren't requesting v4 and v6 leases at the same time for who knows why.
If this is causing internal host overrides to be removed, you're putting persistent local host DNS records in the wrong place. DNS is where you put external DNS redirects. DHCP reservations is where you put persistent local host DNS records so they never get removed.
Please, I would love a correct list of things that cannot be changed without restarting Unbound, from someone that's not me.
-
This solved it for me:
https://forum.pfsense.org/index.php?topic=102470.msg578573#msg578573
- John -
Ring a ding ding same here.
Though I had track disabled, I had to just completely disable IPv6 in sys/adv/networking. -
This solved it for me:
https://forum.pfsense.org/index.php?topic=102470.msg578573#msg578573
- John -
Ring a ding ding same here.
Though I had track disabled, I had to just completely disable IPv6 in sys/adv/networking.There is an issue in Unbound, I will have to disable DNSBL so that there is no "server:include: /var/unbound/pfb_dnsbl.conf" in Unbound custom options window.
see my posts: https://forum.pfsense.org/index.php?topic=113193.0 and https://forum.pfsense.org/index.php?topic=114277.0
so far no response from pfSense Dev teams.
-
I also have found unbound is restarted whenever wan ipv6 is renewed on dhcp6.
so First this occurs
/rc.newwanipv6: rc.newwanipv6:
then gateway etc. been set
After this occurscheck_reload_status Reloading filter
At same time in resolver log unbound is restarted.
Now with only small dnsbl lists loaded in pfblockerng this is not a major issue as I have found even uncached queries on my pfsense box are faster than when I used the asus ac68 as my router, however each unbound restart does also have to process the dnsbl lists which is a slow process if I have large lists loaded.
I will look at the pfsense code and see if I can submit a fix that will be accepted, its probably easy to hack this like someone did earlier in the thread but ideally a clean solution would be found that can be accepted as a improvement, since there is no need to restart unbound just for renewing the same ipv6 prefix.
using"SECOIT GmbH" code, is ok but I think will stop unbound been reloaded when dnsbl gets updated daily on my box, so instead I commented out a line in rc.newwanipv6 which forces a unbound restart. Later after sleep I will look into only skipping the unbound restart in rc.newwanipv6 when its not on bootup and when the actual ipv6 on the pfsense box has not changed, so in other words add a check to see if the new ipv6 matches the previous, if it does skip the reload.
-
I have WAN and LAN IPv6 both static and I am also affected by it.
-
For 2.3.x users without DNSBL active, this fixes everything. Someone could easily make a diff patch for DNSBL based on it as well:
https://forum.pfsense.org/index.php?topic=119467.msg661037#msg661037 -
hi, same problem. IPv6 every 15 minutes starts unbound and with dnsbl it tooks a long time..
ky41083, your link doesn't work, same here https://redmine.pfsense.org/issues/5413
Any solution? cache or not is not realy the problem, no answer is what I get.
pfadmin
-
+1 I am affected by this as well. Whenever the DHCP logs show "Sending HUP signal to dns daemon(17620)" the DNS logs show that unbound has reset.
-
+1 I am affected by this as well. Whenever the DHCP logs show "Sending HUP signal to dns daemon(17620)" the DNS logs show that unbound has reset.
+1. Same problem for me too. I was using using DHCP on my Windows Server originally without problem but have now since switched to using pfSense for DHCP as the layout and customization is better suited to my liking. Since changing, I have noticed Unbound stopping from DHCP interfering with it like you say and others here have said. I took some screen shots of the logs too if it could be of assistance.
I also use pfBlockerNG with DNSBL also.
Cheers.
[Edit: Unchecking Register DHCP leases in the DNS Resolver appears to have resolved it for me. Leaving the static mappings checked seems to be fine so far though, I'll report back later otherwise.]
-
+1 i have the same issue now since a couple of days without changing anything! Running on 2.4.2-DEVELOPMENT because i need the PPPOE Vlan Tag functionality which is not working with the latest stable.
Nov 15 14:32:17 unbound 58529:0 info: start of service (unbound 1.6.6). Nov 15 14:32:17 unbound 58529:0 notice: init module 1: iterator Nov 15 14:32:17 unbound 58529:0 notice: init module 0: validator Nov 15 14:32:17 unbound 58529:0 notice: Restart of unbound 1.6.6. Nov 15 14:32:17 unbound 58529:0 info: server stats for thread 1: requestlist max 0 avg 0 exceeded 0 jostled 0 Nov 15 14:32:17 unbound 58529:0 info: server stats for thread 1: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting Nov 15 14:32:17 unbound 58529:0 info: server stats for thread 0: requestlist max 0 avg 0 exceeded 0 jostled 0 Nov 15 14:32:17 unbound 58529:0 info: server stats for thread 0: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting Nov 15 14:32:17 unbound 58529:0 info: service stopped (unbound 1.6.6). Nov 15 14:32:17 unbound 58529:0 info: start of service (unbound 1.6.6). Nov 15 14:32:17 unbound 58529:0 notice: init module 1: iterator Nov 15 14:32:17 unbound 58529:0 notice: init module 0: validator Nov 15 14:32:14 unbound 15323:0 info: 0.065536 0.131072 3 Nov 15 14:32:14 unbound 15323:0 info: 0.016384 0.032768 1 Nov 15 14:32:14 unbound 15323:0 info: lower(secs) upper(secs) recursions Nov 15 14:32:14 unbound 15323:0 info: [25%]=0.032768 median[50%]=0.0873813 [75%]=0.109227 Nov 15 14:32:14 unbound 15323:0 info: histogram of recursion processing times Nov 15 14:32:14 unbound 15323:0 info: average recursion processing time 0.067271 sec Nov 15 14:32:14 unbound 15323:0 info: server stats for thread 1: requestlist max 1 avg 0.25 exceeded 0 jostled 0 Nov 15 14:32:14 unbound 15323:0 info: server stats for thread 1: 4 queries, 0 answers from cache, 4 recursions, 0 prefetch, 0 rejected by ip ratelimiting Nov 15 14:32:14 unbound 15323:0 info: 0.065536 0.131072 1 Nov 15 14:32:14 unbound 15323:0 info: lower(secs) upper(secs) recursions Nov 15 14:32:14 unbound 15323:0 info: [25%]=0 median[50%]=0 [75%]=0 Nov 15 14:32:14 unbound 15323:0 info: histogram of recursion processing times Nov 15 14:32:14 unbound 15323:0 info: average recursion processing time 0.081054 sec Nov 15 14:32:14 unbound 15323:0 info: server stats for thread 0: requestlist max 0 avg 0 exceeded 0 jostled 0 Nov 15 14:32:14 unbound 15323:0 info: server stats for thread 0: 1 queries, 0 answers from cache, 1 recursions, 0 prefetch, 0 rejected by ip ratelimiting Nov 15 14:32:14 unbound 15323:0 info: service stopped (unbound 1.6.6). Nov 15 14:32:11 unbound 15323:0 info: start of service (unbound 1.6.6). Nov 15 14:32:11 unbound 15323:0 notice: init module 1: iterator Nov 15 14:32:11 unbound 15323:0 notice: init module 0: validator Nov 15 14:32:11 unbound 15323:0 notice: Restart of unbound 1.6.6. Nov 15 14:32:11 unbound 15323:0 info: server stats for thread 1: requestlist max 0 avg 0 exceeded 0 jostled 0 Nov 15 14:32:11 unbound 15323:0 info: server stats for thread 1: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting Nov 15 14:32:11 unbound 15323:0 info: server stats for thread 0: requestlist max 0 avg 0 exceeded 0 jostled 0 Nov 15 14:32:11 unbound 15323:0 info: server stats for thread 0: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting Nov 15 14:32:11 unbound 15323:0 info: service stopped (unbound 1.6.6). Nov 15 14:32:11 unbound 15323:0 info: start of service (unbound 1.6.6). Nov 15 14:32:11 unbound 15323:0 notice: init module 1: iterator Nov 15 14:32:11 unbound 15323:0 notice: init module 0: validator Nov 15 14:32:08 unbound 83784:0 info: 0.131072 0.262144 1 Nov 15 14:32:08 unbound 83784:0 info: 0.065536 0.131072 1 Nov 15 14:32:08 unbound 83784:0 info: 0.016384 0.032768 2 Nov 15 14:32:08 unbound 83784:0 info: 0.001024 0.002048 1 Nov 15 14:32:08 unbound 83784:0 info: lower(secs) upper(secs) recursions Nov 15 14:32:08 unbound 83784:0 info: [25%]=0.018432 median[50%]=0.028672 [75%]=0.114688 Nov 15 14:32:08 unbound 83784:0 info: histogram of recursion processing times Nov 15 14:32:08 unbound 83784:0 info: average recursion processing time 0.062189 sec Nov 15 14:32:08 unbound 83784:0 info: server stats for thread 1: requestlist max 2 avg 0.666667 exceeded 0 jostled 0 Nov 15 14:32:08 unbound 83784:0 info: server stats for thread 1: 6 queries, 0 answers from cache, 6 recursions, 0 prefetch, 0 rejected by ip ratelimiting Nov 15 14:32:08 unbound 83784:0 info: 1.000000 2.000000 1 Nov 15 14:32:08 unbound 83784:0 info: 0.524288 1.000000 1 Nov 15 14:32:08 unbound 83784:0 info: 0.131072 0.262144 1 Nov 15 14:32:08 unbound 83784:0 info: 0.008192 0.016384 1 Nov 15 14:32:08 unbound 83784:0 info: lower(secs) upper(secs) recursions Nov 15 14:32:08 unbound 83784:0 info: [25%]=0.016384 median[50%]=0.262144 [75%]=1 Nov 15 14:32:08 unbound 83784:0 info: histogram of recursion processing times Nov 15 14:32:08 unbound 83784:0 info: average recursion processing time 0.753388 sec Nov 15 14:32:08 unbound 83784:0 info: server stats for thread 0: requestlist max 3 avg 1.25 exceeded 0 jostled 0 Nov 15 14:32:08 unbound 83784:0 info: server stats for thread 0: 5 queries, 1 answers from cache, 4 recursions, 0 prefetch, 0 rejected by ip ratelimiting Nov 15 14:32:08 unbound 83784:0 info: service stopped (unbound 1.6.6). Nov 15 14:32:05 unbound 83784:0 info: start of service (unbound 1.6.6). Nov 15 14:32:05 unbound 83784:0 notice: init module 1: iterator Nov 15 14:32:05 unbound 83784:0 notice: init module 0: validator Nov 15 14:32:05 unbound 83784:0 notice: Restart of unbound 1.6.6. Nov 15 14:32:05 unbound 83784:0 info: server stats for thread 1: requestlist max 0 avg 0 exceeded 0 jostled 0 Nov 15 14:32:05 unbound 83784:0 info: server stats for thread 1: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting Nov 15 14:32:05 unbound 83784:0 info: server stats for thread 0: requestlist max 0 avg 0 exceeded 0 jostled 0 Nov 15 14:32:05 unbound 83784:0 info: server stats for thread 0: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting Nov 15 14:32:05 unbound 83784:0 info: service stopped (unbound 1.6.6). Nov 15 14:32:05 unbound 83784:0 info: start of service (unbound 1.6.6). Nov 15 14:32:05 unbound 83784:0 notice: init module 1: iterator Nov 15 14:32:05 unbound 83784:0 notice: init module 0: validator Nov 15 14:32:02 unbound 39724:0 info: 0.008192 0.016384 1 Nov 15 14:32:02 unbound 39724:0 info: lower(secs) upper(secs) recursions Nov 15 14:32:02 unbound 39724:0 info: [25%]=0 median[50%]=0 [75%]=0 Nov 15 14:32:02 unbound 39724:0 info: histogram of recursion processing times Nov 15 14:32:02 unbound 39724:0 info: average recursion processing time 0.011720 sec Nov 15 14:32:02 unbound 39724:0 info: server stats for thread 1: requestlist max 0 avg 0 exceeded 0 jostled 0 Nov 15 14:32:02 unbound 39724:0 info: server stats for thread 1: 4 queries, 2 answers from cache, 2 recursions, 0 prefetch, 0 rejected by ip ratelimiting Nov 15 14:32:02 unbound 39724:0 info: 0.131072 0.262144 1 Nov 15 14:32:02 unbound 39724:0 info: lower(secs) upper(secs) recursions Nov 15 14:32:02 unbound 39724:0 info: [25%]=0 median[50%]=0 [75%]=0 Nov 15 14:32:02 unbound 39724:0 info: histogram of recursion processing times Nov 15 14:32:02 unbound 39724:0 info: average recursion processing time 0.152199 sec Nov 15 14:32:02 unbound 39724:0 info: server stats for thread 0: requestlist max 0 avg 0 exceeded 0 jostled 0 Nov 15 14:32:02 unbound 39724:0 info: server stats for thread 0: 2 queries, 0 answers from cache, 2 recursions, 0 prefetch, 0 rejected by ip ratelimiting Nov 15 14:32:02 unbound 39724:0 info: service stopped (unbound 1.6.6). Nov 15 14:31:59 unbound 39724:0 info: failed to prime trust anchor -- DNSKEY rrset is not secure . DNSKEY IN Nov 15 14:31:59 unbound 39724:0 info: start of service (unbound 1.6.6). Nov 15 14:31:59 unbound 39724:0 notice: init module 1: iterator Nov 15 14:31:59 unbound 39724:0 notice: init module 0: validator Nov 15 14:31:59 unbound 39724:0 notice: Restart of unbound 1.6.6. Nov 15 14:31:59 unbound 39724:0 info: server stats for thread 1: requestlist max 0 avg 0 exceeded 0 jostled 0 Nov 15 14:31:59 unbound 39724:0 info: server stats for thread 1: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting Nov 15 14:31:59 unbound 39724:0 info: server stats for thread 0: requestlist max 0 avg 0 exceeded 0 jostled 0 Nov 15 14:31:59 unbound 39724:0 info: server stats for thread 0: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting Nov 15 14:31:59 unbound 39724:0 info: service stopped (unbound 1.6.6). Nov 15 14:31:59 unbound 39724:0 info: start of service (unbound 1.6.6). Nov 15 14:31:59 unbound 39724:0 notice: init module 1: iterator
-
Similar issue on 2.4.1. already posted in pfblocker forum as i thought the error occurres from that side.
Nov 14 23:03:28 unbound 45240:0 info: start of service (unbound 1.6.6). Nov 14 23:02:57 unbound 45240:0 info: service stopped (unbound 1.6.6). Nov 14 23:02:57 unbound 45240:0 info: start of service (unbound 1.6.6). Nov 14 23:02:25 unbound 45240:0 info: service stopped (unbound 1.6.6). Nov 14 23:00:08 filterdns adding entry 2a02:26f0:6a:280::3d5 to pf table certbot for host acme-v01.api.letsencrypt.org Nov 14 23:00:08 filterdns adding entry 2a02:26f0:6a:293::3d5 to pf table certbot for host acme-v01.api.letsencrypt.org Nov 14 23:00:08 filterdns adding entry 104.74.107.171 to pf table certbot for host acme-v01.api.letsencrypt.org
-
are there any further investigations?
do you need more information/ logs? -
Similar issue on 2.4.1. already posted in pfblocker forum as i thought the error occurres from that side.
Nov 14 23:03:28 unbound 45240:0 info: start of service (unbound 1.6.6). Nov 14 23:02:57 unbound 45240:0 info: service stopped (unbound 1.6.6). Nov 14 23:02:57 unbound 45240:0 info: start of service (unbound 1.6.6). Nov 14 23:02:25 unbound 45240:0 info: service stopped (unbound 1.6.6). Nov 14 23:00:08 filterdns adding entry 2a02:26f0:6a:280::3d5 to pf table certbot for host acme-v01.api.letsencrypt.org Nov 14 23:00:08 filterdns adding entry 2a02:26f0:6a:293::3d5 to pf table certbot for host acme-v01.api.letsencrypt.org Nov 14 23:00:08 filterdns adding entry 104.74.107.171 to pf table certbot for host acme-v01.api.letsencrypt.org
Exact same issue here. Im on version 2.4.2.
It is solved when disabling DHCP registrations in DNS.
-
Please help! PfSense makes my internet unusable :(
Nov 18 10:58:23 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 10:57:51 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 10:47:31 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 10:47:00 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 10:47:00 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 10:46:28 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 10:41:26 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 10:40:55 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 10:31:13 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 10:30:42 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 10:27:40 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 10:27:08 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 10:12:35 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 10:12:04 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 10:10:21 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 10:09:49 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 10:09:08 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 10:08:37 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 10:02:36 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 10:02:05 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 10:02:05 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 10:01:33 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 09:47:30 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 09:46:59 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 09:46:59 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 09:46:27 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 09:31:13 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 09:30:42 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 09:30:03 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 09:29:32 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 09:16:18 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 09:15:47 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 09:14:59 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 09:14:27 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 09:12:44 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 09:12:12 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 09:11:02 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 09:10:30 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 09:02:33 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 09:02:02 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 09:02:02 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 09:01:30 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 08:47:29 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 08:46:58 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 08:46:58 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 08:46:26 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 08:31:13 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 08:30:42 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 08:24:07 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 08:23:36 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 08:20:02 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 08:19:31 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 08:19:26 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 08:18:55 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 08:17:22 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 08:16:51 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 08:15:07 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 08:14:36 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 08:02:30 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 08:01:59 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 08:01:59 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 08:01:27 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 07:47:28 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 07:46:57 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 07:46:57 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 07:46:25 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 07:34:07 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 07:33:36 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 07:31:13 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 07:30:42 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 07:25:38 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 07:25:07 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 07:21:50 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 07:21:19 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 07:19:46 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 07:19:14 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 07:17:31 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 07:16:59 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 07:02:27 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 07:01:56 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 07:01:56 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 07:01:25 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 06:55:00 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 06:54:28 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 06:46:56 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 06:46:24 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 06:43:53 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 06:43:22 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 06:43:22 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 06:42:51 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 06:31:13 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 06:30:41 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 06:24:14 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 06:23:42 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 06:22:09 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 06:21:37 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 06:19:54 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 06:19:23 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 06:02:24 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 06:01:53 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 06:01:53 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 06:01:22 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 05:47:26 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 05:46:55 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 05:46:55 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 05:46:23 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 05:43:33 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 05:43:02 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 05:41:43 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 05:41:11 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 05:31:44 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 05:31:12 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 05:31:12 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 05:30:41 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 05:26:36 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 05:26:04 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 05:24:32 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 05:24:01 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 05:22:18 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 05:21:46 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 05:02:21 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 05:01:50 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 05:01:50 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 05:01:19 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 04:46:54 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 04:46:22 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 04:44:23 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 04:43:52 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 04:31:12 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 04:30:41 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 04:29:30 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 04:28:59 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 04:28:59 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 04:28:28 unbound 41920:0 info: service stopped (unbound 1.6.6). Nov 18 04:26:56 unbound 41920:0 info: start of service (unbound 1.6.6). Nov 18 04:26:24 unbound 41920:0 info: service stopped (unbound 1.6.6).
-
At the risk of necroposting, here is a related bug for unbound [1] and related merge request [2].
[1] https://redmine.pfsense.org/issues/5413
[2] https://github.com/pfsense/FreeBSD-ports/pull/751 -
This issue is causing issues on my fairly new deployment. I'd call it a deal-breaker had I found it sooner.
Does anyone have any insight as to whether it will be fixed or not?
s
-
Fixed :
!
-
@gertjan said in Unbound seems to be restarting frequently:
Fixed :
!
How is that fixed? It is still HUPping the resolver, and flushing the cache.
s
-
@swixo said in Unbound seems to be restarting frequently:
@gertjan said in Unbound seems to be restarting frequently:
Fixed :
!
How is that fixed? It is still HUPping the resolver, and flushing the cache.
s
Usually, it is the renewal of DHCP leases which results in the DHCP service restarting
unbound
(the DNS resolver, or forwarder, if using forwarding mode) so that it will reload its database of hostname/IP pairs. Unchecking that box prevents DHCP from registering the hosts' new leases with DNS. That, in turn, meansunbound
does not get restarted frequently.,Another source of frequent
unbound
restarts is using the pfBlockerNG-devel package and its DNSBL feature. This is especially true with the new Python module integration. This setup can give the same symptoms as the DHCP leases scenario described above.I will not disagree that there are better ways to fix this -- namely patching the DHCP system so that it uses the
unbound
control app to selectively load domains instead of flushing the entire cache and starting over with everything as it does now. But unless and until the pfSense developer team makes a change, the only two known solutions are to turn off the "Register DHCP leases in the DNS Resolver" option, and/or stop using the features of pfBlockerNG-devel that fiddle withunbound
and frequently restart it. -
@bmeeks said in Unbound seems to be restarting frequently:
@swixo said in Unbound seems to be restarting frequently:
@gertjan said in Unbound seems to be restarting frequently:
Fixed :
!
How is that fixed? It is still HUPping the resolver, and flushing the cache.
s
Usually, it is the renewal of DHCP leases which results in the DHCP service restarting
unbound
(the DNS resolver, or forwarder, if using forwarding mode) so that it will reload its database of hostname/IP pairs. Unchecking that box prevents DHCP from registering the hosts' new leases with DNS. That, in turn, meansunbound
does not get restarted frequently.,Another source of frequent
unbound
restarts is using the pfBlockerNG-devel package and its DNSBL feature. This is especially true with the new Python module integration. This setup can give the same symptoms as the DHCP leases scenario described above.I will not disagree that there are better ways to fix this -- namely patching the DHCP system so that it uses the
unbound
control app to selectively load domains instead of flushing the entire cache and starting over with everything as it does now. But unless and until the pfSense developer team makes a change, the only two known solutions are to turn off the "Register DHCP leases in the DNS Resolver" option, and/or stop using the features of pfBlockerNG-devel that fiddle withunbound
and frequently restart it.Right. We don't disagree. I understand that NOT registering local hosts from DHCP makes it not happen. But thats pretty 1990. Registering local hosts is very convenient and should work. And work without purging the DNS cache - by HUPping the deamon and restarting it.
I have been trying to find some subtle DNS failures and I have traced it to times when resolver is killed/restarting. It also occasionally leads to other small problems that would be considered annoyances.
It's a surprise that so much of this community is happy to just disable an important feature like registering DHCP leases with DNS and defend the practice because it fixes an other issue.
s
-
@swixo said in Unbound seems to be restarting frequently:
@bmeeks said in Unbound seems to be restarting frequently:
@swixo said in Unbound seems to be restarting frequently:
@gertjan said in Unbound seems to be restarting frequently:
Fixed :
!
How is that fixed? It is still HUPping the resolver, and flushing the cache.
s
Usually, it is the renewal of DHCP leases which results in the DHCP service restarting
unbound
(the DNS resolver, or forwarder, if using forwarding mode) so that it will reload its database of hostname/IP pairs. Unchecking that box prevents DHCP from registering the hosts' new leases with DNS. That, in turn, meansunbound
does not get restarted frequently.,Another source of frequent
unbound
restarts is using the pfBlockerNG-devel package and its DNSBL feature. This is especially true with the new Python module integration. This setup can give the same symptoms as the DHCP leases scenario described above.I will not disagree that there are better ways to fix this -- namely patching the DHCP system so that it uses the
unbound
control app to selectively load domains instead of flushing the entire cache and starting over with everything as it does now. But unless and until the pfSense developer team makes a change, the only two known solutions are to turn off the "Register DHCP leases in the DNS Resolver" option, and/or stop using the features of pfBlockerNG-devel that fiddle withunbound
and frequently restart it.Right. We don't disagree. I understand that NOT registering local hosts from DHCP makes it not happen. But thats pretty 1990. Registering local hosts is very convenient and should work. And work without purging the DNS cache - by HUPping the deamon and restarting it.
I have been trying to find some subtle DNS failures and I have traced it to times when resolver is killed/restarting. It also occasionally leads to other small problems that would be considered annoyances.
It's a surprise that so much of this community is happy to just disable an important feature like registering DHCP leases with DNS and defend the practice because it fixes an other issue.
s
Yeah, I'm not trying to defend the situation. I'm not impacted by it because I use Windows AD for DHCP and DNS. Just making sure you understood the two most likely causes and a solution (although certainly it's not a optimum one). You and I may be among the minority here, though, with regards to the importance of DNS working with DHCP clients. The view of many here is you just use static IP addresses with DHCP reservations, and update the DNS Resolver accordingly. I'm definitely not in that camp, especially for a larger business network where it is much easier to use DHCP "freestyle" and have it register hostnames for you in DNS.
Unbound itself also has an issue. The latest release of pfSense rolled back
unbound
to an earlier version to correct an issue with random segfaults. -
You and I may be among the minority here, though, with regards to the importance of DNS working with DHCP clients. The view of many here is you just use static IP addresses with DHCP reservations, and update the DNS Resolver accordingly.
I used to do this to. Thirty years ago. It is much better to have local DHCP hosts registered. ESPECIALLY if you have multiple sites and tunnels between them.
-
Switching of dhcpleases, the process that parses the DHCP leases list, and HUPs unbound, is, I totally agree, just a band aide.
But unbound doesn't work like, for example, bind (named) who is capable of re reading some file, and dealing with the changes on the fly, without completely restarting.
Btw @bmeeks, I'm using pfBlocker(latest) and its using unbound-control to 'inject' DNSBL changes. When pfBlocker found an updated DNSBL list, it parses out the changes, and communicates them to unbound.
For me, unbound restarts ones or twice a week, and even these restarts do not loose the DNS cache, as it is dump before the stop, and read back in when it restarts. That is, if pfBlocker was restarting it.The thing is : unbound does the job, and is small enough - bind, with all it dependency, is huge, as it has much more capabilities.
It was working well, in the past, even with big networks connected to pfSense : devices do not tend to renew their lease every 5 minutes or so. But then some smart guy came allong and thought : hey, what if we feed unbound with host names that we want to short cut to ground ?
Big, no, huge DNSBL lists were build, and unbound needed a lot more time to start. People started to detect DNS outages.pfSense doesn't control unbound, as it is an entire open source project of it's own. I never understood why unbound doesn't have some interface with ISC DHCP, the DHCP server used by pfSense.
It seems rather logic that on a device that has a resolver like unbound, their could also be a DHCP server, thus there are leases for the local devices, who wanted to have their host names registered in the local DNS.dhcpleases should be rewritten to use unbound-control, instead of detecting a new lease, writing it to one of the files that unbound reads on start, and then pulling the trigger on unbound.
Keep in mind that other events can also restart unbound, such as interfaces that go up and down, etc.
-
@gertjan said in Unbound seems to be restarting frequently:
Btw @bmeeks, I'm using pfBlocker(latest) and its using unbound-control to 'inject' DNSBL changes. When pfBlocker found an updated DNSBL list, it parses out the changes, and communicates them to unbound.
For me, unbound restarts ones or twice a week, and even these restarts do not loose the DNS cache, as it is dump before the stop, and read back in when it restarts. That is, if pfBlocker was restarting it.Big, no, huge DNSBL lists were build, and unbound needed a lot more time to start. People started to detect DNS outages.
Yes, the "huge" DNSBL lists were what I was referring to. pfBlockerNG and the DNSBL feature can certainly be a useful tool, but many users manage to shoot themselves in the foot with it as evidenced by the many posts I see here on the Forums. And instead of being only a moderately painful "BB-gun" (an air-powered, small caliber weapon for those who might not be familiar with the common American name), the tool can be the equivalent of shooting your foot off with an American AC-130 gunship (a.k.a. "Angel of Death") when used with huge lists of domains to block. That chokes
unbound
by generating long startup times as the lists are parsed. And untilunbound
starts, it can't do DNS lookups.