On Sat, Mar 3, 2018 at 5:07 PM, Ray Bellis <r...@bellis.me.uk> wrote:
> > > On 01/03/2018 12:37, internet-dra...@ietf.org 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. > > > 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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
