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

Mark Andrews <marka@isc.org> Tue, 14 July 2015 03:04 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B34B31A8A1A for <dnsop@ietfa.amsl.com>; Mon, 13 Jul 2015 20:04:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oq7Zj7rAaxwe for <dnsop@ietfa.amsl.com>; Mon, 13 Jul 2015 20:04:02 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8CC21A8A17 for <dnsop@ietf.org>; Mon, 13 Jul 2015 20:04:01 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.ams1.isc.org (Postfix) with ESMTPS id A3D9F1FCAD0; Tue, 14 Jul 2015 03:03:22 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id B7B3C160052; Tue, 14 Jul 2015 03:04:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A6C8916005A; Tue, 14 Jul 2015 03:04:13 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id RXpqr1Km_Bz9; Tue, 14 Jul 2015 03:04:13 +0000 (UTC)
Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id 5CA66160052; Tue, 14 Jul 2015 03:04:13 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 6BEFF32DCCE5; Tue, 14 Jul 2015 13:03:18 +1000 (EST)
To: shuque@gmail.com
From: Mark Andrews <marka@isc.org>
References: <20150310.191541.52184726.fujiwara@jprs.co.jp> <20150707.182043.193693838.fujiwara@jprs.co.jp> <CAJE_bqcRQH0WGTaLqtMSuiOty4KHe9nN6T-wmqf3x_ohuA6TcA@mail.gmail.com> <CAHPuVdU-1e_7KPH9JdSvbPn-tYptaXbHrQvQz=UEv+QJdseJxw@mail.gmail.com>
In-reply-to: Your message of "Mon, 13 Jul 2015 22:01:29 -0400." <CAHPuVdU-1e_7KPH9JdSvbPn-tYptaXbHrQvQz=UEv+QJdseJxw@mail.gmail.com>
Date: Tue, 14 Jul 2015 13:03:18 +1000
Message-Id: <20150714030318.6BEFF32DCCE5@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/nFkh3CF9dNHxVddOmBiUb2Mvxrc>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jul 2015 03:04:03 -0000

In message <CAHPuVdU-1e_7KPH9JdSvbPn-tYptaXbHrQvQz=UEv+QJdseJxw@mail.gmail.com>
, Shumon Huque writes:
> 
> On Fri, Jul 10, 2015 at 2:53 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinm=
> ei@wide.ad.jp> wrote:
>
> > On Tue, Jul 7, 2015 at 2:20 AM,  <fujiwara@jprs.co.jp> wrote:
> > [...]
> > 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.
> >
>
> That's indeed the literal meaning of NXDOMAIN, but it turns out most
> current resolver implementations don't treat it that way. The wording in
> RFC2308, Section 5 is not entirely precise, but it seems to say that
> negative answers should be cached only for the exact qname, and not
> (necessarily) for anything below it.

Because the consensus at the time was not to support nxdomain
synthesis from signed zone (speaketh the author of RFC 2308).

Extreme care needs to be taken with nxdomain synthesis. You need
to choose the correct NSEC records especially for qnames which are
the subdomain of the NSEC owner name.  The NS bit MUST NOT be set
in this case as the presence of the NS bit indicates a delegation.

NSEC3 is even more complicted.

DLV is only defined to use NSEC signed zones as I wasn't interested
in having to working out all the rules for NSEC3.

> Section 3 of http://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00
> ("Stopping Downward Cache Search on NXDOMAIN") proposed to fix this
> resolver behavior. It would be great if this was standardized and adopted.
>
> 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.
> >
>
> Yes, this will certainly be a very beneficial result of qname
> minimization.
>
> Shumon.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org