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

Mukund Sivaraman <muks@isc.org> Sat, 10 March 2018 16:26 UTC

Return-Path: <muks@isc.org>
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 C4827126B7E for <dnsop@ietfa.amsl.com>; Sat, 10 Mar 2018 08:26:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no 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 Ogqd92iVpSfd for <dnsop@ietfa.amsl.com>; Sat, 10 Mar 2018 08:26:29 -0800 (PST)
Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 368C11200B9 for <dnsop@ietf.org>; Sat, 10 Mar 2018 08:26:29 -0800 (PST)
Received: from jurassic (unknown [49.203.221.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 315C532C0777; Sat, 10 Mar 2018 16:26:23 +0000 (UTC)
Date: Sat, 10 Mar 2018 21:56:15 +0530
From: Mukund Sivaraman <muks@isc.org>
To: =?utf-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Cc: Ray Bellis <ray@bellis.me.uk>, dnsop <dnsop@ietf.org>
Message-ID: <20180310162615.GA28458@jurassic>
References: <151990782328.10030.7325038774873512859@ietfa.amsl.com> <9ab0208f-29e3-10b0-e360-125257b2b238@bellis.me.uk> <CAJE_bqe-5-aD7yTkTSzu+fpSDEJw_TCYyL792cfqboDQXhmJ_g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAJE_bqe-5-aD7yTkTSzu+fpSDEJw_TCYyL792cfqboDQXhmJ_g@mail.gmail.com>
User-Agent: Mutt/1.9.2 (2017-12-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/CMw2Nm5N0kmHZpMPLjyui9RjNR8>
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, 10 Mar 2018 16:26:31 -0000

Hi Jinmei

On Thu, Mar 08, 2018 at 11:08:37AM -0800, 神明達哉 wrote:
> At Sat, 3 Mar 2018 22:07:57 +0000,
> Ray Bellis <ray@bellis.me.uk> 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.
> 
> I've read draft-muks-dnsop-dns-catalog-zones-04.  I see the motivation
> of automating the synchronization of primary/secondary configurations.
> Personally, however, I'm not (yet?) convinced that this should be
> "standardized" in the form of an RFC or that this should be done
> through another tricky use of DNS.  One big reason for standardization
> is to have a unified way that is interoperable with multiple different
> vendors.  But when it comes to configuration, difference on
> vendor-specific options often matters, and unless the common basic set
> of configuration is sufficiently common, a generic and interoperable
> mechanism will be useless.  I'm not yet convinced about it regarding

Some background of how/why catalog zones feature in BIND 9.11 and the
draft came to be is that we often got feedback about requiring better
ways to provision zones and content on multiple nameservers, and
different operators had different ideas about it. They wanted to improve
performance, reduce the scope for mistakes, and have a method that
worked across implementations.

BIND 9.11 shipped with some features for different types of
requirements:

- dyndb support (not possible to update catalog, but it allows an operator to serve shared DB based answers, and dynamic answers)
- improvements to rndc delzone, addzone, modzone, etc. for dynamic zone additions/removals
- catalog zones

Catalog zones emerged after a lot of argum^wdiscussions on how to
simplify provisioning. The primary focus at the start was providing a
way to update the zone catalog (~RFC 1035 "catalog" from where catalog
zones gets its name) on primary and automatically on secondary
nameservers. It was obvious that nameservers were distributed across
organization boundaries with different administrative controls. We
settled on using a zone representation as it used existing zone transfer
protocol (and authorizations) and would involve minimal changes for both
implementations and operations vs. inventing a new protocol. The idea
has been done before as metazones by Vixie. Indeed, interoperability was
on our minds and we took care to ensure that walking zone data
structures used by existing implementations would not be sub-optimial
for this use.

The point about configuration provisioning is well put. Zone config is
also something that an operator wants to provision, but here it gets
dirty because config feature availability differs greatly among
implementations. Some operators have told us that they would like a way
for various DNS implementations to support a common config format
directly or indirectly, but doing this is easier said than done. I have
heard that there have been previous efforts for common nameserver
configuration that were abandoned.

(Without my ISC hat on, I initially imagined that the config provisoning
would be out-of-band using locally installed template config, where the
zones in the catalog would pick a template by name. For operators with a
very large number of zones (the typical use-case for catalog zones), the
same zone config is typically shared, so this would have fit in.)

The draft as it stands provides a way to specify config options within
the zone, but does not specify an explicit list of options. There is no
enthusiasm among the authors to do so in this draft.

Some people already want catalog zones draft to include a lot more
things which would further complicate it. IMO we should not attempt to
solve every possible use-case and simplify as much as possible.

> this proposal.  (in that sense, I'm curious: is there other DNS
> developer than ISC that is interested in implementing this proposal?)

So far: I was told that PowerDNS has implemented a plug-in/script that
provides support for catalog zones.

		Mukund