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

Mark Andrews <marka@isc.org> Thu, 14 February 2019 22:13 UTC

Return-Path: <marka@isc.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 6F99F131053 for <dnsop@ietfa.amsl.com>; Thu, 14 Feb 2019 14:13:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 8MA_-2Jnb2ew for <dnsop@ietfa.amsl.com>; Thu, 14 Feb 2019 14:13:45 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E858D1311EA for <dnsop@ietf.org>; Thu, 14 Feb 2019 14:13:43 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 8733F3AB042; Thu, 14 Feb 2019 22:13:42 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 60B3616006E; Thu, 14 Feb 2019 22:13:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 39C91160072; Thu, 14 Feb 2019 22:13:12 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YpQkUEMQSB5b; Thu, 14 Feb 2019 22:13:12 +0000 (UTC)
Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 3E32D16006E; Thu, 14 Feb 2019 22:13:11 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <b45edb5e-1508-0b02-a14c-a5be4ca9c0e6@redbarn.org>
Date: Fri, 15 Feb 2019 09:13:07 +1100
Cc: IETF DNSOP WG <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C976AB63-C8BD-4F11-8A1A-ADAE05D52CA3@isc.org>
References: <b45edb5e-1508-0b02-a14c-a5be4ca9c0e6@redbarn.org>
To: Paul Vixie <paul@redbarn.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/TBRgndzQiIJpaEbEOMdYACqtdmw>
Subject: Re: [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 22:13:48 -0000


> On 15 Feb 2019, at 8:57 am, Paul Vixie <paul@redbarn.org> wrote:
> 
> 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.

Having the local recursive server having a copy of the local zones was
always part of DNS’s deployment model.  Having authoritative servers not be
recursive servers is not the same as recursive servers not being
authoritative for some zones.

One thing we missed when adding NOTIFY was adding a NOTIFY-ALSO RRset. In
named we work around this by having a also-notify clause in the zone’s
configuration clause.

DNS RRsets need two TTLs. 1) refresh after in case we need to update. 2) stop believing
this result after.  With a little bit of EDNS negotiation both can be transmitted in
a response.

> vixie
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org