Hi Jinmei On Thu, Mar 08, 2018 at 11:08:37AM -0800, 神明達哉 wrote: > 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
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. > this proposal. (in that sense, I'm curious: is there other DNS > 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop