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

Shumon Huque <shuque@gmail.com> Thu, 29 September 2016 11:28 UTC

Return-Path: <shuque@gmail.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 81A8112B429 for <dnsop@ietfa.amsl.com>; Thu, 29 Sep 2016 04:28:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 yzzOG-jgOh_C for <dnsop@ietfa.amsl.com>; Thu, 29 Sep 2016 04:28:39 -0700 (PDT)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 D04BC12B417 for <dnsop@ietf.org>; Thu, 29 Sep 2016 04:28:38 -0700 (PDT)
Received: by mail-wm0-x234.google.com with SMTP id b130so126196539wmc.0 for <dnsop@ietf.org>; Thu, 29 Sep 2016 04:28:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PghnOrlhBzty/yu3MKkPY8P2blhxDbx+PW1yLVgws0Q=; b=xt9F+Qh2V/sNM0C6Q5Yu9zWZpnUmYndyeulGxkzHksr22firT49rop9Awdsf1SmXIH Ilj5fut63/aDYAG5Yq3aefe66X+46c8hen/s1CIlxOnleIFNPl4Db/9+RkUuc4C083vP lXQpIWsis49GrCubvRpta0LjxJ7gsoC9dRPhlHw/k3UdZPhUqEgrREbPnqhIrhm3bZy2 67L5nDaRy5xU2PJEbNUUEr7cM6eWyJNbizYf7V+pcZ+sIrzur8BttPcvJYxOrGjyr1UG bJu4yhvJ2IX7Aj4BICavdCvmRdS6ZkaXLI01zkYacnRetUam2tm6UMWVVdG7ASJStjD0 3wLQ==
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=PghnOrlhBzty/yu3MKkPY8P2blhxDbx+PW1yLVgws0Q=; b=Rwll5WH5NreSm+bl19LIECkAA3vfFGpzY8aBzWEoyv49uwI5zTkZ8zw3ARQgaSzhEL wWSqXBu9gJ6bhHSZVBw6uqQhwLwHyEtZ1Td8VnYKZJfo5uSlVTxnCzfYF5jZzCOwCb4y DI5vxPX9nmlVA2ZY0XLl7ptwgfUCan+byYy9mLDDZhWffV1y6IJS+nbZyze5WnXWRVCu GKCQGJsNIkHru0uIR3H4edxUPkR9ADfgcPWEF4fmQhey67qisiR2GoXYC5sUXGz6F6PK pDpn3+HRM61w1zYxrd5VwJ1y+uU0mBllNIm/zDDyQYYmRDAkzHeme9MmPCF9KD2SzEDG Mzow==
X-Gm-Message-State: AA6/9Rk4/wIabtQsg9JRgbBAN1jVi1t0opx4IWd3xlUz84thoVnWB9ghCvCpvp51HF0x48xPxt5Sam8acq4SXw==
X-Received: by 10.28.101.214 with SMTP id z205mr13562644wmb.123.1475148517288; Thu, 29 Sep 2016 04:28:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.165.168 with HTTP; Thu, 29 Sep 2016 04:28:36 -0700 (PDT)
In-Reply-To: <CAAiTEH9E1qd87hR5ebz4445KB5T2wP_k22Kjr800sy40Zda1dw@mail.gmail.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> <59500ec16f1041558d0b9f6646094ebf@SC58MEXGP032.CORP.CHARTERCOM.com> <CAAiTEH-_mefMBTKSu8G0mT7rO=GzQk0Bn1tKYcgCsa2pLhutuw@mail.gmail.com> <8C58EBA8-E10B-4CBA-A27F-78B483DB2A48@icann.org> <CAAiTEH-Ldy-X_2RcSEPvzEAYENQFLLUNnP7P=ytmbC7+V+bOAw@mail.gmail.com> <CAHPuVdW=mK+spnGE-iaB8N50sHe=+nn8uPTqx+EdJigMMWLAoA@mail.gmail.com> <CAAiTEH9E1qd87hR5ebz4445KB5T2wP_k22Kjr800sy40Zda1dw@mail.gmail.com>
From: Shumon Huque <shuque@gmail.com>
Date: Thu, 29 Sep 2016 07:28:36 -0400
Message-ID: <CAHPuVdXdNj0BQm=qhxmOubMDW+L6NJwj3_Kwfcwu1ma++0E=xw@mail.gmail.com>
To: Matthew Pounsett <matt@conundrum.com>
Content-Type: multipart/alternative; boundary=001a114b317c5d3399053da3c79e
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/HVLG0e02hAra77Ub8-LCa5v5vmI>
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: Thu, 29 Sep 2016 11:28:41 -0000

On Wed, Sep 28, 2016 at 2:37 PM, Matthew Pounsett <matt@conundrum.com>
wrote:

>
>
> On 28 September 2016 at 10:29, Shumon Huque <shuque@gmail.com> wrote:
>
>> On Wed, Sep 28, 2016 at 11:39 AM, Matthew Pounsett <matt@conundrum.com>
>> wrote:
>>
>>>
>>>
>>> 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.
>>>
>>
>> The draft (by working group consensus) is written as "SHOULD treat names
>> below as non-existent", but "MAY continue to answer existing positive
>> cached entries". I think this managed to cover or at least placate all
>> positions expressed by working group participants leading up to the last
>> call.
>>
>> I'm not sure we'll get new agreement on your proposed revision.
>>
>> I phrased that badly.  Since we were on the subject of cached entries
> already, I assumed that context in my wording.   I should have said "MAY
> treat positively cached names below the NXDOMAIN response as nonexistent,
> and MAY choose to expire those cached names early."  I think that's in
> keeping with the intent of the current text.
>
> There's probably some value in rewording that text though, if it's going
> to cause confusion for implementors.  Maybe invert the text?
>
> # When an interative caching DNS resolver receives a response NXDOMAIN, it
> # SHOULD store it in its negative cache.  It MAY choose to immediately
> remove
> # from its positive cache any previously cached names at or below the
> NXDOMAIN
> # response.  If the cached entries below the NXDOMAIN response are not
> # removed, it MAY choose to continue to answer positively for those names
> # until the cached entries expire.
>
> # The resolver SHOULD treat all other names at or below NXDOMAIN response
> as
> # nonexistant and SHOULD respond negatively to queries for such names.
>
>
I'll wait first for others to weigh in on your proposed rewrite.

-- 
Shumon Huque