Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

"White, Andrew" <Andrew.White2@charter.com> Tue, 27 September 2016 19:29 UTC

Return-Path: <Andrew.White2@charter.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDFE12B202 for <dnsop@ietfa.amsl.com>; Tue, 27 Sep 2016 12:29:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 HnbmrHY-P0c2 for <dnsop@ietfa.amsl.com>; Tue, 27 Sep 2016 12:29:00 -0700 (PDT)
Received: from mail.chartercom.com (mail.chartercom.com [24.176.92.28]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B11E312B099 for <dnsop@ietf.org>; Tue, 27 Sep 2016 12:28:59 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="5.30,406,1470718800"; d="scan'208,217"; a="43701081"
Received: from unknown (HELO SC58MEXGP032.CORP.CHARTERCOM.com) ([172.24.253.160]) by mail.chartercom.com with ESMTP; 27 Sep 2016 14:24:06 -0500
Received: from SC58MEXGP032.CORP.CHARTERCOM.COM (172.24.253.160) by SC58MEXGP032.CORP.CHARTERCOM.com (172.24.253.160) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 27 Sep 2016 14:28:58 -0500
Received: from SC58MEXGP032.CORP.CHARTERCOM.COM ([fe80::d63:3f9d:292b:3136]) by SC58MEXGP032.CORP.CHARTERCOM.com ([fe80::d63:3f9d:292b:3136%21]) with mapi id 15.00.1104.000; Tue, 27 Sep 2016 14:28:58 -0500
From: "White, Andrew" <Andrew.White2@charter.com>
To: Shumon Huque <shuque@gmail.com>
Thread-Topic: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt
Thread-Index: AQHSGB1bdhjoj3onHU+w+A+q19myVqCNq0OOgAAC5QCAAFr9gP//sM0w
Date: Tue, 27 Sep 2016 19:28:57 +0000
Message-ID: <59500ec16f1041558d0b9f6646094ebf@SC58MEXGP032.CORP.CHARTERCOM.com>
References: <29B4A430-80C7-44C8-A6FA-54A1560D3FD7@icann.org> <20160927004928.22EAE5515C31@rock.dv.isc.org> <89B42AE2-0377-42A4-B943-E65C52B7CB55@icann.org> <CAHPuVdVneekn9NL_u72KFk7aFQ8uWLkUDqAaW9c46SG-KDVuMg@mail.gmail.com> <d1da7014063b4525a25502408d9fbdc1@SC58MEXGP032.CORP.CHARTERCOM.com> <CAHPuVdVV_fqaiMuLuFKudFaT=FXTKE57+aYuf_HS+x-0OkOk0g@mail.gmail.com>
In-Reply-To: <CAHPuVdVV_fqaiMuLuFKudFaT=FXTKE57+aYuf_HS+x-0OkOk0g@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.24.253.243]
Content-Type: multipart/alternative; boundary="_000_59500ec16f1041558d0b9f6646094ebfSC58MEXGP032CORPCHARTER_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/wSRQnRokrHtKP-G3lnG6yAAYB6w>
Cc: Edward Lewis <edward.lewis@icann.org>, "dnsop@ietf.org" <dnsop@ietf.org>
Subject: Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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, 27 Sep 2016 19:29:02 -0000

Hi Shumon,

True. When a resolver gets an NXDOMAIN for, say x.example.com, would it better to say the resolver SHOULD drop from cache all descendents of x.example.com, or MAY?

It may be computationally expensive to search cache to remove cached NXDOMAIN responses below x.example.com, and I see no harm in letting those cached entries expire as their TTL runs out.

Andrew


NB: This is not official Charter Communications correspondence but rather my personal thoughts.


Andrew White
Desk:  314.394-9594<sip:13143949594>  | Cell:  314-452-4386<sip:1-314-452-4386> | Jabber<sip:andrew.white2@charter.com>
andrew.white2@charter.com<mailto:andrew.white2@charter.com>
Systems Engineer III, DAS DNS group
Charter Communications
12405 Powerscourt Drive<https://goo.gl/maps/AH2PXFKnaGU2>,<http://www.html5zombo.com/> St. Louis,  MO 63131


From: Shumon Huque [mailto:shuque@gmail.com]
Sent: Tuesday, September 27, 2016 2:10 PM
To: White, Andrew
Cc: Edward Lewis; dnsop@ietf.org
Subject: Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

On Tue, Sep 27, 2016 at 2:48 PM, White, Andrew <Andrew.White2@charter.com<mailto:Andrew.White2@charter.com>> wrote:
Hi Shumon,

What about this?

# When an iterative caching DNS resolver receives a response with RCODE being NXDOMAIN,
# the resolver SHOULD store the response in its (negative) cache.  During the time the response
# is cached, any query with a QNAME at or descended from the denied name that is not otherwise
#cached (positively), can be assumed to result in a name error.  Responses to those queries
# SHOULD set RCODE=NXDOMAIN (using the DNSSEC records cached as proof).

When an iterative caching DNS resolver receives a query response with RCODE as NXDOMAIN,
The resolver should store the NXDOMAIN response in cache. During the time that this response
is cached, any query with a QNAME at or descended from the query that resulted in NXDOMAIN
and that is not already in cache can be assumed to result in a name error. Responses to such
queries SHOULD respond with RCODE as NXDOMAIN using DNSSEC records from cache as proof.

Andrew

Andrew - this looks very similar to Ed's rewrite.

The problem I see with both is that it says to reply with NXDOMAIN for all names at or below the cut, except for RRsets already positively cached. But the current draft also allows resolvers to immediately invalidate cached entries below the cut and also return NXDOMAIN for them. Your rewrite appears to remove (or at least not mention) that possibility.

--
Shumon Huque