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
