On 27 September 2016 at 12:28, White, Andrew <andrew.whi...@charter.com> wrote:
> Hi Shumon, > > > > True. When a resolver gets an NXDOMAIN for, say x.example.com, would it > better to say the resolver SHOULD drop from cache all descendents of > x.example.com, or MAY? > > > > It may be computationally expensive to search cache to remove cached > NXDOMAIN responses below x.example.com, and I see no harm in letting > those cached entries expire as their TTL runs out. > Would it be better then to leave early expiry as an implementation choice, and instead say that the implementation SHOULD respond with NXDOMAIN for any QNAME at or below a cached NXDOMAIN? # When an iterative caching DNS resolver receives a response with RCODE being # NXDOMAIN, the resolver SHOULD store the response in its (negative) cache. # During the time the response is cached, any query with a QNAME at or # descended from the denied name SHOULD be assumed to result in a name error. # Responses to those queries SHOULD set RCODE=NXDOMAIN (using the DNSSEC # records cached as proof). Any names at or below the name received in the # NXDOMAIN response MAY be flushed from cache at the time the response is # received. If foo.bar.example.org has a cached record, and an nxdomain for bar.example.org is then cached, further queries for foo.bar.example.org would also trigger NXDOMAIN for as long as bar.example.org is in the negative cache. If the negative response for bar.example.org expires before the positive response for foo.bar.example.org, then that name could pop up in positive responses again... if the implementation hasn't chosen to expire it as well. My rationale is that if foo.bar.example.org were still a valid name at the time that the bar.example.org NXDOMAIN response was issued, then NXDOMAIN was not the correct response. It would be inappropriate to answer for foo.bar.example.org out of the cache in that case.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
