[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
- [DNSOP] the root is not special, everybody please… Paul Vixie
- Re: [DNSOP] the root is not special, everybody pl… Mark Andrews
- Re: [DNSOP] the root is not special, everybody pl… Evan Hunt
- Re: [DNSOP] the root is not special, everybody pl… Paul Vixie
- Re: [DNSOP] the root is not special, everybody pl… Evan Hunt
- Re: [DNSOP] the root is not special, everybody pl… Paul Vixie
- Re: [DNSOP] the root is not special, everybody pl… william manning
- Re: [DNSOP] the root is not special, everybody pl… Paul Vixie
- Re: [DNSOP] the root is not special, everybody pl… Grant Taylor
- Re: [DNSOP] the root is not special, everybody pl… william manning
- Re: [DNSOP] the root is not special, everybody pl… Paul Vixie
- Re: [DNSOP] the root is not special, everybody pl… Evan Hunt
- Re: [DNSOP] the root is not special, everybody pl… David Conrad
- Re: [DNSOP] the root is not special, everybody pl… Tony Finch
- Re: [DNSOP] the root is not special, everybody pl… Stephane Bortzmeyer
- Re: [DNSOP] the root is not special, everybody pl… Bob Harold
- [DNSOP] Making domains work even when connectivit… Stephane Bortzmeyer
- Re: [DNSOP] the root is not special, everybody pl… Paul Vixie
- Re: [DNSOP] Making domains work even when connect… Paul Vixie
- Re: [DNSOP] Making domains work even when connect… william manning