Re: [DNSOP] Adding more example configurations to draft-ietf-dnsop-7706bis

Ray Bellis <ray@bellis.me.uk> Fri, 26 October 2018 09:52 UTC

Return-Path: <ray@bellis.me.uk>
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 DCCF81252B7 for <dnsop@ietfa.amsl.com>; Fri, 26 Oct 2018 02:52:42 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 pr92A95vx4vn for <dnsop@ietfa.amsl.com>; Fri, 26 Oct 2018 02:52:40 -0700 (PDT)
Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94AB212F1A2 for <dnsop@ietf.org>; Fri, 26 Oct 2018 02:52:40 -0700 (PDT)
Received: from [88.212.170.147] (port=57925 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1gFynF-0005eR-JM (Exim 4.72) for dnsop@ietf.org (return-path <ray@bellis.me.uk>); Fri, 26 Oct 2018 10:52:37 +0100
To: dnsop@ietf.org
References: <47597960-3D11-4007-947D-19DBC7AF2BAC@icann.org>
From: Ray Bellis <ray@bellis.me.uk>
Message-ID: <75129a2d-8f91-48ca-dc27-7d6dfde685e0@bellis.me.uk>
Date: Fri, 26 Oct 2018 10:52:38 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <47597960-3D11-4007-947D-19DBC7AF2BAC@icann.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/TAtcNjZbBOoVT4gwNTDZ5Ygf98Q>
Subject: Re: [DNSOP] Adding more example configurations to draft-ietf-dnsop-7706bis
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, 26 Oct 2018 09:52:43 -0000

On 12/09/2018 18:57, Paul Hoffman wrote:

> Greetings again. One of the things that people said they wanted in 7706bis is more example configurations for different systems. We currently have:
> - BIND 9.9 with views
> ...
> I'll test BIND 9.10 with views to see if it's the same setup, and also more recent Unbound/NSDs.

BIND 9.9 and BIND 9.10 were both EOL as of July this year.

BIND 9.11 is the "ESV" version with an EOL date of July 2021.

(see the version table under the "BIND" drop down at
<https://www.isc.org/downloads/>)

The setup should be identical to the earlier versions, though.

That said - I want to take issue with the continuing focus on "same
host", even though the "running on loopback" restriction isn't there.

IMHO there's simply no need for this.  Even the largest ISP shouldn't
need more than a few local root zone servers, and it's an unnecessary
complication to shoe-horn those local copies onto the same host and/or
server as the recursive instance.

The document says "The primary goals of this design are to provide
faster negative responses to stub resolver queries that contain queries
that result in NXDOMAIN responses, and to prevent queries and responses
from being visible on the network".

IMHO, that second goal should be for those queries not to _leave_ the
network.

By all means describe how one _could_ run on the same host, but as a
whole I still find this document unnecessarily proscriptive.

I'd like to see examples of configurations where the local root copy
*isn't* on the same host.  This is, I believe, a potentially more useful
configuration and avoids the needs for nasty hacks like the use of
"views" to allow the recursor to perform DNSSEC validation.

Ray