IETF Logo Mail Archive

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

Tony Finch <dot@dotat.at> Fri, 15 February 2019 09:47 UTC

Return-Path: <dot@dotat.at>
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 35F89130F9A for <dnsop@ietfa.amsl.com>; Fri, 15 Feb 2019 01:47:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 1CjcYUtQ2OGl for <dnsop@ietfa.amsl.com>; Fri, 15 Feb 2019 01:47:51 -0800 (PST)
Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 0AE37130F5F for <dnsop@ietf.org>; Fri, 15 Feb 2019 01:47:51 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:43768) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1gua61-000HZw-1q (Exim 4.91) (return-path <dot@dotat.at>); Fri, 15 Feb 2019 09:47:49 +0000
Date: Fri, 15 Feb 2019 09:47:49 +0000
From: Tony Finch <dot@dotat.at>
To: Paul Vixie <paul@redbarn.org>
cc: IETF DNSOP WG <dnsop@ietf.org>
In-Reply-To: <b45edb5e-1508-0b02-a14c-a5be4ca9c0e6@redbarn.org>
Message-ID: <alpine.DEB.2.20.1902150938540.18720@grey.csi.cam.ac.uk>
References: <b45edb5e-1508-0b02-a14c-a5be4ca9c0e6@redbarn.org>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/kpjvdkWfQNzgtFduYWs7Wt5u8q8>
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 09:47:53 -0000

Paul Vixie <paul@redbarn.org> wrote:

> unbound has pioneered a bit of this by automatically refetching data that's
> near its expiration point.

BIND also does this, it's on by default.

I'm not a fan of RFC 7706 because I think it's redundant wrt prefetch
(HAMMER), NXDOMAIN synthesis, and (to a much smaller extent) serve-stale.

> 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.

We have local stealth secondary copies of our zones on our recursive
servers which helps to some extent, except when downstream validators want
to get the chain of trust. But serve-stale should help.

I wonder if it's worth having different prefetch logic for infrastructure
records (NS, DS, glue, etc) to more eagerly keep them warm than leaf
records.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Northwest Southeast Iceland: Northeasterly 5 or 6, becoming variable 3 or 4.
Rough. Wintry showers. Good, occasionally poor.

v2.31.3 | Report a Bug | By Email | System Status