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

Edward Lewis <edward.lewis@icann.org> Mon, 26 September 2016 17:42 UTC

Return-Path: <edward.lewis@icann.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DEB3912B321 for <dnsop@ietfa.amsl.com>; Mon, 26 Sep 2016 10:42:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.517
X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id pmfX10Ek3AtN for <dnsop@ietfa.amsl.com>; Mon, 26 Sep 2016 10:42:34 -0700 (PDT)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B6D712B31F for <dnsop@ietf.org>; Mon, 26 Sep 2016 10:42:34 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org ( by PMBX112-W1-CA-2.pexch112.icann.org ( with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 26 Sep 2016 10:42:32 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([]) with mapi id 15.00.1178.000; Mon, 26 Sep 2016 10:42:32 -0700
From: Edward Lewis <edward.lewis@icann.org>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt
Thread-Index: AQHSGB1bdhjoj3onHU+w+A+q19myVg==
Date: Mon, 26 Sep 2016 17:42:31 +0000
Message-ID: <29B4A430-80C7-44C8-A6FA-54A1560D3FD7@icann.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
user-agent: Microsoft-MacOutlook/f.1a.1.160916
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3557742150_1162254661"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/pdWxUodJK3VA9Gzv_NSrCe5vTfg>
Subject: [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: Mon, 26 Sep 2016 17:42:36 -0000

#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.  (Logically, it has to be.  If I treat it as SHOULD, I'd never discover data below that I MAY elect to return.)

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.

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.