[DNSOP] some 2015-era thoughts about RFC 7706 -bis

Paul Vixie <paul@redbarn.org> Tue, 23 July 2019 22:18 UTC

Return-Path: <paul@redbarn.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 5FF5B1209DC for <dnsop@ietfa.amsl.com>; Tue, 23 Jul 2019 15:18:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 ilWNLRr5K-j1 for <dnsop@ietfa.amsl.com>; Tue, 23 Jul 2019 15:18:23 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46A551209D5 for <dnsop@ietf.org>; Tue, 23 Jul 2019 15:18:23 -0700 (PDT)
Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 31D8C892E8 for <dnsop@ietf.org>; Tue, 23 Jul 2019 22:18:22 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: dnsop@ietf.org
Date: Tue, 23 Jul 2019 22:18:20 +0000
Message-ID: <3673081.H4C9ml97Qf@linux-9daj>
Organization: none
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="nextPart9310956.uIrC5zjrPb"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/OwANlbzoZDrYUBXu-pd5tR0v8XA>
Subject: [DNSOP] some 2015-era thoughts about RFC 7706 -bis
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 23 Jul 2019 22:18:37 -0000

at the one-hour DNSOP meeting in montreal on monday evening, the authors of 
RFC 7706 described some of the use case questions they were hoping to answer 
in their -bis document, and one of them hit squarely on a topic i spoke about 
frequently between 2005 and 2015. i've attached a copy of the 2015 proposal, 
which was reviewed by warren kumari and then presented in a non-IETF meeting 
on these topics, organized by warren and i, in hong kong.

i was opposed to RFC 7706 as written, but there is no permanent record of my 
reasoning since RFC documents don't include a "dissenting views" section, so 
let me briefly recapitulate here.

first, all complexity comes at a cost. the new code and configuration needed 
to support "mirror zones" will be a life long source of bugs and 
vulnerabilities, because that's true of every new feature. the desired benefit 
should be weighed against this cost. "by running one on the loopback" fails 
this important test, mostly because it only applies to the root zone.

second, RDNS name servers who wanted to support this feature, which all must, 
due to the competitive nature of the open source infrastructure community, 
have to add features very much like authority DNS. we have been moving away 
from the so-called "hybrid server" model for three decades now, and this was a 
move in precisely the wrong direction.

third, access patterns of root zone data are an important input to internet 
governance, and the 7706 proposal included no recommendations by which access 
patterns could still be globally shared in any way -- and for reasons of 
scale, they will not be participating in Day In The Life exercises.

in summary, RFC 7706 solves the wrong problem, in the wrong way, with an 
inverted cost:benefit model compared to similar conceptions with similar 
implementation costs.

those who hang around where i do have heard me explain that what DNS needs is 
a lease model for all metadata, with secure revocation. any delegation data 
including NS, glue, and DNSSEC chains, must be held by an RDNS until it 
changes, and every authority must be able to signal such changes. you can 
think of this as like a micro-secondary server at the RRset level, plus 
NOTIFY. no network partition should keep an RDNS from returning all 
information which is still available ("on this side of the partition") needed 
to reach services and assets which are still available ("on this side of the 
partition"), and DNS got that wrong by externalizing dependencies.

however, that is not the subject of the attached 2015-era "hong kong" 
proposal. at DNSOP monday night, a use case that was mentioned for 7706-bis is 
where the local copy of the root zone not be necessarily co-served by an RDNS. 
that is a much smaller problem than "leasing for all metadata in case of a 
network partition", and is squarely addressed by the modest proposal below.

one world, one internet, one namespace.

-- 
Paul