At Wed, 16 Mar 2016 14:41:36 +0100, Stephane Bortzmeyer <bortzme...@nic.fr> wrote:
> > > you have to do the "rm -rf $qname" when you receive the nxdomain. > > > > The draft says you have to do this, yes. > > No, it does not. draft-vixie-dnsext-resimprove-00 did but > draft-ietf-dnsop-nxdomain-cut-01 does not. You may disagree with the > contents but, please, do not misrepresent what's in the draft. In my understanding the latest major concern is about the first paragraph of Section 2: When an iterative caching DNS resolver receives a response NXDOMAIN, it SHOULD store it in its cache and all names and RRsets at or below that node SHOULD then be considered to be unreachable. Subsequent queries for such names SHOULD elicit an NXDOMAIN response. and specifically when the caching resolver has already cached a positive answer for a subdomain (e.g., sub.example.com) of the owner name (e.g. example.com) of the NXDOMAIN answer. If the caching resolver needs to be compliant to the SHOULD of the last sentence, it will need to check whether there's a super domain of sub.example.com that is cached with NXDOMAIN on receiving a query for sub.example.com (and it will need to return NXDOMAIN without involving other external queries). In a sense that could be interpreted as a delayed form of 'rm -rf *.example.com'. But in any event, I suspect that the main objection is about the requirement of applying this SHOULD in such cases because of the additional search overhead. It may be just for convenience of a particular set of implementations and we might dismiss the objection as such. But on the other hand I don't see a strong reason for not being lenient in this case. Allowing the already cached positive answer for sub.example.com doesn't cause additional external queries; in either case the query is answered immediately from the cache but the answer just happens to be positive instead of NXDOMAIN. Personally I don't think it's that harmful. After all we can't even be sure if the NXDOMAIN is really the newer information just because it arrives after the positive answer. So, if this makes some implementors happier I think it's worth considering. On the other hand, if it's about what the resolver should do when sub.example.com hasn't been cached while there's cached NXDOMAIN for example.com, arguments such as DoS mitigation can apply and it can be more controversial. But my latest impression in this thread is that everyone is basically okay to follow the SHOULD in this case. So I wonder: should we as wg keep requiring the SHOULD for the already cached subdomains or can we loosen the requirement specifically for that case? -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
