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

"John Dickinson" <jad@sinodun.com> Fri, 26 October 2018 10:32 UTC

Return-Path: <jad@sinodun.com>
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 9FAE6130DC0 for <dnsop@ietfa.amsl.com>; Fri, 26 Oct 2018 03:32:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 8iD8UbCdvu8Z for <dnsop@ietfa.amsl.com>; Fri, 26 Oct 2018 03:32:47 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (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 930E0130DC9 for <dnsop@ietf.org>; Fri, 26 Oct 2018 03:32:47 -0700 (PDT)
Received: from [2001:b98:204:102:fff1::f145] (port=52134 helo=[192.168.12.13]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <jad@sinodun.com>) id 1gFzQ2-0008Ee-2F; Fri, 26 Oct 2018 11:32:46 +0100
From: "John Dickinson" <jad@sinodun.com>
To: "Ray Bellis" <ray@bellis.me.uk>
Cc: dnsop@ietf.org
Date: Fri, 26 Oct 2018 11:32:39 +0100
X-Mailer: MailMate (1.12r5523)
Message-ID: <8DC9B868-E939-4AFA-86E5-7A4708562059@sinodun.com>
In-Reply-To: <75129a2d-8f91-48ca-dc27-7d6dfde685e0@bellis.me.uk>
References: <47597960-3D11-4007-947D-19DBC7AF2BAC@icann.org> <75129a2d-8f91-48ca-dc27-7d6dfde685e0@bellis.me.uk>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-BlackCat-Spam-Score: 0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/MyjOMDPfHSUe631Mj4HikUKuByg>
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 10:32:50 -0000

On 26 Oct 2018, at 10:52, Ray Bellis wrote:

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

I agree, there is no need to restrict the document to loopback and we 
should not be using examples that require non-standardised features like 
views.

John

> Ray
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop


John Dickinson

http://sinodun.com

Sinodun Internet Technologies Ltd.
Magdalen Centre
Oxford Science Park
Robert Robinson Avenue
Oxford OX4 4GA
U.K.