[DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.

Edward Lewis <edward.lewis@icann.org> Mon, 29 February 2016 12:51 UTC

Return-Path: <edward.lewis@icann.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC851A8770 for <dnsop@ietfa.amsl.com>; Mon, 29 Feb 2016 04:51:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Level:
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
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 S2mdPUyME7Wb for <dnsop@ietfa.amsl.com>; Mon, 29 Feb 2016 04:51:19 -0800 (PST)
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 5B1751A876B for <dnsop@ietf.org>; Mon, 29 Feb 2016 04:51:19 -0800 (PST)
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 Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 29 Feb 2016 04:51:16 -0800
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.1130.005; Mon, 29 Feb 2016 04:51:16 -0800
From: Edward Lewis <edward.lewis@icann.org>
To: dnsop <dnsop@ietf.org>
Thread-Topic: Fracturing the protocol - was Re: [DNSOP] Updated cheese-shop.
Thread-Index: AQHRcu/gsgHwbGPPSE6l0P859qq8xA==
Date: Mon, 29 Feb 2016 12:51:16 +0000
Message-ID: <D2F9A5BA.13FE2%edward.lewis@icann.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.1.160122
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_3539577073_10081937"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/g77eRUVbjbuf_H9QjJK3ymKj92I>
Subject: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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, 29 Feb 2016 12:51:20 -0000

On 2/25/16, 17:58, "DNSOP on behalf of Warren Kumari"
<dnsop-bounces@ietf.org on behalf of warren@kumari.net> wrote:

>We have recently updated "Believing NSEC records in the DNS root"
>(https://tools.ietf.org/html/draft-wkumari-dnsop-cheese-shop-01).

My objection to this document is based on the draft's proposal to specify
a change to the protocol based on the data being carried in one particular
deployment of the protocol.

(The temptation to define the special protocol behaviors for a special use
case came up when we'd considered altering the DNSSEC signing definition
for dotCOM.  At the time, a 750K delegation-large zone was larger than a
100MHz PC could handle.  We didn't, eventually an "opt-out" proposal was
adopted that would work with any zone.)

The DNS protocol is used in more than just the global public Internet.
I.e., there are other inter-network environments in production use, run
independently of the internet.  The cross-over between the such
environments and the internet is the use of the same software.

If the DNS is built to assume that the root zone is DNSSEC signed with
NSEC records and this is then "burned into software" the other
inter-networks will be given the choice of having to turn on DNSSEC and
NSEC for their root zone or developing other software.  (Or...other
inconvenient mitigations.)

This has nothing to do with whether NXDOMAIN responses can or should be
assembled by a DNS intermediary.  That's an entirely different question.