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

[Petr Menšík]

No, RRSIG should never be looked up manually. You just send query with
DO bit enabled and expect to receive all RRSIGs for all records in the
reply. If the server fails to include RRSIG, but manual query would
work, it should be fixed on server side.

If your change has modified only this problem, I guess we should have
only test ensuring it works with a correct reply.

If any such problem occurs again, contact the service operator or fill
at least issue at:

https://github.com/dns-violations/dns-violations

Cheers,
Petr

On 4/28/22 21:03, Chris via Dnsmasq-discuss wrote:
> Hi all,
>
> Following on from Peter's comments, I went back to Cloudflare and they
> have fixed their upstream server.
>
> I'm not sure if it's dnsmasq's job to look up the RRSIG of an A record
> delivered with a CNAME, but either way, my original problem is now solved.
>
> If you think this is still something that should be supported, I'm
> happy to look into it some more, but probably not.
>
> Thanks all for your input on this.
>
> On 22 Apr 2022, at 07:57, Peter van Dijk <peter.van.dijk at powerdns.com>
> wrote:
>
>     Hi Chris,
>
>     you replied only to me, and not to the list - in case that was on
>     purpose, this reply is also only to you. Feel free to take this back to
>     the list.
>
>     Given names x and y, with x in an unsigned zone and y in a signed zone,
>     and the following content in those two zones:
>
>     x CNAME y
>     y A 192.0.2.1 <http://192.0.2.1>
>     y RRSIG A ...
>
>     your upstream, when asked to do DNSSEC, should give the RRSIG A for
>     both queries 'x A' and 'y A'. If it does not, it is broken. I'm not
>     sure it's dnsmasq's job to compensate for this.
>
>     Cheers, Peter
>
>     On Thu, 2022-04-21 at 23:04 +0100, Chris Staite wrote:
>
>         Yes, And having spent the evening looking at the problem
>         again, I now see that my fix isn’t actually the correct
>         solution. The issue is actually that the server replies with
>         the CNAME and no RRSIG for it (because it’s not signed) and
>         the A records for the CNAME (but no RRSIG values for them). If
>         a query is done separately for the target of the CNAME the
>         RRSIG for the A records are returned. I’m not sure if this is
>         an issue with dnsmasq (whether it should request the A records
>         for the CNAME target as if they weren’t returned already) or
>         if the upstream server really ought to reply with the RRSIG
>         values in the original reply. I’ve got some code in test that
>         detects the lack of RRSIG and removes it from the response,
>         but I’m still trying to figure out how to get dnsmasq to
>         re-query for the A records and get the RRSIG itself. Thanks,
>         Chris.
>
>             On 21 Apr 2022, at 18:36, Peter van Dijk
>             <peter.van.dijk at powerdns.com> wrote: On Fri, 2022-04-15 at
>             00:19 +0100, Chris Staite via Dnsmasq-discuss wrote:
>
>                 It does require the CNAME to come before the A record,
>                 but I think that’s required in the standard anyway 
>
>             This is not something you can rely on. Records can get
>             reordered for many reasons. Kind regards, -- Peter van
>             Dijk PowerDNS.COM BV - https://www.powerdns.com/
>             ------------------------------------------------------------------------
>             Dnsmasq-discuss mailing list
>             Dnsmasq-discuss at lists.thekelleys.org.uk
>             https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>
>
>
>
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik at redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20220429/e34d1f5d/attachment.htm>