Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt

[神明達哉 <[e-mail]>]

On Tue, Jul 7, 2015 at 2:20 AM,  <[e-mail]> 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