On Thu, Oct 6, 2016 at 7:18 AM, Tony Finch <d...@dotat.at> wrote: > I have read through the draft and sent a pull request with some minor > editorial fixes.
Thank you. These have been accepted / incorporated. > > Here are some more substantial suggestions / questions. Sorry for being so > late in the process. > No apologies needed, thanks for feedback. > > Would it make sense to be more specific about how to match queries to" > cached NSEC/NSEC3 records? By cross-referencing to the relevant part of > the NSEC and NSEC3 specs, rather than repeating. Yup! > > The draft seems to imply that only one NSEC record is needed for denial of > existence, and that wildcards are only problematic for NSEC3 - but > wildcards can also trip up NSEC, if the covering NSEC does not also cover > a relevant wildcard. > > eg (modified text) ... > > 5.1. NSEC > > Implementations which support aggressive use of NSEC SHOULD enable > this by default. Implementations MAY provide a configuration switch > to disable aggressive use of NSEC and allow it to be enabled or > disabled per domain. > > The validating resolver needs to check the existence of an NSEC RR > matching/covering the source of synthesis and an NSEC RR covering the > query name. > > If denial of existance can be determined according to the rules set out > in RFC 4035 section 5.4, using NSEC records in the cache, then the > resolver can immediately return an NXDOMAIN or NODATA response. DONE. Thank you for providing text. It certainly makes it easier to understand / address comments. > > 5.2. NSEC3 > > A validating resolver implementation MAY support aggressive use of > NSEC3. If it does aggressive use of NSEC3, it MAY provide a > configuration switch to disable aggressive use of NSEC3 and allow it > to be enabled or disabled for specific zones. > > NSEC3 aggressive negative caching is more difficult. If the zone is > signed with NSEC3, the validating resolver needs to check the > existence of non-terminals and wildcards which derive from query > names. > > If denial of existance can be determined according to the rules set out > in RFC 5155 sections 8.4, 8.5, 8.6, 8.7,, using NSEC3 records in the > cache, then the resolver can immediately return an NXDOMAIN or NODATA > response. DONE. Thank you -- I reordered / reworded things slightly to make it flow somewhat better, but it is basically still your text. > > > TTLs > > Both NSEC and NSEC3 records are supposed to have a TTL matching the SOA > MINIMUM field. This is not quite the same as RFC 2308 negative cache entry > TTL, which is the minimum of the SOA MINIMUM and SOA TTL. > > Should there be text along the lines of: ... probably :-) > > 5.3. Consideration on TTL > > The TTL value of negative information is especially important, > because newly added domain names cannot be used while the negative > information is effective. > > Section 5 of RFC 2308 states that the maximum number of negative cache > TTL value is 3 hours (10800). It is RECOMMENDED that validating > resolvers limit the maximum effective TTL value of negative responses > (NSEC/NSEC3 RRs) to this same value. > > Section 5 of RFC 2308 also states that a negative cache entry TTL > is taken from the minimum of the SOA.MINIMUM field and SOA's TTL. > This can be less than the TTL of an NSEC or NSEC3 record, since their > TTL is equal to the SOA.MINIMUM field. (See RFC 4035 section 2.3 and > RFC 5155 section 3.) > > A resolver that supports aggressive use of NSEC and NSEC3 should reduce > the TTL of NSEC and NSEC3 records to match the TTL of the SOA record in > the authority section of a negative response, if the SOA TTL is > smaller. DONE. This is great. I used your text, thank you. > > Wildcards > > Should the box in section 7 say "positive responses" instead of "negative > responses"? > > If so, there should probably also be a cross-ref to RFC 4035 section 5.3.4 > and RFC 5155 section 8.8 which both discuss validating positive wildcard > responses. Similar to my suggestions for 5.1 and 5.2 above. I can provide > text if you want. NOT DONE. Yes please. That would be awesome! I had removed Section 7 (Wildcards) because I thought that that was what the WG wanted, but I apparently misjudged that. I have now put it back, and tried to reconcile the positive and negative test, but do not have any text like the above. I'd really appreciate some! I have put beck the original Wildcard text, and am committing it to GitHub. I will then try address the original wording issues which made me remove it in the first place... > > > Security Considerations > > This should mention the impact of replay attacks. Something like, > > Although the TTL of NSEC/NSEC3 records is typically fairly short > (minutes or hours), their RRSIG expiration time can be much > further in the future (weeks). An attacker who is able to > successfully spoof responses might poison a cache with old > NSEC/NSEC3 records. If the resolver is NOT making aggressive use > of NSEC/NSEC3, the attacker has to repeat the attack for every > query. If the resolver IS making aggressive use of > NSEC/NSEC3, one successful attack would be able to suppress many > queries for new names, up to the negative TTL. > DONE. Excellent. Incorporated. Thank you. Thank you, I really appreciate everyone's assistance. W > > Tony. > -- > f.anthony.n.finch <d...@dotat.at> http://dotat.at/ - I xn--zr8h punycode > Wight, Portland, Plymouth: East 5 to 7, occasionally 4 later. Moderate or > rough. Showers later. Good. -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
