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

Mark Andrews <marka@isc.org> Tue, 27 September 2016 00:49 UTC

Return-Path: <marka@isc.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 3D16412B3AA for <dnsop@ietfa.amsl.com>; Mon, 26 Sep 2016 17:49:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.217
X-Spam-Level:
X-Spam-Status: No, score=-9.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 rkN9nFReC6Gp for <dnsop@ietfa.amsl.com>; Mon, 26 Sep 2016 17:49:33 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9335212B3A8 for <dnsop@ietf.org>; Mon, 26 Sep 2016 17:49:33 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 8D9653493BB; Tue, 27 Sep 2016 00:49:31 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 68B81160036; Tue, 27 Sep 2016 00:49:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 2E26716007C; Tue, 27 Sep 2016 00:49:31 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2xNK3zfnY7cZ; Tue, 27 Sep 2016 00:49:31 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id B1779160036; Tue, 27 Sep 2016 00:49:30 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 22EAE5515C31; Tue, 27 Sep 2016 10:49:28 +1000 (EST)
To: Edward Lewis <edward.lewis@icann.org>
From: Mark Andrews <marka@isc.org>
References: <29B4A430-80C7-44C8-A6FA-54A1560D3FD7@icann.org>
In-reply-to: Your message of "Mon, 26 Sep 2016 17:42:31 +0000." <29B4A430-80C7-44C8-A6FA-54A1560D3FD7@icann.org>
Date: Tue, 27 Sep 2016 10:49:27 +1000
Message-Id: <20160927004928.22EAE5515C31@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/GWafIELlsNcNkqWlFzOoRK6BitA>
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: Tue, 27 Sep 2016 00:49:35 -0000

In message <29B4A430-80C7-44C8-A6FA-54A1560D3FD7@icann.org>rg>, Edward Lewis writ
es:
> #2.  Rule
> #
> #   When an iterative caching DNS resolver receives a response NXDOMAIN,
> #   it SHOULD store it in its cache and all names and RRsets at or below
> #   that node SHOULD then be considered to be unreachable.  Subsequent
> #   queries for such names SHOULD elicit an NXDOMAIN response.
> #
> #   But if a resolver has cached data under the NXDOMAIN cut, it MAY
> #   continue to send it as a reply (until the TTL of this cached data
> #   expires), since this may avoid additional processing when a query is
> #   received.  Section 6 provides more information about this.
> 
> For consistency, the SHOULD's in the first paragraph ought to be MAY's.
> (Loically, it has to be.  If I treat it as SHOULD, I'd never discover
> data below that I MAY elect to return.)

No.  SHOULD is not MUST.  Every SHOULD has a implict UNLESS
<unspecified reason>.  In this case we actually have a reason for
the why the second and third SHOULD are not MUSTs.

I could turn first SHOULD into a MUST and still reach the MAY.

> As the authority server may change its version of a zone and the SOA
> (with serial) is not in every response, it's impossible (computationally
> undecidable) to know whether the answer with the NXDOMAIN was created
> before or after lower data.  Maybe the lower data is "currently correct"
> and the NXDOMAIN is stale-ish.  Or not.

Temporal issues are not new.  All DNS caches have them.

> DNSSEC does not solve this - the inception time of a RRSIG is a tempting
> metric of freshness but that timestamp is not reliable for that purpose.
> (From the early days, signers would post date the signature on purpose to
> avoid then-common clock skew issues.)  This would be good to reinforce.
>
> Given a temporally valid answer with data below a temporally denied name
> is possible (as zones change over time), I'd say that it is up to the
> implementer to choose one way or the other.  All things being static, an
> NXDOMAIN would occlude lower data.  But things are not static.
>
> When I wrote "occlude" above I thought of the rule that an NS set
> occludes data below it the cut.  That is, hide it from answers but
> include it in zone transfers.  But that doesn't mean we NXDOMAIN the same
> way - because the rule for NS impacts authorities, the NXDOMAIN issue is
> in caches.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org