On Tue, Sep 27, 2016 at 2:48 PM, White, Andrew <andrew.whi...@charter.com> wrote:
> Hi Shumon, > > > What about this? > > > > # 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 > that is not otherwise > > #cached (positively), can be assumed to result in a name error. Responses > to those queries > > # SHOULD set RCODE=NXDOMAIN (using the DNSSEC records cached as proof). > > > > When an iterative caching DNS resolver receives a query response with > RCODE as NXDOMAIN, > > The resolver should store the NXDOMAIN response in cache. During the time > that this response > > is cached, any query with a QNAME at or descended from the query that > resulted in NXDOMAIN > > and that is not already in cache can be assumed to result in a name error. > Responses to such > > queries SHOULD respond with RCODE as NXDOMAIN using DNSSEC records from > cache as proof. > > > > Andrew > Andrew - this looks very similar to Ed's rewrite. The problem I see with both is that it says to reply with NXDOMAIN for all names at or below the cut, except for RRsets already positively cached. But the current draft also allows resolvers to immediately invalidate cached entries below the cut and also return NXDOMAIN for them. Your rewrite appears to remove (or at least not mention) that possibility. -- Shumon Huque
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
