[Dnsmasq-discuss] [PATCH] DNSSEC Validation (super-simplified version)

[Chris]

<snip>

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?

</snip>


On 15 Apr 2022, 08:55, at 08:55, Geert Stappers <stappers at stappers.nl> wrote:
>On Fri, Apr 15, 2022 at 12:19:55AM +0100, Chris Staite via
>Dnsmasq-discuss wrote:
>> Hi again again,
>> 
>> I realised it was even easier than that.  This time I am done and
>> going to bed though, so no more spam from me (at least tonight
>anyway).
>
>I when woke up, I did see three messages from same author about dnssec.
>Only one message was openened (the other two got marked as read)
> 
>> This time I actually fixed an issue with my simplified version in so
>> much as it was able to circumvent the unsigned check of the parent
>> from the target of the CNAME if the CNAME came after the A record in
>> the response, which was bad.  This stops that from happening, which
>> is good.  It does require the CNAME to come before the A record, but
>> I think that’s required in the standard anyway?  If it doesn’t,
>> well then at least it’s better than it was before.
>> 
>> Once again, please see previous for reasoning behind the patch.
>
>Please add the reason to the proposed patch.
> 
>
>> Thanks, Chris.
>> 
>
>Groeten
>Geert Stappers
>-- 
>Silence is hard to parse
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20220415/3e1ae857/attachment-0001.htm>