unbound defaults break DNS resolution when upstream DNS lacks DNSSEC support
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
unbound (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Precise |
Won't Fix
|
Undecided
|
Unassigned | ||
Trusty |
Incomplete
|
Undecided
|
Unassigned |
Bug Description
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_
Status changed to 'Confirmed' because the bug affects multiple users.