Recently our Internet Service Provider had an outage.
After some random rebooting on our part (duh), we gave them a call.
Unnoticed by us, when Unbound was restarted, it stopped serving our
local stubs that are served by NSD on 127.0.0.1:54. Also unnoticed
was the fact that our DHCP server refused to restart as a result of
unresolvable local domain host names being in its config file...
So while we were waiting for the ISP to bring up the service, our
internal hosts started losing their DHCP leases! :^)
I "googled" this and found a blog post of someone else having a
similar problem:
We've subsequently created a kluge (too horrible to share) that that
works around this problem (should it arise again).
I write this in the hope that the good folks who work on Unbound may
be inspired to change this behaviour in a future version.
I was able to recreate the problem by installing Unbound/NSD in a
virtual machine, then disabling the NIC, then restarting Unbound.
We rely on the built-in list of root hints. It looks like Unbound
insists on contacting (?) those servers before it's willing to service
requests for local stubs...
I've verified this behavior running v.1.5.8 on OpenBSD.
I'm sorry for not testing with v.1.5.9 as it's not in OpenBSD "ports"
yet and I did not see a reference to this problem in the changelog for
that release (and I'm lazy).
I guess that your unbound resolver is set to do DNSSEC validation.
Unbound tries to verify chain of trust from root (.) to the resolving domain,
even if the domain is a stub/forwarder zone. Obviously the validation fails
when unbound can't reach root servers (or TLD servers) due to network outage.
Possible workaround is to set negative trust anchor
(domain-insecure) for the stub zone like this:
I guess that your unbound resolver is set to do DNSSEC validation.
Unbound tries to verify chain of trust from root (.) to the resolving domain,
even if the domain is a stub/forwarder zone. Obviously the validation fails
when unbound can't reach root servers (or TLD servers) due to network outage.
sounds plausible.
Possible workaround is to set negative trust anchor
(domain-insecure) for the stub zone like this:
Even operating a root zone mirror (rfc7706) wouldn't help because second level domains could not be reached.
So if a network like to keep internal/own services running DNSSEC must be disabled (at all or by setting negative trust anchors)
Consequence to me: using DNSSEC *require* connectivity.
Am I right?
... and that made the difference. Unbound was indeed able to resolve
local stubs even when the internet connection was down.
As I recall, when first configuring unbound, I searched this file:
unbound/doc/example.conf.in
... for the string of 'DNSSEC' to see what the relevant settings were
and I notice now that the commentary for the 'module-config' setting
does not include that string. The man page [unbound.conf(5)] does
(I should have searched there too)...