Subject: [DNSOP] Fwd: [EXT] New Version Notification for draft-toorop-dnsop-dns-catalog-zones-01.txt

From: Willem Toorop <[email-masked]>
Date: Wed, 15 Apr 2020 11:27:17 +0200

Dear all,

This is the new catalog zones draft as presented yesterday at the DNSOP
WG Interim meeting. The idea of catalog zones is to establish automatic
zone provisioning along existing primary/secondary relationships.

This is an earlier idea which was previously worked on by ISC authors.
The editor's pen has been picked up by authors from different DNS
Software implementations with the aim to create a cross-implementation
compatible version of catalog zones.
Most prominent modifications to earlier versions are:

 1. There are descriptions nor definitions of zone properties anymore
 2. A zone is required to reset state when its unique label changes
 3. The version TXT RR now can be a RRset to allow for versions that are
    backwards compatible with earlier versions.

Willem

-------- Doorgestuurd bericht --------
Onderwerp: 	[EXT] New Version Notification for
draft-toorop-dnsop-dns-catalog-zones-01.txt
Datum: 	Tue, 14 Apr 2020 04:02:23 -0700
Van: 	[email-masked]
Aan: 	Ondrej Sury <[email-masked]>, Libor Peltan <[email-masked]>,
Peter van Dijk <[email-masked]>, Willem Toorop
<[email-masked]>, Leo Vandewoestijne <[email-masked]>

A new version of I-D, draft-toorop-dnsop-dns-catalog-zones-01.txt
has been successfully submitted by Willem Toorop and posted to the
IETF repository.

Name: draft-toorop-dnsop-dns-catalog-zones
Revision: 01
Title: DNS Catalog Zones
Document date: 2020-04-14
Group: Individual Submission
Pages: 11
URL:
https://www.ietf.org/internet-drafts/draft-toorop-dnsop-dns-catalog-zones-01.txt
Status:
https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/
Htmlized:
https://tools.ietf.org/html/draft-toorop-dnsop-dns-catalog-zones-01
Htmlized:
https://datatracker.ietf.org/doc/html/draft-toorop-dnsop-dns-catalog-zones
Diff:
https://www.ietf.org/rfcdiff?url2=draft-toorop-dnsop-dns-catalog-zones-01

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.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Bob Harold <[email-masked]>
Date: Thu, 16 Apr 2020 08:37:44 -0400

On Wed, Apr 15, 2020 at 5:27 AM Willem Toorop <[email-masked]> wrote:

> Dear all,
>
> This is the new catalog zones draft as presented yesterday at the DNSOP WG
> Interim meeting. The idea of catalog zones is to establish automatic zone
> provisioning along existing primary/secondary relationships.
> This is an earlier idea which was previously worked on by ISC authors. The
> editor's pen has been picked up by authors from different DNS Software
> implementations with the aim to create a cross-implementation compatible
> version of catalog zones.
>    3. The version TXT RR now can be a RRset to allow for versions that
>    are backwards compatible with earlier versions.
>
> Willem
>
> Aan: Ondrej Sury <[email-masked]> <[email-masked]>, Libor Peltan
> <[email-masked]> <[email-masked]>, Peter van Dijk
> <[email-masked]> <[email-masked]>, Willem
> Toorop <[email-masked]> <[email-masked]>, Leo Vandewoestijne
> <[email-masked]> <[email-masked]>
>
5.1.  General Requirements

If there is a clash between an existing member zone's name and an
   incoming member zone's name (via transfer or update), the new
   instance of the zone MUST be ignored and an error SHOULD be logged.

-- I do not understand.  Can you give an example?

-- 
Bob Harold

---

From: Willem Toorop <[email-masked]>
Date: Thu, 16 Apr 2020 15:17:41 +0200

Op 16-04-2020 om 14:37 schreef Bob Harold:
> On Wed, Apr 15, 2020 at 5:27 AM Willem Toorop <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Dear all,
> 
>     This is the new catalog zones draft as presented yesterday at the
>     DNSOP WG Interim meeting. The idea of catalog zones is to establish
>     automatic zone provisioning along existing primary/secondary
>     relationships.
> 
>     This is an earlier idea which was previously worked on by ISC
>     authors. The editor's pen has been picked up by authors from
>     different DNS Software implementations with the aim to create a
>     cross-implementation compatible version of catalog zones.
>     Van: 	[email-masked] <mailto:[email-masked]>
>     Aan: 	Ondrej Sury <[email-masked]> <mailto:[email-masked]>, Libor
>     Peltan <[email-masked]> <mailto:[email-masked]>, Peter van
>     Dijk <[email-masked]>
>     <mailto:[email-masked]>, Willem Toorop
>     <[email-masked]> <mailto:[email-masked]>, Leo
>     Vandewoestijne <[email-masked]> <mailto:[email-masked]>
> 
> 
> 
> 5.1..  General Requirements
> 

An authoritative nameserver might have two or more catalog zones, each
associated with their own set of configuration.  In that case, the
member zone that was configured first (and associated with the settings
of the particular catalog zone it was a member of) will keep that
association, regardless of it being a member zone of other catalog zones
as well.

-- Willem

> 
> -- 
> Bob Harold
>  
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Richard Gibson <[email-masked]>
Date: Thu, 16 Apr 2020 10:05:52 -0400

Doesn't that preclude scenarios in which a zone transitions from one 
catalog to another?

---

From: Willem Toorop <[email-masked]>
Date: Thu, 16 Apr 2020 17:06:21 +0200

> Doesn't that preclude scenarios in which a zone transitions from one

Not necessarily, but we do need to provide more text here to describe
precisely how that would work yes. So thanks for bringing that up!

Something like:

	When a member zone is removed from a specific catalog zone, an
authoritative server MUST NOT remove the zone and associated state data
if the zone was not configured from that specific catalog zone.
	Only when the zone was configured from a specific catalog zone, and the
zone is removed as a member from that specific catalog zone, the zone
and associated state MUST be removed.
	Subsequently, after removal, an implementation MUST check if another
catalog zone is present with has the zone as a member. In that case the
zone must be configured and associated according to the set of
configuration associated with that catalog zone.
	If there are multiple other catalog zones which have the previously
removed zone as member, one should be picked randomly.

This is just a quick sketch text proposal.
I've submitted an issue for it in our github repo:

https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/issues/9

-- Willem