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

From: [email-masked]
Date: Thu, 01 Mar 2018 04:37:03 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

        Title           : DNS Catalog Zones
        Authors         : Mukund Sivaraman
                          Stephen Morris
                          Ray Bellis
                          Witold Krecicki
	Filename        : draft-muks-dnsop-dns-catalog-zones-04.txt
	Pages           : 16
	Date            : 2018-03-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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-muks-dnsop-dns-catalog-zones/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-muks-dnsop-dns-catalog-zones-04
https://datatracker.ietf.org/doc/html/draft-muks-dnsop-dns-catalog-zones-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-muks-dnsop-dns-catalog-zones-04

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Ray Bellis <[email-masked]>
Date: Sat, 3 Mar 2018 22:07:57 +0000

On 01/03/2018 12:37, [email-masked] 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.

This no longer reflects the current BIND implementation, but we have
internal consensus that this is a cleaner design which will appear in a
future version of BIND 9.

We are also considering how we might provide a more generic template
system such that multiple member zones can share a common set of
configuration properties rather than them being specified individually
for each member zone.

For this, we're likely to propose something using DNAME.  One option
would be that for a particular member zone tagged with identifying label
"foo" that we use:

     foo.zones.$CATZ IN PTR example.com.
     foo.zones.$CATZ IN DNAME <template-id>.templates.$CATZ

i.e. the DNAME is stored at the same owner name as that member zone's
entry in the list of member zones.

However a disadvantage of this is that it would be impossible to place
any zone-specific properties below this record because they'd be
obscured by the DNAME.

Consequently, the zone could either have all properties come from the
template, or they could all be specified individually as child nodes,
but the zone couldn't have both[*]

We're therefore seeking feedback on whether that's considered an
unreasonable limitation, or whether it's necessary to still be able to
provide zone-specific overrides of the values found in the template.

Ray

[*] in either configuration it's still expected that the server would
fallback to an additional set of catalog-zone wide defaults for any
property whose value is unspecified.

---

From: Bob Harold <[email-masked]>
Date: Mon, 5 Mar 2018 13:01:29 -0500

On Sat, Mar 3, 2018 at 5:07 PM, Ray Bellis <[email-masked]> wrote:

> Thanks for your work on this.

Just my $.02, I would prefer a solution that allowed exceptions, including
templates that "include" other templates and change some prameters.  An
added prefix with DNAME or PTR record(s).  Or even TXT records and define
your own format if necessary.

-- 
Bob Harold

---

From: 神明達哉 <[email-masked]>
Date: Thu, 8 Mar 2018 11:08:37 -0800

At Sat, 3 Mar 2018 22:07:57 +0000,

> 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
this proposal.  (in that sense, I'm curious: is there other DNS
developer than ISC that is interested in implementing this proposal?)

I'm also not convinced that using standard DNS RRs is the best way to
implement the idea.  I see the advantage of it (most notably the
ability of synchronization via zone transfer), but various limitations
of the DNS protocol also make it unnecessarily complicated.  The issue
regarding DNAME is one example.  The way to implement the multi-valued
properties seems to be another.  I'm not convinced the advantages
obviously outweigh drawbacks.

Anyway, I have some comments on the draft body, below:

- Section 4.2.1

   NB: Catalog zones use some RR TYPEs (such as PTR) with alternate
   semantics to those originally defined for them.  Although this may be
   controversial, the situation is similar to other similar zone-based
   representations such as response-policy zones [RPZ].

  I think this justification is weak.  As this text seems to imply,
  I believe everyone agrees that (ab)using standard RRs for a
  different semantics in RPZ is controversial.  Perhaps in the case of
  RPZ a sufficiently large number of people accept it for reasons
  including inertia.  But I don't think a precedence of one
  controversial approach automatically justifies another controversial
  one simply because they are similar.  IMO the new one should have its
  own justification.

- Section 4.2.1

   It is an error for any single owner name within a catalog zone (other
   than the apex of the zone itself) to have more than one RR associated
   with it.

  It was not clear to me why this restriction was necessary, at least
  at the point of reading this text.  I guess this may be related to
  the ordering of ordered multi-valued properties, but I'm still not
  really sure about it.  It would be nice if it's clarified in more
  detail.

  Also, it's not clear what "error" means here.  Does that mean, for
  example, loading the zone should be refused if it violates this
  restriction?  I think this should be clarified.

- Section 4.3.4: minor typo, s/the the/the/

   specifying the property under the the sub-domain associated with the

- Section 5.1: s/the MUST/they MUST/ ?

   If the RDATA is split into multiple <character-string> elements the
   MUST be directly concatenated without any separating character.

