On Tue, Jul 7, 2015 at 2:20 AM, <fujiw...@jprs.co.jp> wrote: > Akira Kato and I submitted draft-fujiwara-dnsop-nsec-aggressiveuse-01. > > https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-nsec-aggressiveuse/ > > * Added reference to DLV {{RFC5074}} and imported some sentences. > * Added Aggressive Negative Caching Flag idea. > * Added detailed algorithms in Appendix. > > Please check and comment.
The primarily intended benefit of this approach seems to mitigate a DoS attack on a resolver (e.g., according to Section 3). But I'm skeptical about the effectiveness in that context: for this mitigation to work the zone in question needs to be DNSSEC-signed. But an attacker would be easily able to find unsigned zone to use for the attack, and they could even set up an unsigned zone they can control. Also, an equally effective attack is possible without relying non-existent names: an attacker would only find some wildcard name and send random queries that match the wildcard. So, if the proposed approach is really effective to "random (non-existent) sub-domain attacks", attackers would simply move to a variant of it that would still work. So, in the end, a resolver would still employ counter measures like rate limiting (which will work for both types of random name attacks, and will work for unsigned zones), and, if it's reasonably effective, the defense using "nsec-aggressiveuse" won't be that promising. That said, I wouldn't necessarily be opposed to the idea itself. It might still be some nice-to-have optimization for resolver performance, and if so, it's probably worth pursing. In Introduction it states: While negative (non-existence) information of DNS caching mechanism has been known as DNS negative cache [RFC2308], it requires exact matching in most cases. [...] This was because the NXDOMAIN response just says there is no such name "a.example.com" and it doesn't tell anything for "b.example.com". While I see what it tries to say and don't disagree with it, I think this is not very accurate. In fact, NXDOMAIN for "a.example.com" says there is no such name *or any subdomain of it*. So it would still be usable to suppress unnecessary external query for, e.g., foo.a.example.com. Regarding Section 5 (possible side effect on root servers), I wonder about the implication of qname-minimization (which I expect will be deployed much sooner than this proposal). A resolver that supports qname-minimization would first send a query to "local." to the root server upon receiving a "foo.local" query, and cache the result of NXDOMAIN for "local.". It will suppress subsequent external queries for any subdomain of it. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
