Subject: [DNSOP] Request reviews of catalog zones draft (draft-muks-dnsop-dns-catalog-zones-01)

From: Mukund Sivaraman <[email-masked]>
Date: Mon, 13 Jun 2016 19:46:24 +0530

Hi everybody

On Mon, Jun 13, 2016 at 06:52:27AM -0700, [email-masked] wrote:
> 
> A new version of I-D, draft-muks-dnsop-dns-catalog-zones-01.txt
> has been successfully submitted by Mukund Sivaraman and posted to the
> IETF repository.
> 
> Name:		draft-muks-dnsop-dns-catalog-zones
> Revision:	01
> Title:		DNS catalog zones
> Document date:	2016-06-13
> Group:		Individual Submission
> Pages:		18
> URL:            https://www.ietf.org/internet-drafts/draft-muks-dnsop-dns-catalog-zones-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-muks-dnsop-dns-catalog-zones/
> Htmlized:       https://tools.ietf.org/html/draft-muks-dnsop-dns-catalog-zones-01
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-muks-dnsop-dns-catalog-zones-01
> 
> Abstract:
>    This document describes a method for automatic zone catalog
>    provisioning and synchronization among DNS primary and secondary
>    nameservers by storing and transferring the catalogs as regular DNS
>    zones.

Catalog zones is a new feature in BIND scheduled to be released in 9.11.
We request reviews of revision -01 the catalog zones draft.

The concept is similar to "metazones". It lets nameserver operators
provision (add/delete) zones on secondary nameservers automatically
using a special zone called a catalog zone representing an RFC 1035
catalog, which contains a list of zones (the catalog) and their
associated configuration. Updates to the catalog zone are automatically
picked up by secondaries and newly added zones are automatically setup,
and deleted ones are automatically removed on these secondary
nameservers.

An alpha preview of the implementation is available in BIND
9.11.0a3 (alpha) release: http://www.isc.org/downloads/

You can use this if you want to play with the feature, or if you are a
DNS developer and want to implement support for catalog zones.

An article by Jan-Piet Mens about the BIND 9.11 implementation:
http://jpmens.net/2016/05/24/catalog-zones-are-coming-to-bind-9-11/

A presentation about it (in Polish):
https://www.isc.org/wp-content/uploads/2016/03/plnog16-catzones.pdf

PowerDNS has a preliminary implementation for catalog zones, by
Peter van Dijk (Habbie): https://github.com/PowerDNS/powercatz

The goal of making this an internet draft is interoperability.  We are
hoping for this to become a standard catalog provisioning method among
DNS implementations. To help this forward, catalog zones uses DNS
protocol purely without any other out-of-band protocols, is designed not
to conflict with RFC 1035 name limits, and the zone configuration
represented in a catalog zone should be usable across DNS server
implementations.

As interoperability is high on our minds, we look to take the draft
through the WG.

		Mukund

---

From: Tony Finch <[email-masked]>
Date: Mon, 13 Jun 2016 18:04:02 +0100

I'll start by saying that I have not tried out catalog zones properly yet.
This review is from the point of view of how I currently manage my
configurations.

(Aside: there should probably be a copy of the draft in the BIND
distribution in doc/draft/.)

There is a lot of TBD in this draft which makes it hard to give a
meaningful review.

There's a big section mapping abstract configuration to DNS master file
syntax, which seems OK.

However, there doesn't seem to be anything about what member zone
properties are available and what they mean - I would expect them to be in
section 2.9 but that is almost empty.

There's a bit more in the latest BIND 9.11 ARM. This amounts to being able
to set the default-masters server addresses in named.conf, which can be
overridden by a global masters setting inside the catalog zone, which can
be overridden by per-member-zone masters settings.

(Aside: the BIND 9.11 release notes refer to chapter 9 of the ARM which I
think should be section 4.14.)

In my current configuration I have a two-level setup: the automatically
managed zone configuration (which would ideally be one or more catalog
zones in the future), and some more hands-on config for things like ACLs
and lists of masters. The zone configs just use names, e.g.

    zone cam.ac.uk {
        type slave; file "/zone/cam.ac.uk";
        masters { master-ipreg; };
        allow-transfer { secondaries; };
        allow-query { any; };
        also-notify { notify-isc; };
    };

The relevance for catalog zones is that indirect ACLs with names make it
easy to support secure zone transfer of the catalog zone without exposing
the TSIG keys used by the member zones. And using names for the other
settings gives us a sort of templated zone config.

For instance, for my public zones on my authoritative servers, the
allow-transfer ACL includes our local IP addresses, and TSIG keys for
ic.ac.uk and isc.org; if we could all use the same catalog zone then
ic.ac.uk could define their version of my ACL as "none" and isc.org could
define it to cover their anycast cloud.

... Having written that I have second thoughts because the coupling
between ACL names and third-party catalog zone contents is probably a
really bad idea :-)

Maybe for my own cluster I want really rich catalog zones, but if I'm
slaving a catz from a third party I want the member zone configurations to
be firmly pinned down.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Fisher: East 4 or 5, occasionally 6 later. Slight or moderate. Showers. Good,
occasionally poor.