At Wed, 3 Aug 2016 13:32:56 -0700, Warren Kumari <[email protected]> wrote:
> We have updated this document with comments and feedback from Berlin. > We have also gone through and done another editing pass, removing a > significant amount of text which was intended to drive the discussion, > but would not really be useful in a published RFC. > > Please review it, we believe that the document is ready (or almost > ready) for WGLC. I see draft-ietf-dnsop-nsec-aggressiveuse-01 has been improved a lot. Some comments on this version: - general: there still seem to be a (IMO) misleading claim as if this technique were a strong mitigation against DoS attacks rather than a possible performance optimization. I'll point out some specific cases below, but independently from whether/how to address these points, we might want to follow the style of draft-ietf-dnsop-nxdomain-cut-04. It has a dedicated section (sec 4) that discusses the benefit, and mentions its attack mitigation effect as a secondary benefit. I think the same logic applies to nsec-aggressiveuse. - general: I suggest removing/rephrasing the phrase "full-service resolver". As far as I understand it, nsec-aggressiveuse is totally irrelevant to whether the resolver is "full-service" (which I interpret as performing recursive resolution from the root) or not. The only critical point for it to work is that the resolver has/uses cache and it performs DNSSEC validation. As long as a resolver meets this condition, nsec-aggressiveuse should be equally usable/effective even if it only uses an external forwarder. Since the use of cache is probably too obvious, a better terminology would be "validating resolver". - general: I wonder whether we also want to use NSEC/NSEC3 for NOERROR-NODATA type of negative cache information. - Abstract This increases resilience to DoS attacks, increases performance / decreases latency, decreases resource utilization on both authoritative and recursive servers, and also increases privacy. I suggest rephrasing it to be less misleading, e.g., This increases performance / decreases latency, decreases resource utilization on both authoritative and recursive servers, and also increases privacy. [It may also help increase resilience to DoS attacks to some extent.] The second sentence could simply be removed, but I added it in case if we really want to say something about it in the abstract. - Section 1 [...] This method of negative caching requires exact matching; this leads to unnecessary additional lookups, which have negative implications for DoS survivability, increases latency, leads to extra resource utilization on both authoritative and recursive servers, and decreases privacy by leaking queries. I suggest removing "which have negative implications for DoS survivability" to be less misleading. - Section 5.2 [...] It SHOULD provide a configuration switch to disable aggressive use of NSEC and allow it to be enabled or disabled for specific zones. I suggest s/specific zones/specific domains/ since it's not trivial for a recursive server operator to know whether a particular domain name is a zone apex or not at the time of configuring the server. - Section 5.4 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. This text seems to be derived from a prior review comment of mine, which was a bit too casual. I suggest revising this part as follows: and it may be justified for performance and other benefits. Such aggressive use of cached deduced wildcard can be employed independently from aggressive use of NSEC. But, it will be more effective when both are enabled since the resolver can determine the name subject to wildcard would not otherwise exist more efficiently. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
