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

Matthew Pounsett <matt@conundrum.com> Wed, 28 September 2016 18:38 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 DD40112B09F for <dnsop@ietfa.amsl.com>; Wed, 28 Sep 2016 11:38:00 -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 uEX8oNmW7PyU for <dnsop@ietfa.amsl.com>; Wed, 28 Sep 2016 11:37:58 -0700 (PDT)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 F1B9512B012 for <dnsop@ietf.org>; Wed, 28 Sep 2016 11:37:57 -0700 (PDT)
Received: by mail-qk0-x230.google.com with SMTP id j129so48066038qkd.1 for <dnsop@ietf.org>; Wed, 28 Sep 2016 11:37:57 -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=j3jyJaN/M73vhKfA3rbZrFIkOAZ6JGUFuMkomDIIkDc=; b=mAUl+jmqSkRfCBWgp80wHZwOHATX1aygs7u1lsOBSkNcmui87cwfIswNCWj21oAvgG CyVo0wI8mw+li6Ww0jYS66lon38rCAXPA8KYaHiyLqq+z7iLCE1HP+iN9xpTAjpYVo6g rSw9MI9iNQV4rHHasrdm5YTM5XJagGc4/eIM5N4c5MHZfA+tAIFhMnuVbp08tyhGb7an aTI7hbDDDlSSemoVhGkL+BW0xZv9YUyxDq2SEyVaBul/Zkv+XS4HeVPmqa5IYNsilUfL YETA5EqGaEvkOchkQp6NHH9TZVa7e4fWi15p6R35DJOIVsl34a8erFUZIL7rMtEpFrQi K48g==
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=j3jyJaN/M73vhKfA3rbZrFIkOAZ6JGUFuMkomDIIkDc=; b=j4xnVIwLAmOFIFYbGUtiCdu6tZ9KpaHbGi5whaIOAgjjpEzos32jSv1fzT4L9PBOkF Zk0O8qsE+led62hXA/SXgBhRa67ggahMT4Ku3eRK7VhKYWMu2yydTlJZTKlfBZbfTBGr EJYUoVMQ9DW6p14JUEaNpMyEQ2nwot1ZUBxuN7CXyW5ablC6VZtLteOCgDBBnwd9Du35 ZKZzw6H72FYCfjkFnw47islLBdV+pJFMDd3IS380c1spnL0SujhjBnjMa/z9JUI0WBT5 au9z3Jij+ySvrqVLENzVTFxaHW5f0RWxm6/UeNfqXC0DTXSIjNvIZ6m6bLbWo1787PF8 ztbg==
X-Gm-Message-State: AA6/9RnepN6f9nD1TV+4JD6u5s/iU/JCeRa3q3E6qMr+pyo3Zn3JG87SMUqiwujxW+q/aEeeFOK7InQxmFYStA==
X-Received: by 10.55.65.139 with SMTP id o133mr32923128qka.191.1475087877019; Wed, 28 Sep 2016 11:37:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.35.197 with HTTP; Wed, 28 Sep 2016 11:37:56 -0700 (PDT)
X-Originating-IP: [69.64.144.72]
In-Reply-To: <CAHPuVdW=mK+spnGE-iaB8N50sHe=+nn8uPTqx+EdJigMMWLAoA@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>
From: Matthew Pounsett <matt@conundrum.com>
Date: Wed, 28 Sep 2016 11:37:56 -0700
Message-ID: <CAAiTEH9E1qd87hR5ebz4445KB5T2wP_k22Kjr800sy40Zda1dw@mail.gmail.com>
To: Shumon Huque <shuque@gmail.com>
Content-Type: multipart/alternative; boundary="001a114891c0eccbef053d95a872"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/NTb6OvdJAlUbVWr_pdR_5FGZsQA>
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: Wed, 28 Sep 2016 18:38:01 -0000

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.