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

[神明達哉 <[e-mail]>]

At Sat, 3 Mar 2018 22:07:57 +0000,
Ray Bellis <[e-mail]> 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.

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