In message <caje_bqckdfhnjdvxw_a6n+w27calo8jeqxwjjfx29rbh1r_...@mail.gmail.com> , =?UTF-8?B?56We5piO6YGU5ZOJ?= writes: > 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.
It is a SHOULD not a MUST. Having a existing cache entry is a reasonable exception to the SHOULD. Or we could add "except when there is a existing cache entry indicating data existed at one of the names between the cached NXDOMAIN indication and the current QNAME". This however may lead to more discussions about the costs of testing for this. Or we could add "There may be a cached name with data between the cached NXDOMAIN and the current QNAME or at the current QNAME. It is implementation specific if this prevents the NXDOMAIN being returned due to the cached NXDOMAIN." Mark > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
