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

Matthew Pounsett <matt@conundrum.com> Wed, 28 September 2016 15:39 UTC

Return-Path: <matt@conundrum.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 0F2AC12B1CB for <dnsop@ietfa.amsl.com>; Wed, 28 Sep 2016 08:39:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=conundrum-com.20150623.gappssmtp.com
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 oQPn6UeCXtnI for <dnsop@ietfa.amsl.com>; Wed, 28 Sep 2016 08:39:36 -0700 (PDT)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80DD812B1C4 for <dnsop@ietf.org>; Wed, 28 Sep 2016 08:39:36 -0700 (PDT)
Received: by mail-qk0-x231.google.com with SMTP id g67so50864576qkd.0 for <dnsop@ietf.org>; Wed, 28 Sep 2016 08:39:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3ml33rOCbpR/PL19c32Gu3kitMW1SmIFpT/7DF1ZvoU=; b=E/m4WbAciwst5p2TZgrbGiEU6zSt6pfdEtW2O4hsTxCwejIzLzwCgHOOgOqGNGFar7 TgYQ7mpf90N4sshdhEME0/92lQVHQMMpvzEDuPcvmS+YbOwc6K2eQXLhvytpjRA65FtL 3ii8CyZCtIl3SsGjbfRDEXvfdgxy+0d8icoAXurrhg4yB+UI/2ZhHedIhAsCjGweoB04 gbOGCLmb9iGusmS3fbCsaPSylZBhozlVAjYDl5cTm79tM3xrZ1KqtI6XgF5P7A5WRvx2 FEka2I2sKULMfU9Yj4vgEGtD+XS59nxHttmrfX2XUY/gU99jhsIX+NhdaTLTLZdd42dD mCjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3ml33rOCbpR/PL19c32Gu3kitMW1SmIFpT/7DF1ZvoU=; b=X96pGpvxItN3zAX+TKvXecbqcD6vdue9z44ohKORgiAW6yVQ7bs8L0flq+kvUl89Mz G7XavSHbr4Jg8sgNuGCUz5+xZFPkrPEthEKTTpZe6bq2LLpbn+QcLcps5ufy3xNEIBE7 Slu1+ARusaqSAca72NuNWAyZ+a7AGDt8Y+lWeCC4hfCikyMjuq/2F8l1TxGaHOokv27f f/psgZ+/vJr3DWDgBRDg+pieW2hFR1B3XQMcFL4lJsSmkVm8Y/Fxva6iS+ttn1KDZyQV nBmeewdyvO9qiMG0cV67x+wIZdClbtv4MLMhvRTyQgCSjWGX+h4VINa+eCZi3HjJngTb vRAQ==
X-Gm-Message-State: AA6/9Rn+TlfV/Ua5KY82y2KG0lK1lsg+vHpADXPuF0Qjn7ZgKgkp1euSmHMXppEhpyOpkO685Yr8cjFDl7N00g==
X-Received: by 10.55.128.129 with SMTP id b123mr32841780qkd.322.1475077175699; Wed, 28 Sep 2016 08:39:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.35.197 with HTTP; Wed, 28 Sep 2016 08:39:35 -0700 (PDT)
X-Originating-IP: [69.64.144.72]
In-Reply-To: <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> <8C58EBA8-E10B-4CBA-A27F-78B483DB2A48@icann.org>
From: Matthew Pounsett <matt@conundrum.com>
Date: Wed, 28 Sep 2016 08:39:35 -0700
Message-ID: <CAAiTEH-Ldy-X_2RcSEPvzEAYENQFLLUNnP7P=ytmbC7+V+bOAw@mail.gmail.com>
To: Edward Lewis <edward.lewis@icann.org>
Content-Type: multipart/alternative; boundary=94eb2c06652e12fc6c053d932beb
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/CKop-CxksbaZLT06r8OQirKHUGQ>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>, "White, Andrew" <Andrew.White2@charter.com>
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 15:39:41 -0000

On 28 September 2016 at 06:42, Edward Lewis <edward.lewis@icann.org> wrote:

> 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
>
>
> 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.)
>
>
Taking the view that this is only about interoperability, then I would say
the implementor MAY treat names below the NXDOMAIN response as nonexistent,
and MAY choose to expire those names early... perhaps with a suggestion
that this might be the better choice for data coherence, but still leave it
up to the implementor if they've got a better reason to do it otherwise.