IETF Logo Mail Archive

Re: [DNSOP] some 2015-era thoughts about RFC 7706 -bis

Tony Finch <dot@dotat.at> Wed, 24 July 2019 14:33 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 7BF3F120388 for <dnsop@ietfa.amsl.com>; Wed, 24 Jul 2019 07:33:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NONE=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 WWrsW1bekab4 for <dnsop@ietfa.amsl.com>; Wed, 24 Jul 2019 07:33:45 -0700 (PDT)
Received: from ppsw-40.csi.cam.ac.uk (ppsw-40.csi.cam.ac.uk [131.111.8.140]) (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 5FE911202C0 for <dnsop@ietf.org>; Wed, 24 Jul 2019 07:33:45 -0700 (PDT)
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]:45022) by ppsw-40.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1hqIKt-0002qR-kS (Exim 4.92) (return-path <dot@dotat.at>); Wed, 24 Jul 2019 15:33:43 +0100
Date: Wed, 24 Jul 2019 15:33:43 +0100
From: Tony Finch <dot@dotat.at>
To: Paul Vixie <paul@redbarn.org>
cc: dnsop@ietf.org
In-Reply-To: <3673081.H4C9ml97Qf@linux-9daj>
Message-ID: <alpine.DEB.2.20.1907241524580.8471@grey.csi.cam.ac.uk>
References: <3673081.H4C9ml97Qf@linux-9daj>
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/KvFMqEWKMBH8rsRruwuziiY7Nw4>
Subject: Re: [DNSOP] some 2015-era thoughts about RFC 7706 -bis
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: Wed, 24 Jul 2019 14:33:51 -0000

Paul Vixie <paul@redbarn.org> wrote:
>
> first, all complexity comes at a cost. the new code and configuration needed
> to support "mirror zones" will be a life long source of bugs and
> vulnerabilities, because that's true of every new feature. the desired benefit
> should be weighed against this cost. "by running one on the loopback" fails
> this important test, mostly because it only applies to the root zone.

Yes. I also agree with Geoff Huston's article from April that hyperlocal
roots are not a compelling imrovement when we have DNSSEC negative answer
synthesis, which applies to any NSEC zone, not just the root.

https://www.potaroo.net/ispcol/2019-04/root.html

> second, RDNS name servers who wanted to support this feature, which all must,
> due to the competitive nature of the open source infrastructure community,
> have to add features very much like authority DNS.

Ironically, unbound has been growing more and more features for serving
authoritative data. There are fairly compelling operational pressures
that drive recursive servers to become more and more complicated, because
they are a very powerful point of control.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Great Orme Head to the Mull of Galloway: South 3 to 5. Smooth or slight.
Mainly fair. Moderate or good.

v2.23.0 | Report a Bug | By Email