On 9/27/16, 18:46, "Matthew Pounsett" <m...@conundrum.com> 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).

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to