unbound defaults break DNS resolution when upstream DNS lacks DNSSEC support

[Tom Hendrikx]

Unbound default setup (after upgrade from 11.10 to 12.04 server, package is 1.4.16-1) seems to be:
- DNSSEC enabled, root key added
- use resolvconf resolvers as forwarder when available

However, when resolvconf has knowledge of an upstream resolver that does not properly support DNSSEC, priming the root.key fails, and all queries to unbound are finally answered with SERVFAIL.

I ran into this when an upstream resolver did return DNSKEY data, but no RRSIG data with it. Unbound logs with an empty cache:

Apr 25 21:37:48 alison unbound: [20399:0] info: resolving nu.nl. A IN
Apr 25 21:37:48 alison unbound: [20399:0] info: response for nu.nl. A IN
Apr 25 21:37:48 alison unbound: [20399:0] info: reply from <.> 217.149.196.6#53
Apr 25 21:37:48 alison unbound: [20399:0] info: query response was ANSWER
Apr 25 21:37:48 alison unbound: [20399:0] info: prime trust anchor
Apr 25 21:37:48 alison unbound: [20399:0] info: resolving . DNSKEY IN
Apr 25 21:37:48 alison unbound: [20399:0] info: response for . DNSKEY IN
Apr 25 21:37:48 alison unbound: [20399:0] info: reply from <.> 217.149.196.6#53
Apr 25 21:37:48 alison unbound: [20399:0] info: query response was ANSWER
Apr 25 21:37:48 alison unbound: [20399:0] info: validate keys with anchor(DS): sec_status_bogus
Apr 25 21:37:48 alison unbound: [20399:0] info: failed to prime trust anchor -- DNSKEY rrset is not secure . DNSKEY IN

Since there still are a myriad of non-DNSSEC aware resolvers around, and resolvconf/unbound don't check for DNSSEC support at upstream, I don't think it's safe to assume that you can both enable/enforce DNSSEC in unbound, *and* use the upstream resolver unconditionally.

Therefore, I think that the default value for RESOLVCONF_FORWARDERS in /etc/default/unbound should be set to false, and not to true.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Tom Hendrikx (whyscream)]

Lately, we found out that this issue makes it virtually impossible to deploy unbound using automated tools (specifically: puppet), since this issue requires you to:
- install unbound (daemon gets started)
- edit config file
- restart unbound
- continue doing other stuff

When the daemon gets started the first time, all DNS lookups fail. When using puppet for deployment, you can do all these steps automated, but since puppet tries to delay the unbound restart until the end of the run, any action from puppet that tries to use DNS (f.i. download another package) will fail until unbound is restarted, which will not happen because puppet fails its run (because of broken DNS). There is virtually no way (AFAIK) that will get unbound running using puppet without modifying the package that ubuntu provides.

[Simon Déziel (sdeziel)]

@Tom, have you tried telling Puppet to set RESOLVCONF_FORWARDERS=false in /etc/default/unbound ?

[Tom Hendrikx (whyscream)]

@Simon: that impossible, because the /etc/default/unbound file is part of the package. You can only set this after the package is installed, and DNS resolving is broken at the moment the package is installed (Unbound is started automatically during post-install).

Anyway, the puppet issue only illustrates the problem with the default settings in the unbound package. This ticket isn't about puppet config, it's about a less than optimal default setting for unbound in ubuntu.

[James E. Blair (corvus)]

I agree with the statement in the bug report that the default should be safer.

However, you can work around the problem in config management by installing the defaults file before installing the package. In our Puppet config we have the unbound package require the defaults file: https://review.openstack.org/#/c/80092/13/modules/unbound/manifests/init.pp

[Nish Aravamudan (nacc)]

So unbound since 1.5.7-2 (which is in xenial and on) no longer ships a /etc/default/unbound by default. It would appear, based upon the change in that release:

+ RESOLVCONF_FORWARDERS
+
+ This variable controlled whether or not the upstream nameservers
+ supplied by resolvconf were configured into the running Unbound instance
+ with the "unbound-control forward" command, via a resolvconf update.d
+ hook.
+
+ This mechanism still exists, but the variable controlling it has been
+ removed. Instead, add or remove the executable bit from the
+ /etc/resolvconf/update.d/unbound file to enable or disable the hook.

And by default:

        install -m 0644 debian/resolvconf debian/unbound/etc/resolvconf/update.d/unbound

So I think it's non-executable (and thus not executed) by default. For the purposes of this bug, I feel like it's fixed now. However, I think we cannot change the default behavior in existing releases. Can you confirm that c#5's statement does work for you?

[Ondřej Surý (ondrej)]

> that impossible, because the /etc/default/unbound file is part of the package.

That's actually not true - you can create /etc/default/unbound before installing the package and the package will not overwrite the configfile by default:

root@lettie:/# touch /etc/default/unbound

root@lettie:/# ls -l /etc/default/unbound
-rw-r--r-- 1 root root 0 Dec 5 09:43 /etc/default/unbound

root@lettie:/# apt-get install unbound
[...]
Setting up unbound (1.4.16-1) ...

Configuration file `/etc/default/unbound'
 ==> File on system created by you or by a script.
 ==> File also in package provided by package maintainer.
   What would you like to do about it ? Your options are:
    Y or I : install the package maintainer's version
    N or O : keep your currently-installed version
      D : show the differences between the versions
      Z : start a shell to examine the situation
 The default action is to keep your current version.
*** unbound (Y/I/N/O/D/Z) [default=N] ?
invoke-rc.d: policy-rc.d denied execution of start.
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place

root@lettie:/# ls -l /etc/default/unbound
-rw-r--r-- 1 root root 0 Dec 5 09:43 /etc/default/unbound

I don't think that the default configuration is "unsafe". You are installing it in ***broken*** network, and thus you should modify your script to accommodate for the fact that the upstream resolver is broken.

Or just fix the upstream resolver, you should do that anyway.

[Tom Hendrikx (whyscream)]

@ondrey: Since when is a dns resolver without dnssec support 'broken'? I believe that DNSSEC is a good thing: it will improve security and everybody using it will benefit, even when most people don't understand what it is or that it is there. But since most home (and business-grade) DSL routers don't support DNSSEC (yet), this is not the correct default setup.

Note that this bug is already 4 years old, the situation for the general public hasn't really changed in that time IMHO.

[Ondřej Surý (ondrej)]

RFC 4033, 4034 and 4035 are on the IETF Standards track. Any recursive DNS server not supporting 10-yo standards is broken.

If we keep dancing around non-standard compliant devices, the situation won't ever improve. Go yell at your vendors for sticking their heads into sand. Or vote with your money.

As a bonus I've shown that you can setup /etc/default/unbound before you install the package when you are behind broken device. There's absolutely no need to patch the package for least-common denominators, au contraire, the package should set a reasonable and secure standard.

[Steve Langasek (vorlon)]

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release