Re: BIND9 Feature Request: inheritance-policy
Thanks Tony!This is essentially what we do today. In fact, I was ecstatic when acl's were finally able to be used for all address match-lists.However, (and I realize this not a common use case) with over 150,000 zones -- some in multiple views, with different sets of rules (e.g., allow-query, etc.). Even with short 3-5 character acl's, repeating them every few lines will make the file grow...a lot, and I expect to be at around 250,000 zones fairly soon.I understand I could play hide-the-body and stuff the acl's into include file(s), but this level of duplication has bothered me for a while I and was hoping for something a little more elegant.Having said this, your suggestion holds true and is appreciated!Thanks,John Original message > From: Tony Finch > You can sort of do what you want already, by defining> named ACLs. ACLs can refer to named ACLs: you can> include a named ACL or exclude it.Tony.-- f.anthony.n.finch https://dotat.at/work to the benefit of all___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND9 Feature Request: inheritance-policy
JW λ John Woodworth wrote: > Greetings, I would like to request a new feature which I hope will make > management of the 'allow' match-lists a tad easier.In short, an option > such as 'allow-transfer' in view or zone contexts could extend the > match-list as defined in the options section. You can sort of do what you want already, by defining named ACLs. ACLs can refer to named ACLs: you can include a named ACL or exclude it. For example, in my production config, I have some acl clauses roughly like the ones outlined below. I like named ACLs and named "masters" lists because they allow our config generation scripts to use symbolic names to describe a zone's config: query and xfer ACLs, upstream xfer sources, downstream notify targets. And when I look at the generated config I see the same symbolic names, so I have a reasonably consistent and simple vocabulary from the source of all knowledge through to the run-time config. (And the logs when I have persuaded the other end to do TSIG!) acl cudn { # cambridge university data network address ranges }; acl mythic { # mythic beasts xfer and auth servers }; acl secondaries { cudn; mythic; # some xfers allowed by key instead of address key tsig-maths; key tsig-imperial; }; zone cam.ac.uk { # blah blah allow-query { any; }; allow-transfer { secondaries; }; }; zone private.cam.ac.uk { # etc usw allow-query { cudn; }; allow-transfer { cudn; }; }; Tony. -- f.anthony.n.finchhttps://dotat.at/ work to the benefit of all___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND9 Feature Request: inheritance-policy
Greetings, I would like to request a new feature which I hope will make management of the 'allow' match-lists a tad easier.In short, an option such as 'allow-transfer' in view or zone contexts could extend the match-list as defined in the options section. This would flow from options->view->zone.This could minimize some of the duplication when the same set of servers are used at lower levels in the config.Additionally, a 'reset' flag would set the policy within its context, while clearing the accumulated list prior to setting the match-list in that context.Below is a proposed ABNF:inheritance-policy "{" 1*policy "};"reset = "reset"rule = "allow-query"rule =/ "allow-query-cache"rule =/ "allow-notify"rule =/ "allow-transfer"rule =/ "allow-update"rule =/ "allow-update-forwarding"rule =/ "also-notify"policy = rule "replace" *1reset ";"policy =/ rule "extend" *1reset ";"Best regards, John___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users