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

Shumon Huque <shuque@gmail.com> Wed, 28 September 2016 17:03 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 10BB612B1C2 for <dnsop@ietfa.amsl.com>; Wed, 28 Sep 2016 10:03:57 -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 pHA-xstaY1YH for <dnsop@ietfa.amsl.com>; Wed, 28 Sep 2016 10:03:52 -0700 (PDT)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c: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 58BB612B23A for <dnsop@ietf.org>; Wed, 28 Sep 2016 10:03:27 -0700 (PDT)
Received: by mail-wm0-x230.google.com with SMTP id b130so82219631wmc.0 for <dnsop@ietf.org>; Wed, 28 Sep 2016 10:03:27 -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=dFLHB3jFw/flQOd1nGM0Zkuba6mjOSjPAu8A/hXqBoE=; b=D+UDAI68vMnoDeq3x6IoYnK624lqV1Nityw8XMgXcZQ2OZ4X6faEzzMJ5AENROsrwW t4//KK0b7IjtaBDUhJOeW/V55w+WbQe9gcLIcho+Ep6gDSpT6qQzFgncUyr/m8bFSObh GTD5XzZHA5pMf+AaNhboawG6O6cH2GPt21iMM6wK3HNSHCZqPTubicrTHEpoADpC3c+T 2SbndjBGcUrWIFCwU9Kj65CTISrvxAYnm6R9uyA93K4TzvmMsCnt6cUKxASipLuK++I8 /eZ6J7b6TvhytiqZIAG5XBO6DFJwvvV1heyzrb0IICahylmRnS6Pb7E9e1gJqaE1ux3L SB3Q==
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=dFLHB3jFw/flQOd1nGM0Zkuba6mjOSjPAu8A/hXqBoE=; b=GFpAByvuh38lmQO8llNCStWiCk16VfUEindgFaVLyZcZidz6UXncRO5R5LvszFAETY BANXQhruK0TFpiU7cJR6aUUD3/ifXaRFlR038XF1rJT6ca1N4VzEQZfDytxobA0koC64 VIUWJu/JU0wBcX45Mf2xt95iPidn9QouCtg0nTXx6FALIbGC0Dogz8grtNWHib0RJ/s8 S6HcZjPL++k6/zq6D6Uu1iK6aYv32v1lSN8si6MbIgFAGz8KUJf8YClHY1PH8g7G2IMZ RUA2ymkbqmYIQdB6gZSRAgz3c7ZDLo+iUqvMjTB2fpS9KrDtLzNlnb0vB/UWhDLYwxBP 9b1A==
X-Gm-Message-State: AA6/9Rm00Dn66ljIO1w52juVj2se14Hxjloj7bfbRbptVYCUmbi7N2ZG4OJvQRl59SjBi64ndNTMe/lc+3eg8w==
X-Received: by 10.28.107.22 with SMTP id g22mr8746247wmc.31.1475082205869; Wed, 28 Sep 2016 10:03:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.165.168 with HTTP; Wed, 28 Sep 2016 10:03:24 -0700 (PDT)
In-Reply-To: <E309662B-9C03-4EFE-9168-62033A6D75A6@fl1ger.de>
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> <CAHPuVdV8Nw_AGY0jbdCoh2dJBdL2cctg6Wm_Afqu9Ui4y6wm7g@mail.gmail.com> <E309662B-9C03-4EFE-9168-62033A6D75A6@fl1ger.de>
From: Shumon Huque <shuque@gmail.com>
Date: Wed, 28 Sep 2016 13:03:24 -0400
Message-ID: <CAHPuVdVuFMMiRyk+wW-Edmmj8gXWK-hZhR-+-x6hUkaa-xSk5Q@mail.gmail.com>
To: Ralf Weber <dns@fl1ger.de>
Content-Type: multipart/alternative; boundary="001a1146563ce53c31053d945652"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/8ZJebsFWkL9osFfFixnp8QGBU9Y>
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 17:03:57 -0000

On Wed, Sep 28, 2016 at 12:44 PM, Ralf Weber <dns@fl1ger.de> wrote:

> Moin!
>
> On 28 Sep 2016, at 17:21, Shumon Huque wrote:
> > To be precise, I would say we are not necessarily always pruning out
> entire
> > zones. For a leaf zone, we are pruning all names within that zone below
> the
> > nxdomain-cut, modulo cached entries, i.e. a subset of the zone. But yes,
> > for non-leaf zones, all zones below too are pruned.
> I think we've been down that argument before. Not all cache implementations
> have a DNS tree structure and nothing in the DNS protocol requires this
> AFAIK.
> I consider anything in the cache where the TTL is still valid to be valid
> data
> that can be send to clients even if below the nxdomain cut. My
> understanding
> is that this is how the current draft is written.
>

Not exactly. The draft does NOT say that all unexpired cached data below
the NXDOMAIN boundary is still valid. It leaves that up to implementers.
Paraphrasing without 2119 keywords, it says that resolvers should consider
all names below the cut non-existent, but may continue to return positive
answers for existing cached entries. This text was the end result of many
long discussions on the topic earlier this year. I think this accommodates
your position.


> For new records/delegations of course this would go NXDomain, but what to
> do
> with stuff already in the cache is an implementation choice.
>

Yes.

-- 
Shumon Huque