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

Paul Vixie <paul@redbarn.org> Fri, 15 February 2019 02:56 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 83608130E8B for <dnsop@ietfa.amsl.com>; Thu, 14 Feb 2019 18:56:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 bNSGKvgBINUS for <dnsop@ietfa.amsl.com>; Thu, 14 Feb 2019 18:56:53 -0800 (PST)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FF2E130E7D for <dnsop@ietf.org>; Thu, 14 Feb 2019 18:56:53 -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 DBF72892C6; Fri, 15 Feb 2019 02:56:52 +0000 (UTC)
To: Grant Taylor <gtaylor=40tnetconsulting.net@dmarc.ietf.org>
Cc: dnsop@ietf.org
References: <b45edb5e-1508-0b02-a14c-a5be4ca9c0e6@redbarn.org> <20190214235614.GB87001@isc.org> <6c3d6894-c584-c4fd-d09e-55903b34bead@redbarn.org> <CACfw2hiH5pS1wL+MKCq6-vYZS2sQ562Ke-2unC7zV1KQMPJybw@mail.gmail.com> <c54c48aa-1c75-7b72-2b52-3583e0e803ed@redbarn.org> <c25c30d6-91f5-ddd9-4dc4-475c1b55bf78@spamtrap.tnetconsulting.net>
From: Paul Vixie <paul@redbarn.org>
Message-ID: <4c8b9d4c-8a26-6140-0dc9-f5ba84a8f680@redbarn.org>
Date: Thu, 14 Feb 2019 18:56:51 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/6.1.10
MIME-Version: 1.0
In-Reply-To: <c25c30d6-91f5-ddd9-4dc4-475c1b55bf78@spamtrap.tnetconsulting.net>
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/KU39tkMR3iDOijAG62l1s50L05M>
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: Fri, 15 Feb 2019 02:56:55 -0000


Grant Taylor wrote on 2019-02-14 18:27:
> Please explain how "warm storage" relates to priming issues.  Does
> warm mean that it's something you have queried?  Or does it also
> include pertinent (meta)data for interesting things (but not
> everything) that you've not yet queried?

i don't expect anyone to store anything they have not queried, though
it's natural for an implementation to permit an operator to statically
define other targets as well, much as mark andrews did with "stub" zones
starting in 1990 or so in BIND4.

> Does "still reach all internet resources on my side of the break" 
> include things that you've not yet queried for?

no. while there may be some kind of persistent storage of long term
popularity information so that things that were ever warm can be kept
warm even if not queried since the last reboot cycle, i do not expect
any tree-walking exercises. my long term study of RDNS tells me that
there is a high correlation between past and future queries. if some
query tries to occur during a connectivity break, it might fail, and in
that sense it's a DNS problem we've always had, that i'm not solving.

> ...
> 
> How close would something like this be to what you're wanting to
> see?

i think leasing behaviour is expensive on a network-wide basis, and
should be limited to high-value data, by which i mean metadata needed to
reach and trust name servers. so, DS/NS, DNSKEY/RRSIG, and related
AAAA/A. i do not foresee remembering non-metadata information, no matter
how popular, since it's in a content operator's power to put a copy of
their DNS infrastructure inside any region that also has a copy of its
services. it's only third party metadata, like the delegation and trust
chain, that is an unmanageable risk today.

also note, i would not propose invalidation on its own merits, because 
the cost of the data-state and trust-state is too high. however, if we 
have to maintain that state anyway, for leasing, then invalidation is 
approximately free, depending on the priorities of the authority server 
operator. therefore, it becomes a package deal, one stone, two birds.

-- 
P Vixie