[DNSOP] the root is not special, everybody please stop obsessing over it

Paul Vixie <paul@redbarn.org> Thu, 14 February 2019 21:57 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 9FCA612D826 for <dnsop@ietfa.amsl.com>; Thu, 14 Feb 2019 13:57:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 4UoTwVvWpLs8 for <dnsop@ietfa.amsl.com>; Thu, 14 Feb 2019 13:57:16 -0800 (PST)
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 81AF71200D7 for <dnsop@ietf.org>; Thu, 14 Feb 2019 13:57:16 -0800 (PST)
Received: from [IPv6:2001:559:8000:c9:b448:8ed0:27c1:2c1b] (unknown [IPv6:2001:559:8000:c9:b448:8ed0:27c1:2c1b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 398AC892C6 for <dnsop@ietf.org>; Thu, 14 Feb 2019 21:57:16 +0000 (UTC)
To: IETF DNSOP WG <dnsop@ietf.org>
From: Paul Vixie <paul@redbarn.org>
Message-ID: <b45edb5e-1508-0b02-a14c-a5be4ca9c0e6@redbarn.org>
Date: Thu, 14 Feb 2019 13:57:14 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/6.1.10
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/eo0tT7ZrAvvFOhCUJLPZfwK87bA>
Subject: [DNSOP] the root is not special, everybody please stop obsessing over it
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: Thu, 14 Feb 2019 21:57:19 -0000

7706 is wrong headed on a number of levels, but its worst offense is to 
think that the root zone is special. we need dns to have leases on its 
delegation chain including glue and dnssec metadata. everything you 
might need to use in order to reach a zone authority and trust its 
results should be kept warm. the owner of the data you've leased must 
have the ability to reach out and invalidate it in a trusted way.

having .CN's delegation data resident because of 7706 doesn't help you 
reach your own EXAMPLE.CN name servers if the network outage you were 
concerned about is inside china rather than between china and the rest 
of the world.

NFS gave an example of how to solve this, 25 years ago, with NQLEASE. i 
am not asking for new computer science, only application of what's 
already well understood outside the DNS community, as to keeping the hot 
side hot.

unbound has pioneered a bit of this by automatically refetching data 
that's near its expiration point. we should work from there outward, by 
standardizing it, prioritizing delegation and dnssec metadata, and 
exploring ways that the .CN servers could invalidate old NS RRset or DS 
RRset data (or indeed DNSKEY and RRSIG) if it was willing to do the work 
of remembering who it had handed the now-invalid data to and what trust 
markers would be needed to get an RDNS to accept some new form of NOTIFY 
to purge its cache.

_that_ would be complexity worth its cost. 7706 was not. HAMMER is not. 
indeed nothing which treats the root zone as special is worth pursuing, 
since many other things besides the root zone are also needed for 
correct operation during network partition events.

the fact that i have to hotwire my RDNS cache with local zone glue in 
order to reach my own servers when my comcast circuit is down or i can't 
currently reach the .SU authorities to learn where VIX.SU is, should not 
only concern, but also embarrass, all of us.

vixie