[dns-operations] Cloudflare DNS resolver (1.1.1.1): Weird DNSSEC race condition

[Petr Špaček]

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
>> https://gitlab.labs.nic.cz/knot/knot-resolver/issues/391
> 
> Yikes...well that explains the 3 hour delay on that one instance of 1.1.1.1.
> 
> I knew you folks were using knot-resolver at the core of the 1.1.1.1
> 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!

For curious:
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
brokenness.

Let's see how we can improve this. Thanks once again!

-- 
Petr Špaček  @  CZ.NIC