[Unbound-users] Forwarding failing when DNSSec is enabled
wouter at NLnetLabs.nl
Thu Jul 2 07:04:43 UTC 2009
-----BEGIN PGP SIGNED MESSAGE-----
On 07/01/2009 06:46 PM, Paul Wouters wrote:
> On Wed, 1 Jul 2009, Harish Chandra wrote:
>> Without DNSSec, forwarding is working fine. With DNSSec enabled (I am
>> using DLV), forwarding fails when I forward my querries to a server that
>> isn't dnssec enabled.
>> The output from the log looks like this:
>>  unbound[7919:0] info: verify rrset <dlv.isc.org.. DNSKEY IN>
>>  unbound[7919:0] debug: rrset failed to verify due to a lack
>> of signatures
> Are you running trunk? There is a bug upto 1.3.0 that caused DLV to
No the actual resolver he is running, the upstream that unbound is
forwarding to, is not dnssec enabled. That means it is not transmitting
RRSIGs with the responses. Without signatures unbound can only conclude
that signatures have been removed (and that could possibly be
malicious). Therefore the queries are failed for security.
Harish is correct that it would be fine if, say the upstream is also
running unbound without trust anchors, and the forwarder downstream has
trust anchors. In that case the downstream does the validation.
But here, it is not about trust anchors, it is about getting signatures.
So, the solution here is to make the upstream actual resolver
transmit signatures in replies. dnssec-enable:yes for BIND.
Or deploy unbound there, which does it by default.
>> The failure appears because of a signature mismatch. But why is
>> validation taking place when the actual resolver can't talk dnssec? My
>> config file looks like this:
> It should fall back to non-secure. If your forwarder changes again to one
> that does relay dnssec information, unbound drops the cache and uses the
> validator again (If I understood Wouter correctly, I have not verified
> this myself)
It does not do that! That would be a downgrade attack!
However, this idea is significantly popular, and there is even an option
for unbound: harden-dnssec-stripped that you can turn off.
You are then susceptible to the downgrade attack, but it does the above.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the Unbound-users