On Tue, Sep 27, 2016 at 3:10 PM, Shumon Huque <shu...@gmail.com> wrote:
> 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 > One other quick comment on the rewrite: " .. (using the DNSSEC records cached as proof)." is a bit unclear and perhaps misplaced. I assume here this means signed NSEC or NSEC3 records, which may or may not exist depending on whether the zone in question is signed. And even if they exist, the resolver typically doesn't return them as proof unless the querier sets DO=1. I think we cover this point further down in the text, which I'll excerpt here: "If the NXDOMAIN response due to a cached non-existence is from a DNSSEC signed zone, then it will have accompanying NSEC or NSEC3 records that authenticate the non-existence of the name. For a descendant name of the original NXDOMAIN name, the same set of NSEC or NSEC3 records proves the non-existence of the descendant name. The iterative, caching resolver MUST return these NSEC or NSEC3 records in the response to the triggering query if the query had the DNSSEC OK (DO) bit set." Re-reading this paragraph, I think I'd suggest explicitly mentioning that the NSEC/NSEC3 signatures must be returned also. -- Shumon Huque
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
