At Mon, 09 May 2016 19:46:01 +0900 (JST), fujiw...@jprs.co.jp wrote: > >> > When aggressive use is enabled, regardless of description of > >> > Section 4.5 of [RFC4035], it is possible to send a positive response > >> > immediately when the name in question matches a NSEC/NSEC3 RRs in the > >> > negative cache. > >> > > >> > I don't understand the second paragraph. I also don't understand > >> > how the first paragraph is related to the second. I'm not sure if > >> > it's only me, but I'd like to see more explanation here. > >> > >> The second sentence shows the aggressive use of ... changed the first > >> paragraph. > > > > I still don't get it here. Can you perhaps show a specific example of > > "send a positive response immediately when the name in question > > matches a NSEC/NSEC3 RRs in the negative cache."? Especially about > > how "a positive response" is derived from negative cache information? > > I will update the part to be expressed well. > > If nonexistence of a domain name is proved and there is a matching > wildcard for the domain name, then the domain name matches the wildcard.
Ah, okay, now I see it. I think there's some logical gap here, which I believe could be improved through some wording change: - the last paragraph of RFC 4035 Section 4.5 talks about aggressive use of a cached deduced wildcard (as well as aggressive use of NSEC) but rather recommends not to rely on it. - just like the case for the aggressive use of NSEC discussed in this draft, we could revisit this recommendation. as long as the recursive server knows a name would not exist without the wildcard match, it could answer a query for that name using the cached deduced wildcard, and it may be justified for performance and other benefits. (Note that, so far, this is orthogonal to "when aggressive use (of NSEC) is enabled"). - *Furthermore* when aggressive use of NSEC is enabled, the aggressive use of cached deduced wildcard will be more effective as the aggressive NSEC use helps prove more names wouldn't exist without the wildcard through fewer external queries. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
