local stubs not served when internet down

Daisuke HIGASHI daisuke.higashi at gmail.com
Tue Jun 21 19:23:03 CEST 2016


  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:

     auto-trust-anchor-file: "root.key" # DNSSEC validation enabled
     domain-insecure: "mydummylocaldomain.com"
     name: "mydummylocaldomain.com"
     stub-addr: at 54

Daisuke Higashi

2016-06-22 1:04 GMT+09:00 Tor Perkins via Unbound-users
<unbound-users at unbound.net>:
> Hello,
> 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  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:
>   https://kimmo.suominen.com/blog/2014/02/unbound-not-resolving/
> 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).
> Thanks for your consideration.  We love Unbound!
> - Tor

More information about the Unbound-users mailing list