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

Edward Lewis <edward.lewis@icann.org> Wed, 28 September 2016 13:42 UTC

Return-Path: <edward.lewis@icann.org>
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 5EA0E12B446 for <dnsop@ietfa.amsl.com>; Wed, 28 Sep 2016 06:42:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.517
X-Spam-Level:
X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, 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 mmCu6kpgC6zJ for <dnsop@ietfa.amsl.com>; Wed, 28 Sep 2016 06:42:22 -0700 (PDT)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71C5D12B430 for <dnsop@ietf.org>; Wed, 28 Sep 2016 06:42:22 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 28 Sep 2016 06:42:20 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Wed, 28 Sep 2016 06:42:20 -0700
From: Edward Lewis <edward.lewis@icann.org>
To: Matthew Pounsett <matt@conundrum.com>, "White, Andrew" <Andrew.White2@charter.com>
Thread-Topic: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt
Thread-Index: AQHSGB1bdhjoj3onHU+w+A+q19myVqCMgefvgAFQ3YCAAE3HAIAABBwAgAAGBYCAAAU5gIAANyIAgAC3TIA=
Date: Wed, 28 Sep 2016 13:42:19 +0000
Message-ID: <8C58EBA8-E10B-4CBA-A27F-78B483DB2A48@icann.org>
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> <59500ec16f1041558d0b9f6646094ebf@SC58MEXGP032.CORP.CHARTERCOM.com> <CAAiTEH-_mefMBTKSu8G0mT7rO=GzQk0Bn1tKYcgCsa2pLhutuw@mail.gmail.com>
In-Reply-To: <CAAiTEH-_mefMBTKSu8G0mT7rO=GzQk0Bn1tKYcgCsa2pLhutuw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1a.1.160916
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.47.236]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3557900539_1988189847"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/FQhI9CzUsIPxoxb4PzxSyhMDNHg>
Cc: "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: Wed, 28 Sep 2016 13:42:26 -0000

On 9/27/16, 18:46, "Matthew Pounsett" <matt@conundrum.com> wrote:
>Would it be better then to leave early expiry as an implementation choice

I think it comes down to implementer's choice.  The goal of the (IETF in general) documents is interoperability. Whether or not a cache chooses to keep the cached entries or remove them, or the way in which it chooses which of two (or more) valid answers to give doesn't impact interoperability.  So long as the response given is protocol-appropriate.

The issue is, which response (of a set of possible responses) is correct is not definable within the DNS protocol.  So, there's no winner here.

Implementors ought to be aware of choices, but let them choose because they know best what's optimal for their goals.  Well, "ought" might be too strong, implementors just "need" to produce acceptable responses.  If this is over constrained, goodbye innovation.

For me, I'd never think to cull validated entries because of conflicting information and I'd use the routing-area principle of longest match to decide what to return.  But those are whimsical choices.  I can see that some might want to cull, I just don't see spending cycles managing that.

Ultimately, the goal of the draft is to tell a recursive server that if it can conclusively deduce existence of a name from what it has cached, it is allowed to do so.  Today if the conclusion is positive, that's how it is.  The draft proposes to add negative conclusions as well.  Perhaps getting into the details of managing what's in the cache, which is not covered beyond TTL expiry "rules" is causing the wrapping around the axle.  (We are talking about the fairly odd example of there being conflicting data.)

As far as DNSSEC, this only works with DNSSEC in place, right?  You need the missing span proofs or you are NXDOMAIN'ing entire zones, not just entire domains (within a zone).