[Unbound-users] Forwarding fails with DNSSEC validation

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Hauke,

I have tried to reproduce, but forwarding to another server and DLV
enabled works fine for me.  What version of unbound are you using?

harden-dnssec-stripped is not support to be disabled.  I did create this
config option to help operators in strange situations like this.

Can you give me (in private, off-list) email more configuration that you
use?


Hauke Lampe wrote:
> Hello.
> 
> Forwarding without DNSSEC validation works fine. However, forwarding
> with DNSSEC validation fails for insecure zones (and sometimes secured,
> too), unless I set "harden-dnssec-stripped: no".
> 
> Forwarder is BIND 9.6.1rc1 and so far I had not much trouble with
> validating (BIND) resolvers behind it.
> 
> Where should I look for the cause of this problem?
> Or is "harden-dnssec-stripped" supposed to be disabled in a forwarding
> setup?
> 
> 
> A failing query for an insecure zone typically looks like this:
> 
>> info: resolving <www.example.com. A IN>
>> info: response for <www.example.com. A IN>
>> info: reply from <.> 10.42.23.3#53
>> info: query response was ANSWER
>> info: resolving <www.example.com.dlv.isc.org. DLV IN>
>> info: response for <www.example.com.dlv.isc.org. DLV IN>
>> info: reply from <.> 10.42.23.3#53
>> info: query response was ANSWER
>> info: resolving <com.dlv.isc.org. DS IN>
>> info: response for <com.dlv.isc.org. DS IN>
>> info: reply from <.> 10.42.23.3#53
>> info: query response was ANSWER
>> info: NSEC RRset for the referral did not prove no DS.
>> info: Could not establish validation of INSECURE status of unsigned response.

What is weird is that it is querying for type DS.
It should not be doing that but querying to type DLV.

