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

Bob Harold <rharolde@umich.edu> Mon, 05 March 2018 18:01 UTC

Return-Path: <rharolde@umich.edu>
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 BED3012DA25 for <dnsop@ietfa.amsl.com>; Mon, 5 Mar 2018 10:01:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu
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 wJxtha3Zh4Dt for <dnsop@ietfa.amsl.com>; Mon, 5 Mar 2018 10:01:34 -0800 (PST)
Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E29D4124234 for <dnsop@ietf.org>; Mon, 5 Mar 2018 10:01:33 -0800 (PST)
Received: by mail-lf0-x22e.google.com with SMTP id 70so24478136lfw.2 for <dnsop@ietf.org>; Mon, 05 Mar 2018 10:01:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6rrm16h5gce2kPq/AG/m05B2Mj4Mi8rKXz3deXzcztk=; b=LZEp6zi20FUD/PVJB+4REmo3ivByqCqwoGBJZlBz/7S12cGKqZdPC8A59jBqrhs2GL 2kdSOVH21JOgTFNSu1OUKQ4zPmxwjiotdDJHpL7oWrdbuVIX9/8CzrTKizRRdn8c4NdS FbOjJqdaDJKq6ci0sLmPE8TporHE9LePZu7RLksdVneqwdFeF18FtjVxE06yAMfEAba3 KwNihrarQbHoJX1+MvJI2G+o/Eet3h18MGpvldSb3m0XyoQmbwFqwSfXjYtE7RyXVUb8 pw2R8o/+WHSwbZhnZaQi3DK1DpV8aMSqH1H8BkU4707reXxXIf5i9I5QVyJ9upwZ1oHL igRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6rrm16h5gce2kPq/AG/m05B2Mj4Mi8rKXz3deXzcztk=; b=qh3m5crOy50JFFixDd0/eOl1l9YhIL4bP7Ky5vgjVnT8VBBEC1RoFlANtK1YOTjV+/ 5G7hGmwua1zsthT0RDSKPF2qzUc+cn7LSoOkXXAoAX03jX0MGJswbj53CtF28f01NtS/ o8s0yIpev2Hmdgsdui2IhpZjG/DBASFlWRD8sltln5IVfJ8HRU62IH4ESCbqYgmy+hlF 6d04oCNuRS7wsOMItR3OnmiYPupdJ7z52Uhe0NjBytOupq8JYXl/ttjWzOTpj6zZ+WtT GAI8660EomJBcQS5XfiGfBh6SNaWd74eu7TAcci2jQMifo8LQHbOtQ7TI9Ckm8lbQl0o O8+g==
X-Gm-Message-State: AElRT7FfwjpL1nqD0pAdYGSspX7JGvmJ1JA0jdRQST7+AyLPc2rfrRI8 eRjkB3ZHfpEJ0VuBwMhPjQSlFdTHE/jznAwYWyED51Li
X-Google-Smtp-Source: AG47ELtQQLNxayCgrXwbwEgXA63FjUUSeQn8zTNXwwUbKsxYySa6chgJWcQfqYNnymaXaso8Xz5IEXt47WteOv+mYQk=
X-Received: by 10.46.87.72 with SMTP id r8mr10888912ljd.93.1520272891282; Mon, 05 Mar 2018 10:01:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.46.18.21 with HTTP; Mon, 5 Mar 2018 10:01:29 -0800 (PST)
In-Reply-To: <9ab0208f-29e3-10b0-e360-125257b2b238@bellis.me.uk>
References: <151990782328.10030.7325038774873512859@ietfa.amsl.com> <9ab0208f-29e3-10b0-e360-125257b2b238@bellis.me.uk>
From: Bob Harold <rharolde@umich.edu>
Date: Mon, 05 Mar 2018 13:01:29 -0500
Message-ID: <CA+nkc8CqDB1vHXe4Wjd1xxeXtFaG2iGo1qTNtvOsCt=2pxUhTg@mail.gmail.com>
To: Ray Bellis <ray@bellis.me.uk>
Cc: IETF DNSOP WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="f403045f8918a5a1da0566ae1dd7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/TD0x2SQSDNz9rq2ElXvVz9YgwF0>
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: Mon, 05 Mar 2018 18:01:37 -0000

On Sat, Mar 3, 2018 at 5:07 PM, Ray Bellis <ray@bellis.me.uk> wrote:

>
>
> 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.
>
>
> Thanks for your work on this.

Just my $.02, I would prefer a solution that allowed exceptions, including
templates that "include" other templates and change some prameters.  An
added prefix with DNAME or PTR record(s).  Or even TXT records and define
your own format if necessary.

-- 
Bob Harold