On 28 September 2016 at 10:29, Shumon Huque <shu...@gmail.com> wrote:
> On Wed, Sep 28, 2016 at 11:39 AM, Matthew Pounsett <m...@conundrum.com> > wrote: > >> >> >> On 28 September 2016 at 06:42, Edward Lewis <edward.le...@icann.org> >> wrote: >> >>> 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 >>> >>> >>> 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.) >>> >>> >> Taking the view that this is only about interoperability, then I would >> say the implementor MAY treat names below the NXDOMAIN response as >> nonexistent, and MAY choose to expire those names early... perhaps with a >> suggestion that this might be the better choice for data coherence, but >> still leave it up to the implementor if they've got a better reason to do >> it otherwise. >> > > The draft (by working group consensus) is written as "SHOULD treat names > below as non-existent", but "MAY continue to answer existing positive > cached entries". I think this managed to cover or at least placate all > positions expressed by working group participants leading up to the last > call. > > I'm not sure we'll get new agreement on your proposed revision. > > I phrased that badly. Since we were on the subject of cached entries already, I assumed that context in my wording. I should have said "MAY treat positively cached names below the NXDOMAIN response as nonexistent, and MAY choose to expire those cached names early." I think that's in keeping with the intent of the current text. There's probably some value in rewording that text though, if it's going to cause confusion for implementors. Maybe invert the text? # When an interative caching DNS resolver receives a response NXDOMAIN, it # SHOULD store it in its negative cache. It MAY choose to immediately remove # from its positive cache any previously cached names at or below the NXDOMAIN # response. If the cached entries below the NXDOMAIN response are not # removed, it MAY choose to continue to answer positively for those names # until the cached entries expire. # The resolver SHOULD treat all other names at or below NXDOMAIN response as # nonexistant and SHOULD respond negatively to queries for such names.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
