-----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: > >> ha...@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. >> ha...@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----- _______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