--
JINMEI, Tatuya

---

From: Mukund Sivaraman <[email-masked]>
Date: Sat, 10 Mar 2018 21:56:15 +0530

Hi Jinmei

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

> 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

---

From: Tony Finch <[email-masked]>
Date: Sat, 10 Mar 2018 18:46:59 +0000

Mukund Sivaraman <[email-masked]> wrote:

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

I want to emphasize this point.

In my previous job running MXs it was amazingly easy to do in-band SMTP
call-forward address verification - one configuration was able to verify
addresses at dozens of departmental mail servers with all sorts of
different configurations. Trying to talk to each department's LDAP service
(if they had one) would have been a nightmare.

In my current job, I can provide a catalog zone and a bit of configuration
advice to make it much simpler for my colleagues to run stealth
secondaries - no need for them to adjust firewalls or scripts etc.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Fair Isle, Faeroes, Southeast Iceland: Easterly or northeasterly 5 to 7,
occasionally gale 8 in Fair Isle. Moderate or rough, occasionally very rough
later. Rain or showers. Good, occasionally poor.

---

From: tjw ietf <[email-masked]>
Date: Sat, 10 Mar 2018 15:12:15 -0500

(speaking not as chair but DNS operator)

At the last OARC, my co-worker did a lightning talk on his deployment of
MetaZones
(
https://indico.dns-oarc.net/event/27/session/7/contribution/39/material/slides/0.pdf
)

He attempted to contact the authors of the catalog-zones draft (as did I)
to talk about why this draft has some
deficiencies. but never heard back.   I felt this metazone work (which we
are efforting to open source through our employer)
should be given a deeper look.

The main problem I see is your exmaples always talk of "1 Primary DNS
Server and 1 (or more) DNS Secondary servers"
I would argue this is a severely outdated operational view, and to me feels
that you are out of touch with what
operators are actually deploying these days.

Tim
(again as myself)

On Sat, Mar 10, 2018 at 1:46 PM, Tony Finch <[email-masked]> wrote:

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

---

From: Paul Vixie <[email-masked]>
Date: Sat, 10 Mar 2018 12:39:05 -0800

if anybody wants to work on metazones, i encourage it, and would be 
happy to remain involved if desired.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 12 Mar 2018 12:24:30 +0100

On Sat, Mar 10, 2018 at 09:56:15PM +0530,
 Mukund Sivaraman <[email-masked]> wrote 
 a message of 80 lines which said:

> I have heard that there have been previous efforts for common
> nameserver configuration that were abandoned.

Several efforts, I believe, such as
<https://datatracker.ietf.org/doc/draft-regnauld-ns-communication/>

---

From: 神明達哉 <[email-masked]>
Date: Mon, 12 Mar 2018 10:59:11 -0700

At Sat, 10 Mar 2018 21:56:15 +0530,

> worked across implementations.

I can understand that, and, if it mainly means different versions of
BIND, that's certainly possible.  If it also means a unified way that
works for multiple different vendors, I personally doubt it's
feasible; I suspect those operators assume some kind of magic happens
in the unified mechanism and gracefully handle differences in config
details amount different vendors' implementations, and would complain
when they realize it doesn't work that way.  So...

> enthusiasm among the authors to do so in this draft.

...I'm personally not convinced this proposal will be useful as an
interoperable way to solve the issue (but, of course, it may be a good
idea as an enhancement to BIND) unless you actually address this
point.

That said,

> provides support for catalog zones.

if there is actually an interest (or better, implementation or
deployment cases) in having an interoperable way of synchronizing
primary/secondary meta info, it may become more convincing.  I'd
suggest you confirming the rumor and including the implementation
status in the draft.

--
JINMEI, Tatuya

---

From: Paul Vixie <[email-masked]>
Date: Mon, 12 Mar 2018 14:18:29 -0700

even after talking to muks@isc offline, i still don't understand why the 
original metazone proposal can't simply be standardized.

---

From: Mukund Sivaraman <[email-masked]>
Date: Tue, 13 Mar 2018 11:55:41 +0530

Hi Jinmei

> suggest you confirming the rumor and including the implementation

It was not a rumor. I heard this directly from one of the PowerDNS
developers.

https://github.com/PowerDNS/powercatz

		Mukund

---

From: "Peter van Dijk" <[email-masked]>
Date: Tue, 13 Mar 2018 12:51:43 +0100

>> developer than ISC that is interested in implementing this proposal?)

Yes. PowerDNS has wanted something like this for years but we never got 
around to writing it down. We are grateful that ISC is now doing that 
:-)

> provides support for catalog zones.

https://github.com/powerdns/powercatz

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/