Re: [dnsext] [Ext] [Technical Errata Reported] RFC4592 (5119)

Edward Lewis <edward.lewis@icann.org> Thu, 21 September 2017 12:00 UTC

Return-Path: <edward.lewis@icann.org>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22AA11342C5 for <dnsext@ietfa.amsl.com>; Thu, 21 Sep 2017 05:00:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 A2zA0JfdKv0g for <dnsext@ietfa.amsl.com>; Thu, 21 Sep 2017 05:00:45 -0700 (PDT)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41A251320C9 for <dnsext@ietf.org>; Thu, 21 Sep 2017 05:00:45 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 21 Sep 2017 05:00:42 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Thu, 21 Sep 2017 05:00:42 -0700
From: Edward Lewis <edward.lewis@icann.org>
To: RFC Errata System <rfc-editor@rfc-editor.org>, "suresh.krishnan@gmail.com" <suresh.krishnan@gmail.com>, Terry Manderson <terry.manderson@icann.org>, "ogud@ogud.com" <ogud@ogud.com>, "ajs@anvilwalrusden.com" <ajs@anvilwalrusden.com>
CC: "K.Koymans@uva.nl" <K.Koymans@uva.nl>, "dnsext@ietf.org" <dnsext@ietf.org>
Thread-Topic: [Ext] [dnsext] [Technical Errata Reported] RFC4592 (5119)
Thread-Index: AQHTMsgETTnbasncMkKOPIRs+ZkkYaK/skcA
Date: Thu, 21 Sep 2017 12:00:42 +0000
Message-ID: <E74BF354-AE18-4D18-B066-E9EB745176F2@icann.org>
References: <20170921105406.C6A89B81F0B@rfc-editor.org>
In-Reply-To: <20170921105406.C6A89B81F0B@rfc-editor.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.26.0.170902
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.47.234]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="B_3588825642_1033411387"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsext/JKlVL3rOTcWMYl0z6AQfbM6hsPQ>
Subject: Re: [dnsext] [Ext] [Technical Errata Reported] RFC4592 (5119)
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsext/>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Sep 2017 12:00:47 -0000

On 9/21/17, 06:54, "dnsext on behalf of RFC Errata System" <dnsext-bounces@ietf.org on behalf of rfc-editor@rfc-editor.org> wrote:

>Synthesizing these records would destroy the semantics of the NSEC chain and could be very harmful if implementations would cache them and use them for "Aggressive Use of DNSSEC-Validated Cache" (RFC 8198).

When "The Role of Wildcards in the DNS" was written, "Aggressive Use of DNSSEC-Validated Cache" hadn't been.  Until now I wasn't completely aware of that latter document (as I've not followed DNSOP for some time now), although I heard rumors about the idea.  (Meaning: I'd have to read the newer document before understanding the errata.)  Take this reply as the beginning of a discussion, not a final response, I certainly don't have all the data.

Nevertheless, some explanation of the history of the subject passage is in order.

The DNS of 10-15 years ago had the concept of a positive cache and a negative cache, the latter from "Negative Caching of DNS Queries (DNS NCACHE)".  Entries in the latter cache only happened with a negative answer (i.e., NSEC or NSEC3 in the authority section of a DNS response if DNSSEC was "running").  Data from the answer section in a DNS response would not go there, hence the comment that synthesized answers would do no harm.

The distinction of the section in which the NSEC record is received matters.  There are two ways an NSEC record can appear in an answer section and one way an NSEC3 record can appear in an Answer section.  The protocol will answer for queries with a QTYPE of NSEC (one way for NSEC) but not for NSEC3 (which the count of "ways" is different).  The one way each can appear in an answer section is in a zone transfer (AXFR) [and I suppose incremental transfer (IXFR).  AXFR and IXFR handling are a whole'nuther topic (see "DNS Zone Transfer Protocol (AXFR)").  I haven't read the "Aggressive Use of DNSSEC-Validated Cache" to know if it overlooked this important distinction, that is, NSEC records in the answer section (of a query-response) are not necessarily qualified to be used for "aggressive use" if because they may be synthesized.

The assumption behind the statement in "The Role of Wildcards in the Domain Name System" is that we wanted minimal disruption to existing code bases, hence there was no new restriction added for a query whose type was NSEC.

Another element of the historical context, while "The Role of Wildcards in the Domain Name System" was developed, there was uncertainty about whether a cache should be allowed to "usurp" the role of an authority (server) when it came to RCODE Name Error responses.  I don't recall my opinion on this at the time, so I'm not arguing one way or the other, but there was reluctance to permit the caches to take this on.  There was no consensus then, as there is now, that caches out to be "aggressive."  This is why the document assumed that the only use of negative answer records would be to answer specific queries (QNAME, QTYPE, QCLASS), modulo other factors such as "Client Subnet in DNS Queries".  This shift in consensus is what makes the subject passive "historically confusing." 

My take.  I'm naturally against adopting errata unless it is clear a change is needed.  I do see that the statement is historically confusing, but am not yet certain it is incorrect.  I would suggest examining the "Aggressive Use of DNSSEC Validated Cache" to see if it takes into consideration the response message section of the NSEC records.

Altering the older document would mean needing to address older code paths, this is why I suggest examining the newer document to see if it has the same assumptions as the older document - specifically the message section.