Hi, Please disregard my previous patch, it actually broke all DNSSEC validation for the simple case!
I now understand the problem more thoroughly and believe the new patch I have attached to fix the problem. The use case is as follows: 1) Query for a record. 2) Response is a CNAME which is valid but unsigned, but points to a record that is signed 3) Code checks unsigned and is happy with that (verifying NSEC) 4) Code checks CNAME and is happy with that (verifying the RRset) 5) Final validation sees a secure response in the answer set when the sigcnt for the response is 0 (because the CNAME was unsigned) and returns BOGUS The correct response here should be to return an INSECURE response (throwing away the secure check for the forwarded domain). One could argue it’s not worth validating the CNAME target if it isn’t signed itself… That’s an alternative, but we might as well make it as hard for the attacker as possible I suppose? I have attached a patch that utilises the `secure` variable to track one of the answers having an invalid signature and switches the response to an INSECURE one rather than a BOGUS. In order to ensure that the validation of the requested zone can’t be overridden by an insecure record on the target server, I have added the extra validation that only a CNAME could make it insecure. Otherwise I believe you could circumvent the logic by changing the order of the answer records to have the CNAME last. Thanks, Chris.
dnssec.patch
Description: Binary data
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
