[dns-operations] Cloudflare DNS resolver (126.96.36.199): Weird DNSSEC race condition
petr.spacek at nic.cz
Mon Aug 6 09:42:31 UTC 2018
On 4.8.2018 02:53, Michael Sinatra wrote:
> On 08/03/18 16:12, Marek Vavruša wrote:
>> This is due to the way how Knot Resolver deals with insecure
>> delegations currently. If the delegation doesn't have a DS, resolver
>> will remember the delegation as insecure and turn off DNSSEC until the
>> record expires from cache. The current cache maximum TTL is 3 hours,
>> which is when the NS+DS+DNSKEY was refetched. I've opened a ticket to
>> track this here
> Yikes...well that explains the 3 hour delay on that one instance of 188.8.131.52.
> I knew you folks were using knot-resolver at the core of the 184.108.40.206
> service, but wasn't sure if that or a Cloudflare optimization was the
> cause of what I was seeing, so I didn't think to try to replicate it on
> knot-resolver. Thanks for opening the issue with CZ NIC.
Thank you Marek and Michael for reporting this!
This is side-effect of not setting DO in queries to insecure zones.
The main motivation is that some insecure zones/name servers break
horribly when they receive a query with DO=1, and we did not want to
clutter code with even more workarounds for this particular type of
Let's see how we can improve this. Thanks once again!
Petr Špaček @ CZ.NIC
More information about the dns-operations