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

Grant Taylor <gtaylor@tnetconsulting.net> Fri, 15 February 2019 02:27 UTC

Return-Path: <gtaylor@tnetconsulting.net>
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 E1989130DE3 for <dnsop@ietfa.amsl.com>; Thu, 14 Feb 2019 18:27:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tnetconsulting.net
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 In5jkphZ6sNe for <dnsop@ietfa.amsl.com>; Thu, 14 Feb 2019 18:27:41 -0800 (PST)
Received: from tncsrv06.tnetconsulting.net (tncsrv06.tnetconsulting.net [IPv6:2600:3c00:e000:1e9::8849]) (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 A23D0130DD8 for <dnsop@ietf.org>; Thu, 14 Feb 2019 18:27:41 -0800 (PST)
Received: from Contact-TNet-Consulting-Abuse-for-assistance by tncsrv06.tnetconsulting.net (8.15.2/8.15.2/Debian-3) with ESMTPSA id x1F2RddG007037 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <dnsop@ietf.org>; Thu, 14 Feb 2019 20:27:40 -0600
ARC-Filter: OpenARC Filter v0.1.0 tncsrv06.tnetconsulting.net x1F2RddG007037
Authentication-Results: tncsrv06.tnetconsulting.net; arc=none header.d=tnetconsulting.net
ARC-Seal: i=1; a=rsa-sha256; d=tnetconsulting.net; s=2015; t=1550197660; cv=none; b=J2Wxs397g98Nao2+qa9goFwnoArnwDgKrJPmcsGWkZv3D7a4GJsZR57nCBs0o99rQ3EmEdHqW0dh/yc958wT+JGp9/cHWVwVfvCWFmLuc6QhKL3i4Rg6EJPIPjafa4c9oOp5FIsf5EF/5MXugQ8ZCGiuzn0Lx8OYcekGQVqZm/c=
ARC-Message-Signature: i=1; a=rsa-sha256; d=tnetconsulting.net; s=2015; t=1550197660; c=relaxed/simple; bh=3sI25Txs4NENuvzYC/ajdHiqE2lr2K5uiGCl10lXE8g=; h=DKIM-Signature:Subject:To:From:Message-ID:Date:User-Agent: MIME-Version:Content-Type; b=oF6zjjgujD2j9SkGScVZUKU4NtU1BR5yle0V9YzydBcco/0uaYZuupiZJpCsazOdpUqKK499yQwJcYjcC92e6lQ8FU/qev0JGzvsKIIOFD1790Un8QmKm/NOV5z3rzYNtsjhqdeJghier7AWsUzBj9ZaTCK91mpKz2YxfXcHvGo=
ARC-Authentication-Results: i=1; tncsrv06.tnetconsulting.net; none
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tnetconsulting.net; s=2015; t=1550197660; bh=3sI25Txs4NENuvzYC/ajdHiqE2lr2K5uiGCl10lXE8g=; h=Subject:To:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Cc:Content-Disposition: Content-Language:Content-Transfer-Encoding:Content-Type:Date:From: In-Reply-To:Message-ID:MIME-Version:References:Reply-To: Resent-Date:Resent-From:Resent-To:Resent-Cc:Sender:Subject:To: User-Agent; b=NMGN6tmbw0OLDYMD4xhp7ssLtKsGcD/rjOVKhYnuQIw8onOebFr72iCiA9+GbvVki Ii/74KyzADwUhPLLN/Ofx3O/3GWFuO5P7E+W2WuBfNvQKBt5qFmcjUzpeiDWfiImGg FM5NiCSHVO/17lYoMlrHO/SX5uthx8H7mN3ujytw=
To: 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>
From: Grant Taylor <gtaylor@tnetconsulting.net>
Organization: TNet Consulting
Message-ID: <c25c30d6-91f5-ddd9-4dc4-475c1b55bf78@spamtrap.tnetconsulting.net>
Date: Thu, 14 Feb 2019 19:27:41 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <c54c48aa-1c75-7b72-2b52-3583e0e803ed@redbarn.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040404000801080901090608"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/7Z3hGsWcEl54Hg47KokczDqgT4s>
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:27:44 -0000

On 2/14/19 6:51 PM, Paul Vixie wrote:
> i want the metadata i need to reach and trust assets on my side of any 
> connectivity loss event, to be kept in warm storage, and made subject to 
> trusted invalidation on an opportunistic basis, at the discretion of the 
> authority operators who own the data i have warm copies of.

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?

> in practice this means DS/NS and DNSKEY/RRSIG and AAAA/A from my static 
> trust anchor(s) down to any data i used recently or frequently (or by 
> some other priority scheme), and i want it to look a bit like the single 
> transaction mode of IXFR plus the single transaction mode of NOTIFY.
> 
> no topology information as to actual connectivity will be modeled or 
> estimated or needed. what matters is whether i can still reach all 
> internet resources on my side of a break in connectivity (whether local 
> or regional or distant), without needing any information that's 
> otherwise only available on the far side of the connectivity break.

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

I'm wondering if a fancier cache of some sort would suffice.

Specifically I wonder if BIND (et al) can maintain a FIFO (like) list of 
QNAMEs, moving the current QNAME to the start of the list, and 
proactively refreshing the first 10 / 100 / 1000 / pick a number in such 
a way as to not alter the list position when refreshing.

This obviously has a priming problem as a QNAME won't be subject for 
refresh until /after/ it has been queried the first time.  This is why I 
question your use of the word "warm".

Perhaps this can be implemented as part of the existing garbage 
collection process that remove expired cache entries.  If the data to be 
purged is in the FIFO, then refresh it and cache the results without 
moving it to the head of the FIFO.

The other thing that I might add to this is something to artificially 
prime the cache by querying for specific names off of a user definable list.

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

This would re-use existing mechanism and methodology.  It wouldn't see 
changes in data until after cache expiration.  But this is SoP for 
caches now.

> thanks for asking; i am happy to clarify. DNS infrastructure should not 
> be centralized, even if its content remains centrally coordinated by 
> ICANN. (block chain people keep telling me that ICANN will be obsolete, 
> but i'm not taking a position on that, only on data resiliency.)



-- 
Grant. . . .
unix || die