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

[Paul Hoffman]

On 6 Aug 2018, at 16:07, Michael Sinatra wrote:

> HOWEVER, that still doesn't fix the following scenario:

This thread should probably be moved to DNSOP because of this very 
important bit:

> - If the RR is first queried by a client that doesn't set the DO bit,
> and is then subsequently queried by a client that DOES set the DO bit,
> then the recursive resolver will return what's in-cache, i.e. the RR
> without the RRSIG.  This would continue to break the use-case 
> described
> here:
>
> https://gitlab.labs.nic.cz/knot/knot-resolver/issues/153
>
> and it would greatly complicate timing of the introduction of the DS
> record for a busy zone that was moving from insecure to secure.  The
> only way to fix that is to set a flag on the cached entry that
> represents whether the DO bit was set when the recursive resolver
> queried the authoritative server and cached the result.  If the flag
> isn't set in the cache and the DO bit was set on a subsequent query by 
> a
> downstream client, then the recursive resolver would have to re-fetch
> the RR with the DO bit set.

And this one:

> This is starting to get complicated as we attempt to get rid of the
> corner cases, and as it currently stands, this optimization makes it
> difficult to time the introduction of new trust anchors and use
> knot-resolver (and Cloudflare DNS) as a forwarder for a validating
> resolver.  (As cool as I think the optimization otherwise is...)

Although the "how" is implementation-dependent, documenting which states 
a validating resolver SHOULD/MUST keep track of is definitely an 
operational practice. And, FWIW, I don't consider what you are 
describing as an "edge case".

--Paul Hoffman