At Sat, 3 Mar 2018 22:07:57 +0000, Ray Bellis <r...@bellis.me.uk> 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop