Re: [DNSOP] Fwd: New Version Notification for draft-muks-dnsop-dns-catalog-zones-00

Mukund Sivaraman <muks@isc.org> Tue, 20 October 2015 07:26 UTC

Return-Path: <muks@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01401ACE5D for <dnsop@ietfa.amsl.com>; Tue, 20 Oct 2015 00:26:19 -0700 (PDT)
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
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 5HJQpOqHOdzw for <dnsop@ietfa.amsl.com>; Tue, 20 Oct 2015 00:26:17 -0700 (PDT)
Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 665671ACE5C for <dnsop@ietf.org>; Tue, 20 Oct 2015 00:26:17 -0700 (PDT)
Received: from jurassic.l0.malgudi.org (unknown [182.156.69.204]) (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 3A6B32BA0B09; Tue, 20 Oct 2015 07:26:13 +0000 (GMT)
Date: Tue, 20 Oct 2015 12:56:08 +0530
From: Mukund Sivaraman <muks@isc.org>
To: Evan Hunt <each@isc.org>
Message-ID: <20151020072608.GA24636@jurassic.l0.malgudi.org>
References: <20151019064816.GA14286@jurassic.l0.malgudi.org> <alpine.LSU.2.00.1510191107450.20598@hermes-2.csi.cam.ac.uk> <12355344.hnKWazBd09@linux-rfx1> <20151019195058.GA24031@isc.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY"
Content-Disposition: inline
In-Reply-To: <20151019195058.GA24031@isc.org>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/IBcg8SkRCyRz19HI2dy0wXBszW0>
Cc: dnsop@ietf.org, Paul Vixie <paul@redbarn.org>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-muks-dnsop-dns-catalog-zones-00
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 20 Oct 2015 07:26:19 -0000

On Mon, Oct 19, 2015 at 07:50:58PM +0000, Evan Hunt wrote:
> On Mon, Oct 19, 2015 at 10:10:29AM -0700, Paul Vixie wrote:
> > there's been enough churn at isc in recent years that probably noone now 
> > working there remembers metazones.
> > 
> > muks, et al, see: <http://family.redbarn.org/~vixie/mz.pdf>.
> 
> Metazones, and that particular URL, are referenced in the draft.
> 
> I've had no significant involvement in the catalog zones design, so
> I can't tell you why the metazone format wasn't used, but I'm pretty
> sure there were reasons for the decision.

(Apologies that some of what follows is implementation specific)

We initially were looking at issues with "rndc addzone", and ways to
improve it for operators so that it was possible to configure a
secondary nameserver for zones easily. The feature was named "Easy Add
Zone" and we gathered requirements. Due to the nature of it, the
requirements implied different designs - suggestions described how
things should behave and this implied radically different designs.

Some of the ideas were to improve rndc addzone and its sibling commands
to make them more featureful and better performing, such as adding more
commands and ability to work with multiple zones, etc. Another idea was
to use a dynamic database that a primary and secondaries could share,
which could be used for provisoning. One of the contenders that looked
very good for provisoning of large numbers of zones among namesevers
under different administrative controls was to use a zone based catalog.
The name "catalog" comes from RFC1035, and we had to call it something
at that stage (not "Easy Add Zone" which was incorrect and sounded
weird), so it was named "catalog zones".

Now, all of the proposals above have uses that are more suitable to some
operators, so we implemented or are implementing all of the above in
BIND. rndc addzone, showzone, modzone, delzone all got feature
improvements or were implemented, improved performance and we are
thinking of incorporating ways to add/remove multiple zones using a
single command. BIND also merged dynDB (similar to a "datasrc" in BIND
10), which allows loading .so objects that implement the db interface -
this allows plugging in support for external shared databases. It still
needs a bit of improvement for provisioning.

We had already discussed the design of catalog zones and were beginning
writing things down when Victoria Risk pointed out Metazones and we
checked it out. At the same time, a DNS operator who had been reviewing
requirements and the proposed catalog zones design also mentioned
Metazones to us. There are only so many straightforward ways to
represent catalogs as DNS zones, but one nice idea we picked up from
Metazones was to put the member zone names in the RDATA. Our initial
design had it as part of the owner names, which meant that the catalog
zone name itself and property names would eat into the DNS name
allocation and restrict the length of member zone names.

Having said that, catalog zones are structured differently due to the
way it was initially designed, and it tries to specify everything
clearly to make it simple to introduce zone properties across DNS
implementations. It supports both templated properties and per-zone
properties without naming size limits. We intend to make this a complete
detailed specification so any DNS vendor can implement it.

Development of this feature is as part of named, i.e., it isn't
implemented by auxiliary programs. This is similar to the case with
response policy zones where zone changes are automatically merged into
in-memory RPZ data structures.

We initially didn't plan to introduce new RR types in the first draft,
to leave it up for discussion as an open question.  We used RR TYPEs
such as CNAME for its singleton property to represent single names, but
abandoned it due to possible additional section processing in the query
path. We still use existing types where possible (such as PTR which
hopefully is not controversial as RFC1035 defines it just as a pointer
to any name). Some new RR TYPEs have been introduced to specify zone
properties for which there are no existing types. TXT could have been
used for all of these, but custom types would strictly enforce syntax.

		Mukund