Unbound - restarted when interface wakes up? (is delay and BlackLists)

Started by lar.hed, December 05, 2020, 11:00:58 PM

Previous topic - Next topic
Do we (?) know if a server restart/reboot (Windows/Linux) will trigger a reload also in Unbound, if it is direct connected to OPNsense (like my LAN PC is connected)?

I can't know for sure, but logically - it should, because the physical link will be down / up

Quote from: lar.hed on December 10, 2020, 01:38:56 PM
Do we (?) know if a server restart/reboot (Windows/Linux) will trigger a reload also in Unbound, if it is direct connected to OPNsense (like my LAN PC is connected)?

Okay, I just had to test this: restart of server = restart of Unbound, and if one has a bunch of BlockLists, well OPNsense in my case looses name resolution for about 40 seconds = downtime. Sorry.

This in my case also gives that 4 (four and not 2) out of 8 ports are in risk of triggering a Unbound restart = downtime of about 40 seconds. Adding a managed switch, which of course will solve the restart Unbound issue, will be way more complicated with VLANs and all. It is sooo much simpler with just raw ports direct into OPNsense (in my mind, anyone is free to have other opinions).

I'll test DNS-Proxy now...

Quote from: lar.hed on December 10, 2020, 04:27:43 PMI'll test DNS-Proxy now...
Yes this works kind of, I get a downtime of about 8 seconds before everything works - however I do get an answer without reload of a web page for example - I am not loosing any info as far as I can tell. So Yes it kind of works - it just needs about 8 seconds to local zone to be reloaded - but that is it.

I have to say, DNSCrypt-Proxy looks good so far. Does not support local blocklists (I have two that I need for Sweden only so to speak, so being able to add them is well something I would like, anyone knows if they could be added via ssh/shell?), but the rest is a-okay. And I have done some more testing, and there does not seem to be any 8 seconds wait like I had in the first few tries - maybe I was a bit to eager...

Quoteanyone knows if they could be added via ssh/shell?
I think you can. via custom configd action
you can copy the update script with hardcoded dnsbls (/usr/local/opnsense/scripts/OPNsense/Dnscryptproxy/dnsbl.sh), add your lists to it (don't forget to clear it. it should only contain fqdns), add a custom action to configd (copy of "Download DNSCrypt-Proxy DNSBLs and restart" but with your own script and Description) and cron this job  instead of a "Download DNSCrypt-Proxy DNSBLs and restart"
(imo its better to ask the devs (@mimugmail I think) ) to add some kind of hook to the dnsbl.sh for custom dnsbls (source "$custom_dnsbls" ? ))
QuoteAdding a managed switch, which of course will solve the restart Unbound issue, will be way more complicated with VLANs and all
I thought that "protected ports" would be enough for it

Quote from: Fright on December 11, 2020, 07:20:51 AM(imo its better to ask the devs (@mimugmail I think) ) to add some kind of hook to the dnsbl.sh for custom dnsbls (source "$custom_dnsbls" ? ))

Although that would be great, I rather see that any time spent on this issue is spent on Unbound.

Quote from: Fright on December 11, 2020, 07:20:51 AM
Quoteanyone knows if they could be added via ssh/shell?
I think you can. via custom configd action
you can copy the update script with hardcoded dnsbls (/usr/local/opnsense/scripts/OPNsense/Dnscryptproxy/dnsbl.sh), add your lists to it (don't forget to clear it. it should only contain fqdns), add a custom action to configd (copy of "Download DNSCrypt-Proxy DNSBLs and restart" but with your own script and Description) and cron this job  instead of a "Download DNSCrypt-Proxy DNSBLs and restart"

Yep - that seems to work just perfect. For now, or until Unbound is just that tiny bit better with reload instead of HUP, this will do just super. And my WAN fail-over also works like a charm - so happy for the moment!

(until I get to next challenge where I most likely will have to figure something else out - gray hair or what it now was according to @mimugmail )

can you test unbound.inc changes for if down/up unbound HUP issue workaround? (checks if a file has changed before reloading). works on test VM but who knows..
https://github.com/kulikov-a/core/commit/d799447ae87bd722a301c83822cf7671c088ee9e

Quote from: Fright on December 11, 2020, 10:07:07 PM
can you test unbound.inc changes for if down/up unbound HUP issue workaround? (checks if a file has changed before reloading). works on test VM but who knows..
https://github.com/kulikov-a/core/commit/d799447ae87bd722a301c83822cf7671c088ee9e

Works 100% perfect!

Good!
I also noticed that the unbound does not actually restarts on cron job "Download Unbound DNSBLs and restart".
imo the command in actions_unbound.conf should be changed to

/usr/local/opnsense/scripts/unbound/download_blacklists.py && configctl unbound reload

can also change download_blacklists.py a little
before:
blacklist_items.add(entry)
after:
blacklist_items.add(entry.lower())
(in debug mode there is many messages about a duplicate dnsbl when local zone loads. but it does not affect the load time i think)
it might be worth making a FR for unbound.inc\actions_unbound.conf changes

Quote from: Fright on December 12, 2020, 08:07:03 AM
I also noticed that the unbound does not actually restarts on cron job "Download Unbound DNSBLs and restart".
imo the command in actions_unbound.conf should be changed to

/usr/local/opnsense/scripts/unbound/download_blacklists.py && configctl unbound reload


Not sure I follow on this, since the code I have (not changed in any way) is:
[dnsbl]
command:/usr/local/opnsense/scripts/unbound/download_blacklists.py && /usr/local/sbin/pluginctl unbound restart
parameters:
type:script
message:fetching and applying DNSBLs
description: Download Unbound DNSBLs and restart


I'll have a look on the other stuff now...

Quote from: Fright on December 12, 2020, 08:07:03 AM
it might be worth making a FR for unbound.inc\actions_unbound.conf changes

Ohhh this is where my lack of (Git-) knowledge will be a bit embarrassing I guess, I have no idea how to do that  :(

QuoteNot sure I follow on this
in your string its
pluginctl unbound restart
do nothing on my test VM. afaik it should be
pluginctl -s unbound restart
or
configctl unbound reload
reload is far more faster than restart. on test VM with full DNSBLs list it takes 40sec to reaload and 1m24sec to restart
(need to talk with devs. imho reload is enough after dnsbl update)
QuoteI have no idea how to do that
ok. i'll try )

Aah - now I do follow! Thanks! I have no idea (yet) if the restart as it is written works or not, since well I have simply put not tested it (yet - but now I have to figure out a test).