[2.0.1] unbound problems
-
Hi all,
I tried to run unbound as the primary DNS resolver for our networks for the past 3 months. However, two particular mission-critical issues made me revert to DNS forwarder for now:
Issue 1: Unbound silently "dies" after WAN connectivity drops. Service page still shows unbound running, but it does not answer DNS queries anymore - even after WAN connectivity is restored. This happens everytime the WAN goes down for more than a minute or so. Restarting unbound from the service page corrects the problem.
Issue 2: Unbound sometimes fails to start up after a reboot. Service page shows unbound as not running. Manually starting the service corrects the problem.
I cant be ***** to play unbound-nanny all day.
So bye-bye unbound for now. Too bad, it looked very promising! -
Unbound backs off for certain period between 1 and 15minutes when it detects that servers are down. After 900s it should re-enable itself again. You can lower this timeout by adjusting the value for 'TTL for Host cache entries' in the advanced section. Otherwise you can also issue, from the command line, unbound-control flush_infra and service should resume.
-
Unbound backs off for certain period between 1 and 15minutes when it detects that servers are down. After 900s it should re-enable itself again. You can lower this timeout by adjusting the value for 'TTL for Host cache entries' in the advanced section. Otherwise you can also issue, from the command line, unbound-control flush_infra and service should resume.
You're kidding me! Let's entertain your idea for a moment:
T=00: WAN goes down
T=01: Client wants to resolve a DNS.
T=02: Ubound "detects that servers are down" and "backs off"
T=03: Resolution fails cause WAN is down.
T=22: WAN comes up
T=34: Client A does ICMP echo_request to 195.186.1.110
T=35: Client A receives ICMP echo_reply from 195.186.1.110
T=50: Client B wants to resolve a DNS.
T=53: Resolution fails due to ubound "taking a break"
T=55: Client C wants to resolve a DNS
T=57: Resolution fails due to ubound "taking a break"
….
T=900: Ubound decides the nap is over and comes back into operation ??? ???Uh yeah. Right. You're not going to need any high availability features with services built like that, hahaha... ;D
Anyway. It doesn't seem to apply to what happened here, because one little difference: ubound didn't "re-enable" itself no more. Not after 900 secs. Not after 4 hours. Only after I manually restarted it, did it process DNS requests again.
If this is a "feature" then ubound must be a M$ product!