Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

[Edward Lewis <[e-mail]>]

On 9/27/16, 18:46, "Matthew Pounsett" <[e-mail]> wrote:
>Would it be better then to leave early expiry as an implementation choice

I think it comes down to implementer's choice.  The goal of the (IETF in general) documents is interoperability. Whether or not a cache chooses to keep the cached entries or remove them, or the way in which it chooses which of two (or more) valid answers to give doesn't impact interoperability.  So long as the response given is protocol-appropriate.

The issue is, which response (of a set of possible responses) is correct is not definable within the DNS protocol.  So, there's no winner here.

Implementors ought to be aware of choices, but let them choose because they know best what's optimal for their goals.  Well, "ought" might be too strong, implementors just "need" to produce acceptable responses.  If this is over constrained, goodbye innovation.

For me, I'd never think to cull validated entries because of conflicting information and I'd use the routing-area principle of longest match to decide what to return.  But those are whimsical choices.  I can see that some might want to cull, I just don't see spending cycles managing that.

Ultimately, the goal of the draft is to tell a recursive server that if it can conclusively deduce existence of a name from what it has cached, it is allowed to do so.  Today if the conclusion is positive, that's how it is.  The draft proposes to add negative conclusions as well.  Perhaps getting into the details of managing what's in the cache, which is not covered beyond TTL expiry "rules" is causing the wrapping around the axle.  (We are talking about the fairly odd example of there being conflicting data.)

As far as DNSSEC, this only works with DNSSEC in place, right?  You need the missing span proofs or you are NXDOMAIN'ing entire zones, not just entire domains (within a zone).