Forwarding fails with DNSSEC validation

Unbound
1

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.

The forwarder returns the correct response, as far as I can see:

hauke@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?

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:

hauke@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=

Hauke.

2

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@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@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

3

W.C.A. Wijngaards wrote:

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

Unbound 1.3.0, although I just reproduced it with svn r1660, too.

I set the forwarder with "unbound-control forward" as I plan to use it
in DHCP client hooks.

Now, with one of the resolvers at the local office, forwarding works as
expected.

With another, it fails just in the same way I experienced earlier on a
different network.

I will try and run some tests as well as send you configuration and
debug details later after work.

Hauke.