Thanks, Jinmei. > From: 神明達哉 <jin...@wide.ad.jp> > - Abstract: I suggest revising this on this point (see above): > > responses as well as some level of mitigation of random sub-domain > attacks (referred to as "Water Torture" attacks). > > by either simply removing it or clarifying that it's mitigation for > authoritative servers.
I would like to remain all benefits in the abstract. I will rewrite the sentense as the following. With this proposal, it is expected that performance improvement for recursive servers, reducing garbage traffic to authoritative servers and possible countermeasure of random subdomain attacks. > - Section 3: IMO this section will have to be completely revised in > terms of the selling point. Even if my point about the effect for > recursive server is refused, this section looks still quite awkward > since it reads as if this is *the* problem this proposal tries to > address, while in (e.g.) abstract it rather sounds a weak subset of > the goals. I will move texts from Section 1 Introduction to Section 3 and add three benefits. > - Section 4.2: this may also depend on the goal of the proposal, but > at this moment I don't think this "SHOULD" is fully justified: > > A full-service resolver implementation SHOULD support aggressive use > of NSEC and enable it by default. It SHOULD provide a configuration > knob to disable aggressive use of NSEC. > > If it's just a possible performance improvement for recursive > servers, it should be totally up to the implementors choice. For > other purposes such as (helping) attack mitigation for authoritative > servers or reduce garbage traffic to the root, some stronger > requirement level may make sense, but I'd like to see more empirical > evidence before making the requirement. agree. > - Section 4.5 > > Even if a wildcard is cached, it is necessary to send a query to an > authoritative server to ensure that the name in question doesn't > exist as long as the name is not in the negative cache. The sentence shows current specifications (Section 4.5 of RFC 4035 and previous RFCs). > 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. > - Section 5.1: IMO, this is an example that makes the document fragile > by trying to defend it as an attack mitigation. If we say something > like this: > > This draft proposes that the CD bit may be ignored to support > aggressive negative caching when the full-service resolver is under > attacks with CD bit set. > > It's useless unless we also specify how to detect the resolver is > under an attack. And, if we can reasonably detect that (which I > guess is possible) we might not necessarily need nsec-aggressiveuse > for mitigation. When it's under an attack, other general counter > measures such as rate limiting can be justified and probably > sufficient. My personal suggestion is to stop the idea of defending > it as an attack mitigation, and simply note the implication of the > CD bit as a fact. It will not immediately make this proposal > useless for other general cases, since such queries would be > relatively much rare. I agree. I added "[[ This section may be removed. ]]" and removed the proposal of ignoring CD bit. > - Section 5.2: ditto. I suggest simply removing this section. > > - Section 9: I don't understand this: > > Aggressive use of NSEC/NSEC3 resource records without DNSSEC > validation may cause security problems. > > Specifically what does "without DNSSEC validation" mean? Something > like a case where a validating resolver receives an NSEC/NSEC3 and > uses that information without DNSSEC-validating it? If so, it's > simply invalid per protocol whether the use is "aggressive" or not. > So I don't see the need for stating that here. If this means > something else, I didn't get it and would like to see more > explanation. These parts may be useless. -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
