Re: [DNSOP] I-D Action: draft-muks-dnsop-dns-catalog-zones-04.txt

Ray Bellis <ray@bellis.me.uk> Sat, 03 March 2018 22:08 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 753CD127333 for <dnsop@ietfa.amsl.com>; Sat, 3 Mar 2018 14:08:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 a0oTefjxHZYf for <dnsop@ietfa.amsl.com>; Sat, 3 Mar 2018 14:08:00 -0800 (PST)
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 798D21272E1 for <dnsop@ietf.org>; Sat, 3 Mar 2018 14:08:00 -0800 (PST)
Received: from [88.212.170.147] (port=50689 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 1esFJr-0002Er-3O (Exim 4.72) for dnsop@ietf.org (return-path <ray@bellis.me.uk>); Sat, 03 Mar 2018 22:07:55 +0000
To: dnsop@ietf.org
References: <151990782328.10030.7325038774873512859@ietfa.amsl.com>
From: Ray Bellis <ray@bellis.me.uk>
Message-ID: <9ab0208f-29e3-10b0-e360-125257b2b238@bellis.me.uk>
Date: Sat, 3 Mar 2018 22:07:57 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <151990782328.10030.7325038774873512859@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_BqjZwjpuYG5OeXz7xS9beScpfA>
Subject: Re: [DNSOP] I-D Action: draft-muks-dnsop-dns-catalog-zones-04.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Sat, 03 Mar 2018 22:08:02 -0000


On 01/03/2018 12:37, internet-drafts@ietf.org wrote:

> Abstract: This document describes a method for automatic DNS zone
> provisioning among DNS primary and secondary nameservers by storing
> and transferring the catalog of zones to be provisioned as one or
> more regular DNS zones.

This version of the Catalog Zones draft has undergone significant
restructuring, in particular to separate out the mechanism by which
single-valued and multi-valued properties are specified.

This no longer reflects the current BIND implementation, but we have
internal consensus that this is a cleaner design which will appear in a
future version of BIND 9.

We are also considering how we might provide a more generic template
system such that multiple member zones can share a common set of
configuration properties rather than them being specified individually
for each member zone.

For this, we're likely to propose something using DNAME.  One option
would be that for a particular member zone tagged with identifying label
"foo" that we use:

     foo.zones.$CATZ IN PTR example.com.
     foo.zones.$CATZ IN DNAME <template-id>.templates.$CATZ

i.e. the DNAME is stored at the same owner name as that member zone's
entry in the list of member zones.

However a disadvantage of this is that it would be impossible to place
any zone-specific properties below this record because they'd be
obscured by the DNAME.

Consequently, the zone could either have all properties come from the
template, or they could all be specified individually as child nodes,
but the zone couldn't have both[*]

We're therefore seeking feedback on whether that's considered an
unreasonable limitation, or whether it's necessary to still be able to
provide zone-specific overrides of the values found in the template.

Ray

[*] in either configuration it's still expected that the server would
fallback to an additional set of catalog-zone wide defaults for any
property whose value is unspecified.