Unbound seems to be restarting frequently
-
-
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 filterAt 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.orgExact 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, meansunbounddoes not get restarted frequently.,Another source of frequent
unboundrestarts 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
unboundcontrol 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 withunboundand 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, meansunbounddoes not get restarted frequently.,Another source of frequent
unboundrestarts 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
unboundcontrol 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 withunboundand 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, meansunbounddoes not get restarted frequently.,Another source of frequent
unboundrestarts 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
unboundcontrol 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 withunboundand 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
unboundto 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.
No "help me" PM's please. Use the forum.
-
@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
unboundby generating long startup times as the lists are parsed. And untilunboundstarts, it can't do DNS lookups. -
Hello, I'm just getting up to speed on this issue. I've noticed the constant restarts of unbound... but it hasn't actually caused us any problems normally.
But now we are looking at using Cisco Umbrella DNS filtering, which seems to have some limits to the number of lookups that you can perform per day.
So the fact that unbound gets restarted and the cache gets cleared is now an issue due to the cache being cleared, resulting in way more upstream dns requests. I understand I can turn off registering dynamic dhcp leases, but that is a really nice feature.
Just to give a practical example, we are looking at signing up for 50 licenses, which are allowed 3000 lookups each a day, so 150K total for our 23 locations.
One of our busier branches had 150K queries to unbound in the last day, with about 12K cache misses. So with unbound doing it's constant restarting, we may have blown all our queries with one branch.
What is needed to move forward, there seems to be a roadmap at https://github.com/pfsense/FreeBSD-ports/pull/751
If that solution generally seems acceptable, then do the extra config bits just need to be added? Adding the view and the acl entries for interfaces that can use unbound?
It would probably be good to make sure the correct precedence of dns entries is respected with this solution, and things like that.
Hardware used: Alix 2D13 X 10, APU2D4 X 10, SG-2200 X 10, SG-2440 X 4
-
@stompro said in Unbound seems to be restarting frequently:
but that is a really nice feature.
On network(s) with many devices, or network(s) that have a faulty implementation of the DHCP client, or network(s) with devices that loose their connection very often (Wifi), the current implementation of how lease info, the hostname + IP, is updated in the resolver unbound, is completely flawed **.
A question that every admin has to ask for himself : what devices in a network need to be known by 'name' ?
Most of our portable devices, and most PC's TV's whatever : we don't care. Only server type devices like printers, NAS, scanners, cameras etc need to have their name assigned.
And if possible not the default name these devices propose but a name chosen by the admin.
For these devices : make a static mac DHCP lease entry. This type of devices are not added a lot to our networks, none of us is installing a new network printer and NAS every day.
Shut down "DHCP Registration".
And done.
Bonus : you have a build in list in pfSense with all your important network devices, part of pfSense config.
All the important devices (servers) or less important devices can use the default DHCP-client mode. The admin control from pfSense what their IP / DNS etc will be. No more f*ck *ps when people start to assign static addresses (and forget half the stuff needed).
With the upcoming IPv6 it will be even easier to administer all this stuff in one place : pfSense.I made entries a long time ago for all devices that I access by wire.
https://github.com/pfsense/FreeBSD-ports/pull/751 uses a potential good solution.
Another approach might be : as unbound can uses "call back functions" for nearly every important resolve step, and it has chooses python to be the call back script method, its easy to add another python script "made by pfSense" that loads the file content of the DHCP-leases file if it was changed. If not, it serves IP or reverse right out the in python memory array.
Exactly like pfBlockerNG-devel using the 'python' mode.** edit : that is : pfSense, with a dozen or so devices that behave correctly, like 24 hours leases, so 12 or so renewals take place every day, the situation is pretty non noticeable.
But when these devices start to emit big quantities of DNS traffic, users will start to notice something. -
@stompro said in Unbound seems to be restarting frequently:
which are allowed 3000 lookups each a day
That is a really low number.. Out of curiosity if they block something, what is the TTL they send on the blocked IP they send you back? What exactly do they send back for a query that is blocked? Do they send back an IP that points you to a block page? Do they just send back 0.0.0.0, do they send back NX, Refused? What is the ttl if they send you back an IP of any kind?
A client looking for something, be it blocked or not if the ttl is low, or even if its high could produce a insane amount of queries depending on what is sent back, and what is actually cached.
I agree unbound clearing its cache sure isn't going to be helpful in lowering the number of queries sent upstream..
Until they change how registration of dhcp is done so it doesn't restart and clear the cache of unbound.. Turning that off is one solution.
Another solution might be to use another local cache, that isn't restarted that unbound forwards to. Also you might want to look into increasing min TTL to lower number of queries.
Also when you find stuff that is being blocked by them, creating a local block for that - so its not forwarded upstream could be way to reduce your overall number of queries sent to them.
-
@gertjan said in Unbound seems to be restarting frequently:
Shut down "DHCP Registration".
And done.Except that this is a documented feature and should work properly. It doesn't. This is a workaround and in some cases undesirable.
-
@swixo said in Unbound seems to be restarting frequently:
This is a workaround and in some cases undesirable.
I don't think anyone would disagree with that. It has been a sore point for a long time.
Agree it not very desirable for unbound to restart and loose its cache on every dhcp, etc.
-
@swixo said in Unbound seems to be restarting frequently:
Except that this is a documented feature and should work properly. It doesn't.
Sure and it's serious. pfSense is perfect. The issue is fare to 'old'.
But I have this impression that not many people notice it / are bothered with it / always look at the dashboard page and never to the page that actually matters most : the log pages. Dono why. maybe the log pages are less pretty.@swixo said in Unbound seems to be restarting frequently:
This is a workaround and in some cases undesirable.
Workaround ?
I used two available options in the GUI. Telling pfSense not to use the names DHCP devices gave it (because most use really stupid non significant,t names) : I like to chose my own names.
I like to chose what IP is used by what device, like servers from 192.168.1.20 to 20 - cameras from 30 to 50 - NAS and printers from 60 to 70 - and all PC's start after 80.
And again : no need to 'login' into every LAN device to set up DHCP/network related stuff. No need to know and learn all these thee devices. I control their network behaviour from pfSense.That's not a work around : it a huge feature. I even presume that all 'big' or 'company' networks are set up like that.
Btw : I work f for a hotel and I decide who sleeps on which room, the clients don't chose.
No coding needed here. Just very ordinary classic network 'book keeping' and vey ancient network knowledge.
My opinion is based on a small (60 devices ?) company network of course, @home I care less, I only want to now where my NAS is ;)
@johnpoz said in Unbound seems to be restarting frequently:
I don't think anyone would disagree with that
I call it a bug (flaw, whatever).
Still, as sais, no workaround needed IMHO.
Even if the dhcpleases change = unbound restart issue wouldn't exist, I would myself allocate my network device devices.
Doing so so under pfSense even squashed a bug. -
@johnpoz said in Unbound seems to be restarting frequently:
That is a really low number.. Out of curiosity if they block something, what is the TTL they send on the blocked IP they send you back? What exactly do they send back for a query that is blocked? Do they send back an IP that points you to a block page? Do they just send back 0.0.0.0, do they send back NX, Refused? What is the ttl if they send you back an IP of any kind?
They redirect to a block page, requires installing their CA on devices you want to show the block page without browser warnings.
I'll gather the other info about the TTL once they re-enable my trial.
I am trying the Minimum RRSet TTL setting of unbound, to make the miniumum TTL 2 hours. That does seem to help quite a bit.
Thanks for the reply.
Hardware used: Alix 2D13 X 10, APU2D4 X 10, SG-2200 X 10, SG-2440 X 4
-
@stompro said in Unbound seems to be restarting frequently:
Minimum RRSet TTL setting of unbound, to make the miniumum TTL 2 hours. That does seem to help quite a bit.
I have ran a min ttl of 1 hour for many many years - I have not seen any sort of issues with doing so.. Its not that I trying to actually lower the number of queries - but sites that use excessively low ttls bug the shit out of me ;)
There is no sane reason to have a ttl of 60 seconds - unless your were in the actual process of changing the record to point elsewhere.. And 60 seconds, 5 minutes seem to be a growing common thing with dns hosted by dns services. I think they are on purpose trying to increase the number of queries sent to them.. Either just bumping their numbers up, or wanting to track users more on how long they are staying on sites, how often they go there, etc.
Sure if the record is for a dynamic host, ie ddns sure you wouldn't want that ttl to be like a day or something...
So I would be curious how low they set the ttl of something.xyz.com that are blocking, will it maybe be unblock 5 minutes from now ;)
-
This is getting off topic also, but I'm also exploring sending out a list of the top 100-500 domains in a domain override list to bypass cisco umbrella resolution for the most heavily requested domains... it seems like I can just use our ISPs or googles dns servers for those entries. And Unbound has some nice options for domain overrides that I didn't know about. I can set multiple servers for each domain, you can say to fall back to the system forwarders if the configured override forwarders are not accepting requests for fault tolerance. And I'm reading up on on dumping and restoring the cache to make unbound restarts retain the rrset cache. But this whole case of paying per lookup essentially is probably quite a niche situation.
And after reading more about how Cisco Umbrella calculates usage, it looks like it is a 30 day daily average, so you get some credit for slow weekends and the like.
Hardware used: Alix 2D13 X 10, APU2D4 X 10, SG-2200 X 10, SG-2440 X 4
-
@stompro said in Unbound seems to be restarting frequently:
This is getting off topic also
Yeah but quite often that is where the fun happens ;) A specific question can often lead to great discussions, be that always on point and specific the original question would be boring..
If threads were always question : answer and that is all - I doubt I would spend as much time here as I do..
I could see quite a few ways to reduce the number of queries sent to them ;) Overrides for stuff you know is on the bad list, but yeah I like your idea of known good domains being forwarded to somewhere else that doesn't charge you for the query.. I mean how likely is it for example for www.google.com to get put on their bad list ;) So why ever ask them for www.google.com.. And have that query count against your use.
The only problem I see with that is if they did for some reason put something on the block list that you were forwarding somewhere.. But there is prob a large list of specific fqdn or domains that are highly highly unlikely to be listed as bad by them.
-
@johnpoz said in Unbound seems to be restarting frequently:
I could see quite a few ways to reduce the number of queries sent to them ;) Overrides for stuff you know is on the bad list, but yeah I like your idea of known good domains being forwarded to somewhere else that doesn't charge you for the query.. I mean how likely is it for example for www.google.com to get put on their bad list ;) So why ever ask them for www.google.com.. And have that query count against your use.
I'm not too worried about caching the bad stuff, that should be a very small minority of requests, and once someone hits the block page, I doubt they will keep trying enough for it to be a problem.
www.google.com is actually one I wouldn't want to add, since Cisco Umbrella enforces safe search for google search results. Although it is possible to do that locally(setting a domain override for google.com to a certain ip), I'm not sure how they are doing it, so I would rather leave that on them. I think google uses sane ttls so they don't seem to be a problem.
I'm going to stick with bypassing for service related stuff, not content related. windowsupdate,msedge,connectioncheck.ubuntu.com,lencrpt.com.
-
@gertjan said in Unbound seems to be restarting frequently:
Consider the situation: unbound starts, and read all the files its need, like /var/etc/hosts, the DHCP leases file, etc.
Then we instruct it to load the cache file, /var/tmp/unbound_cache
It doesn't take long to discover that the internal working cache (with the new local info) in unbound is being replaced by what has been written in /var/tmp/unbound_cache.
F*ck.
Doing so makes it completely useless to restart unbound to begin with …... >:(
As said in the doc: dump_cache and load_cache exists for debugging purposes.Hello, I was trying to track down why the unbound dump_cache and load_cache where not fully implemented, and saw your comments from 2015. I'm wondering if maybe something has changed in the unbound code... because I cannot verify that local data is included in the unbound cache dump.
When I do a cache dump, I cannot find any of my locally setup domains in the data.... and if I understand your rant correctly, you are saying that old stale local data from the dump would overwrite new data, making the dump and restore unusable.
In my testing with unbound 1.12 in 21.05.2, I don't notice any incorrect data after a dump and restore. Could you tell me what to look for? Maybe NXDOMAIN entries?
The negative catch entries don't seem to cause any problems... I just tried the following steps.
- dig printer9.mylocaldomain.org, no results
- dumped the cache
- fgrep printer9 unboundcache.file
- msg entry exists "msg printer9.mylocaldomain.org. IN A 33155 1 169 3 0 1 0" (I'm ignorant about what that actually means though, is that a negative cache entry?)
- Added a host override for that host.
- reloaded the dumped cache
- dig printer9.mylocaldomain.org returns the correct results
Maybe the problem is with existing dns entries, that are now being overriden?
- dig testsite.mylocaldomain.org, returns current A record.
- dump unbound cache
- fgrep cache file "testsite.mylocaldomain.org. 864 IN A 18.22.82.21"
- Add domain override for testsite.mylocaldomain.org
- Restore the dump.
- dig testsite.mylocaldomain.org returns the correct info, it wasn't overwritten by the restore.
So maybe it would make sense to now revive that feature?
-
@johnpoz said in Unbound seems to be restarting frequently:
@swixo said in Unbound seems to be restarting frequently:
This is a workaround and in some cases undesirable.
I don't think anyone would disagree with that. It has been a sore point for a long time.
Agree it not very desirable for unbound to restart and loose its cache on every dhcp, etc.
Still hoping for a fix here. Another big time-waster network issue emerged that came down to this issue. Certain MAC clients getting stuck if they make a DNS request during the reload time.
Who do I have to pay to get this fixed properly?