Can you run an example like this again, with verbosity=5
capture the logfile and send that to me?
(offlist, it'll be big and contain your IP numbers)

> The forwarder returns the correct response, as far as I can see:
> 
>> hauke at pope:~$ dig +dnssec com.dlv.isc.org. DS  @10.42.23.3
> [...]
>> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
> [...]
>> ;; AUTHORITY SECTION:
>> dlv.isc.org.		3600	IN	SOA	ns-int.isc.org. hostmaster.isc.org. 2009061202 7200 3600 2419200 3600
>> dlv.isc.org.		3600	IN	RRSIG	SOA 5 3 3600 20090712140015 20090612140015 64263 dlv.isc.org. BVoz6eKZVJL4Fqd3sxuxringDn3823lWmmw7r+wnQAeAfEZalql2srh/ vUhIWqxF2LZWDgAgg3Wgzaq9XHtUX4h9gmtxjA80vTbOaO7TAoUGPSz7 A6KYL3epOuiTNW5zV0JWoo3JRUXn5baCCcc8HZnh+Zinl8CmLEmRo0yr yk8=
>> seatex.com.cn.dlv.isc.org. 3600	IN	RRSIG	NSEC 5 6 3600 20090712140015 20090612140015 64263 dlv.isc.org. e629+1zdL6GKD9Ti6q96UjXldZio7SXgqNIYOGem2iFgFrwEBhNnHPHm Zpg/5LPh1FgPjPsdYcphBCOTiUnZ1pcZ8LfMHtPM57hB7VF7eoExkIXU cJCGndG0+vBaZ8Yf7HXeOESoWDNdX0GPTspld68rgLY5UfSQdIbzI2xS Chk=
>> seatex.com.cn.dlv.isc.org. 3600	IN	NSEC	absolight.com.dlv.isc.org. RRSIG NSEC DLV
> 
> Curious thing: Even though tcpdump shows no difference in both query and
> response packets, the response to Unbound's query is not cached.
> Querying with dig forces the forwarder to retrieve the record again and
> cache it. Is this normal?

I do not understand you here.  Is unbound not caching or is the
forwarder(bind) not caching?  Unbound should be caching these queries.

> Queries for secure zones succeed most of the time:
> 
>> info: resolving <www.hauke-lampe.de. A IN>
>> info: response for <www.hauke-lampe.de. A IN>
>> info: reply from <.> 10.42.23.3#53
>> info: query response was ANSWER
>> info: resolving <hauke-lampe.de.dlv.isc.org. DLV IN>
>> info: response for <hauke-lampe.de.dlv.isc.org. DLV IN>
>> info: reply from <.> 10.42.23.3#53
>> info: query response was ANSWER
>> info: validate(positive): sec_status_secure
>> info: validation success <hauke-lampe.de.dlv.isc.org. DLV IN>
>> info: resolving <hauke-lampe.de. DNSKEY IN>
>> info: response for <hauke-lampe.de. DNSKEY IN>
>> info: reply from <.> 10.42.23.3#53
>> info: query response was ANSWER
>> info: validated DNSKEY <hauke-lampe.de. DNSKEY IN>
>> info: validate(positive): sec_status_secure
>> info: validation success <www.hauke-lampe.de. A IN>
> 
> but sometimes they fail:
> 
>> info: resolving <www.hauke-lampe.de. A IN>
>> info: response for <www.hauke-lampe.de. A IN>
>> info: reply from <.> 10.42.23.3#53
>> info: query response was ANSWER
>> info: resolving <hauke-lampe.de.dlv.isc.org. DLV IN>
>> info: response for <hauke-lampe.de.dlv.isc.org. DLV IN>
>> info: reply from <.> 10.42.23.3#53
>> info: query response was ANSWER
>> info: Validate: message contains bad rrsets
> 
> What bad rresets could Unbound mean? Again, the response from the
> forwarder looks good to me:

Well it means that the answer contained signatures that failed
validation.  So perhaps a byte got mangled by a bad link? (although UDP
checksums catch that sort of thing, but those are not always enabled).

Again, if you could please enable verbosity to level 4 or 5, then the
complete packets are printed, and we can see if the response that
unbound got above is the correct one.

>> hauke at pope:~$ dig +dnssec hauke-lampe.de.dlv.isc.org. DLV IN @10.42.23.3
> [...]
>> ;; ANSWER SECTION:
>> hauke-lampe.de.dlv.isc.org. 3600 IN	DLV	56203 5 2 0DDE2A17776A0ED199F95AF248674711F2476A451CC816CB68B2FD55 55AC7CC7
>> hauke-lampe.de.dlv.isc.org. 3600 IN	DLV	56203 5 1 A663185665B4D3B4B3999ADCD320F4387E016322
>> hauke-lampe.de.dlv.isc.org. 3600 IN	RRSIG	DLV 5 5 3600 20090712140015 20090612140015 64263 dlv.isc.org. VRVFXaeQqywauBSAVYdFwYuqui6OnfW76E0Jdui+ebIJeIKIZddSCzET 7OLeGKd6ls5wHw/UGXFbBLHCBL97QJgoQbMSLspn9HDE3HzXfXP0eDqF Pcl0Lcxk5xW9dspYEduluFAsDbNu95kzOOXaYyE9dOCqP7gSXhqoMZyj dXY=

This one looks OK again.  Better to log from unbound to see exactly what
packet it got, since there may be some linklevel trouble here?
(Other explanation: the forwarder is hacked and sometimes gives faulty
information)

Anyway more verbosity helps, a clean test for me here works well with
DLV-anchor + forward-to-another-server(unbound).  Tell me more about
your configuration too, maybe I more options need to be enabled before
faults in unbound show up.

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAko194EACgkQkDLqNwOhpPihLQCgk5cU3ahVV00wzZQlsZRwWmb8
Iu8An1evONmB48LMBdftVcnj1GtbYdlH
=e4cr
-----END PGP SIGNATURE-----