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

Tony Finch <dot@dotat.at> Fri, 26 October 2018 13:18 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 268D3130DE9 for <dnsop@ietfa.amsl.com>; Fri, 26 Oct 2018 06:18:45 -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 NIo5fGCBRH9I for <dnsop@ietfa.amsl.com>; Fri, 26 Oct 2018 06:18:43 -0700 (PDT)
Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 1B19312872C for <dnsop@ietf.org>; Fri, 26 Oct 2018 06:18:42 -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]:56974) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1gG20e-000tBG-eD (Exim 4.91) (return-path <dot@dotat.at>); Fri, 26 Oct 2018 14:18:40 +0100
Date: Fri, 26 Oct 2018 14:18:40 +0100
From: Tony Finch <dot@dotat.at>
To: Ray Bellis <ray@bellis.me.uk>
cc: Bjørn Mork <bjorn@mork.no>, dnsop@ietf.org
In-Reply-To: <b8db3c3c-1ff3-f562-200c-3d054242186d@bellis.me.uk>
Message-ID: <alpine.DEB.2.20.1810261404400.24450@grey.csi.cam.ac.uk>
References: <47597960-3D11-4007-947D-19DBC7AF2BAC@icann.org> <75129a2d-8f91-48ca-dc27-7d6dfde685e0@bellis.me.uk> <alpine.DEB.2.20.1810261210150.24450@grey.csi.cam.ac.uk> <8736ss6htv.fsf@miraculix.mork.no> <b8db3c3c-1ff3-f562-200c-3d054242186d@bellis.me.uk>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="1870870841-566189844-1540559920=:24450"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/-ZhZbXNIbbUBiu8NyZgGlJdM0hI>
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 13:18:45 -0000

Ray Bellis <ray@bellis.me.uk> wrote:
> On 26/10/2018 12:57, Bjørn Mork wrote:
>
> > I'd also like to repeat my previous comment on the BIND example
> > config: Configuring a "static-stub" root zone has some unexpected
> > consequences. It makes the server refuse non-recursive queries for
> > root instead of redirecting.  Not a big problem, but it does make
> > "dig +trace" fail with such a server as starting point.

The setup I have on my toy server uses `match-recursive-only` on the
recursive view, which avoids this problem. It has the side-effect that
RD=0 queries do not probe the cache, but I haven't noticed any problems
due to that. (But this server is only used by me so it doesn't get a wide
variety of weird traffic.)

> > It would be nice to see this issue discussed in the RFC, including
> > justification of the "static-stub" zone type.  The reason for that
> > choice is not obvious.  To me, at least.
>
> From my (admittedly limited) testing I don't think there's any other
> BIND zone type that would work. When I tried "type forward" it sent not
> just the root zone queries to the specified server but *all* queries for
> all sub-domains thereof, too.

A `forward` zone makes `named` act as a recursive client for that part of
the namespace, so if you point it at an authoritative server for that
zone, you won't get the right answer for any delegations or out-of-zone
CNAMEs.

A `stub` zone works kind of like root hints: `named` queries the
configured server for the zone's NS records, then uses those. So it can't
be used to redirect queries to an unofficial secondary.

Directly using a `slave` zone in the recursive view suppresses validation,
so it can't detect on-the-wire mangling in the way the `static-stub` setup
does.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Lundy, Fastnet, Irish Sea: North 5 to 7, occasionally gale 8. Moderate or
rough. Squally showers, perhaps wintry later. Good occasionally moderate.