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

[schnipp]

I tried to reproduce this issue. Indeed, the whole unbound process is restartet in case a network links gets down and comes up again. This should not occur. But, now I know why sometimes name resolution stalls.

Do we have a related ticket on github regarding the FR?

[Fright]

FR added
https://github.com/opnsense/core/issues/4518

[Fright]

Interim results: "restart after dnsbl update" issue solved by @AdSchellevis before I noticed it  . Devs are aware of the problems with the unbound restart performance and are thinking about a solution. Suggestion to check host_entries file before restart (and skip restart if nothing changed) not accepted

[lar.hed]

What ever solution there might be in the end must be considered an improvement

Good work there @Fright !

[lar.hed]

Btw just for facts: With my OPNsense h/w with a Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz (8 cores), I restart (!) Unbound with all blocklists plus my own two in under 40 seconds. I have no idea how long a reload would take, but an estimate might be about 20 seconds?

[Fright]

easy to compare by checking unbound logs)

Code: [Select]

configctl unbound reloadfor reload
and

Code: [Select]

pluginctl -s unbound restarfor restart

but an estimate might be about 20 seconds?

I wouldn't be surprised if it fits in 15

[lar.hed]

easy to compare by checking unbound logs:

Code: [Select]

configctl unbound reload

Well...reload according to the log, is 40 seconds also - now in the log it says restart.

notice: Restart of unbound 1.12.0.

[lar.hed]

I just noticed that Unbound gets restarted when one saves System -> Administration -> Settings (I was altering SUDO, to disallow since I do not like to have that one opened...). That was kind of a big surprise...!

[Fright]

Well...reload according to the log, is 40 seconds also

thanks for the info!
looked deeper ..a bit embarrassing - should have found out before creating a FR.
the difference in time between restarting and reloading (~50sec) is just in one line - the launch (and fail) of the unbound-anchor utility in unbound_start.sh. DNSSEC is not allowed, by the way.
Need a little more time to find out what is happening (it looks like something with DNS traffic during the launch of the unbound-anchor: I don't see any replies on dns OPT-requests).
with successful launch of the unbound-anchor, the time difference between restart and reload should be imperceptible i think
(at the same time, I think that there is no need to launch unbound-anchor if DNSSEC is not enabled)

[Fright]

Oh. old cisco pix two hops in front of test VM blocked dns packets larger than 512 bytes..
now it takes 2 sec to start unbound-anchor and 37 to load unbound. so (!with unbound-anchor successful launch!) there is no imperceptible difference in time between restart and reload. need to think whats next

[lar.hed]

I just reversed back to DNSCrypt-Proxy since well no downtime what-so-ever for regular stuff like link up/down, changes in System and so on - all that Unbound for some reason needs a restart = 40 seconds of downtime.

[Fright]

I am wondering if the unbound will restart in 1-2 sec (without reading the DNSBLs) and the DNSBLs will load into a running unbound, will this help? I want to test and discuss with the devs, but only if it makes sense
upd:
quickly tested this approach
result: no downtime at all at restart. the server serves requests while loading the full 102MB dnsbl list
of course, while the list is loading, accidentally resolving a name from the dnsbl-s is possible

[Fright]

I just noticed that Unbound gets restarted when one saves System -> Administration -> Settings

confirm. reloads after that. i think it make sense. page contains dns-relative parameters

[lar.hed]

I just noticed that Unbound gets restarted when one saves System -> Administration -> Settings

confirm. reloads after that. i think it make sense. page contains dns-relative parameters

Hmmm well that does sound legit reason then, but the thing is I did not change any of that. I just altered the SUDO property. If I do that with DNSCrypt-Proxy this does not seem to happen - and the memory consumption is way less (I have 16GB RAM, and I can upgrade to 32GB if needed so I have no memory problem). Maybe DNSCrypt works in a different way?

[Fright]

but the thing is I did not change any of that

it seems to me that it is simply easier to respond to the applying of the entire form than to control and compare values from form fields and values in the system config.

Maybe DNSCrypt works in a different way?

developers can say more, but in my opinion the DNSCrypt is not so integrated into the whole system as an unbound (updating hosts records, registering dhcp client records etc.)

so what about loading dnsbls after unbound start (no downtime but accidentally resolving a name from the dnsbl-s is possible)? it might be interesting? for me this is more correct behavior than long service loading