Maintained by: NLnet Labs

local stubs not served when internet down

Daisuke HIGASHI
Tue Jun 21 19:23:03 CEST 2016


Hi,

  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:

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

Regards,
-- 
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 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:
>
>   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
>
>