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

From: Mukund Sivaraman <[email-masked]>
Date: Mon, 19 Oct 2015 12:18:16 +0530

Hi everyone

> A new version of I-D, draft-muks-dnsop-dns-catalog-zones-00.txt
> has been successfully submitted by Mukund Sivaraman and posted to the
> IETF repository.
>
> Name:           draft-muks-dnsop-dns-catalog-zones
> Revision:       00
> Title:          DNS catalog zones
> Document date:  2015-10-18
> Group:          Individual Submission
> Pages:          20
> URL:            https://www.ietf.org/internet-drafts/draft-muks-dnsop-dns-catalog-zones-00.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-00
>
>
> 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.

ISC is implementing a zone catalog synchronization method in BIND. This
is the first public draft of various ideas and suggestions that were
pooled together and is named "DNS catalog zones". Some prelimnary
versions of a requirements specification (named "Easy Add Zone
requirements") and drafts were shared with DNS operators to gather
input.

Reviews of this first public draft are requested specifically from DNS
implementations and DNS operators. We want it to be adopted across
implementations so that operators have an easy time synchronizing
catalogs regardless of the implementation. This is why this draft is
brought here for discussion so that others can participate in its
design.

A zone based representation has been attempted and implemented before
(see Vixie's Metazones cited in the draft). Catalog zones borrows some
ideas from it.

We haven't yet settled on a list of zone properties (zone options in
BIND terminology) that are to be synchronized across
implementations. Comments on suitable zone properties are requested.

A list of BIND 9.10 zone options can be found in its administrator
reference manual (BIND 9.10 ARM) in section 6.1.25:

https://www.isc.org/downloads/bind/doc/bind-9-10/

We request implementations to consider if catalog zones would perform
well with your zone data structures (we considered a binary search
forest - an RB forest specifically for the BIND case).

The draft is currently under-specified. It requires further discussion
on open items, more elaborate nameserver behavior specification and
several items marked "TBD" to be completed. However at this stage, it is
more or less together as a design for public participation and comments.

		Mukund

---

From: Tony Finch <[email-masked]>
Date: Mon, 19 Oct 2015 11:32:27 +0100

Mukund Sivaraman <[email-masked]> wrote:
> >
> > Name:           draft-muks-dnsop-dns-catalog-zones-00
> > Title:          DNS catalog zones
> pooled together and is named "DNS catalog zones".

Yay! Why not call the feature "metazones" since that's the term we are
familiar with?

I recently hacked together a crappy version, which is deliberately dumb
and BIND-specific. http://dotat.at/prog/nsnotifyd/

I didn't implement Vixie-format metazones mainly out of laziness. My
configuration is based on named ACLs and server lists (etc.) which helps
to decouple the zone configurations from the server configurations -
addresses, TSIG keys, etc. I incorrectly thought that Vixie's format was
too address-based, but in fact I could have just left out the *.servers
sub-tree and let the metazone refer to implicit out-of-zone data. I would
have had to add an allow-query subtree too.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Thames, Dover, Wight, Portland, Plymouth: Northeast 4 or 5. Slight,
occasionally moderate in Plymouth. Occasional rain or drizzle. Moderate or
good, occasionally poor.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 19 Oct 2015 10:10:29 -0700

> Yay! Why not call the feature "metazones" since that's the term we are

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>.

> I didn't implement Vixie-format metazones mainly out of laziness. ...

it's terribly simple. laziness can't be an excuse, it just wasn't that 
difficult! see: <http://family.redbarn.org/~vixie/mz.tgz>.

-- 
Paul

---

From: Bob Harold <[email-masked]>
Date: Mon, 19 Oct 2015 14:31:22 -0400

On Mon, Oct 19, 2015 at 1:10 PM, Paul Vixie <[email-masked]> wrote:

> After reading both formats, I prefer
http://family.redbarn.org/~vixie/mz.tgz - ordered lists are multiple
records and can be as large a list as needed.  No new record types needed.
If I had seen this before, I probably would have implemented it by now.  It
has been on my wish list for a while.

-- 
Bob Harold

---

From: Evan Hunt <[email-masked]>
Date: Mon, 19 Oct 2015 19:50:58 +0000

> 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.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Mukund Sivaraman <[email-masked]>
Date: Tue, 20 Oct 2015 12:56:08 +0530

> 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

---

From: Tony Finch <[email-masked]>
Date: Tue, 20 Oct 2015 09:43:56 +0100

> difficult! see: <http://family.redbarn.org/~vixie/mz.tgz>.

Oh excellent, thanks, I didn't know the code was available. I shall have a
look! (All I previously knew about was the paywalled article in a Japanese
academic journal.)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fair Isle, Faeroes: West 5 or 6, backing south, then veering southwest later,
6 to gale 8, perhaps severe gale 9 later in north. Moderate or rough,
occasionally very rough later. Showers, then occasional rain. Moderate or
good, occasionally poor.