BIND9 Feature Request: inheritance-policy

[JW λ John Woodworth]

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

[Tony Finch]

Post by JW λ John Woodworth
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.

[JW λ John Woodworth]

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 <***@dotat.at>> 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  <***@dotat.at>  https://dotat.at/work to the benefit of all