Hi Viktor, I forgot to update this thread, but this should be fixed.
Best,
Marek
On Tue, 1 Sep 2020 at 10:19, Marek Vavruša wrote:
>
> Thanks Viktor, this looks like a bug in writing NSECs to the final response.
>
> On Mon, 31 Aug 2020 at 23:09, Viktor Dukhovni wrote:
> >
> >
> > My
Thanks Viktor, this looks like a bug in writing NSECs to the final response.
On Mon, 31 Aug 2020 at 23:09, Viktor Dukhovni wrote:
>
>
> My validating resolver downstream of CF 1.1.1.1 (among others) at times
> sees "bogus" denial of existence for:
>
> _25._tcp.mx.runbox.com IN TLSA ?
>
>
On 9/1/20 9:58 AM, Stephane Bortzmeyer wrote:
> AFAIK, Cloudflare uses Knot Resolver. I tested with another Knot
> resolver and it works:
I think they originally started the service quite close Knot Resolver
code, but they've apparently diverged quite a bit since then (I don't
know). To be sure,
On Tue, Sep 01, 2020 at 01:48:17AM -0400,
Viktor Dukhovni wrote
a message of 71 lines which said:
> * The apex wildcard record and signature identically ONLY from
> Google, Verisign and Quad9. From CloudFlare, I get the munin01
> NSEC record and signature twice, but this
My validating resolver downstream of CF 1.1.1.1 (among others) at times
sees "bogus" denial of existence for:
_25._tcp.mx.runbox.com IN TLSA ?
This is because the set of NSEC records forwarded by Cloudflare for this
domain is not complete. Looking across the major public DNS services:
