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

[Mukund Sivaraman <[e-mail]>]

Hi Jinmei

On Thu, Mar 08, 2018 at 11:08:37AM -0800, 神明達哉 wrote:
> At Sat, 3 Mar 2018 22:07:57 +0000,
> Ray Bellis <[e-mail]> 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