[FEATURE] ACLs and controls per zone

[ulvida]

Our needs

We are switching from a set of BIND9 NS servers with customized configurations to a new set automated with this role.

We used to allow query, transfer, as well as set notify and notify-also zone by zone, not globally for all the zones the authoritative NS. The set of visible and hidden secondary NS servers was not the same for each zone.

Till now we used the role to define a new set of NS servers for new zones and to migrate some zones with the same NS and that we could easily manage at the registrar, but now we want to automate all, we would like to preserve many of our barroque configurations, and, if possible, automate our existing NS servers preserving their specific configuration.

The idea

We would like to extend the role with the following functionnalities:

• a variable bind9_acl where we can define a customized set of ACLs, each with an arbitrary list of elements, addresses or acls,
• several configurations customizable zone by zone (static as well as dynamic ones), similar to those already existing for masters and dnssec :
  • allow_query, with a customized list of addresses or acls,
  • allow_transfer, with a customized list of addresses or acls,
  • notify (we should allow notify: false in masters and notify: true in slaves
  • notify_also to add a customized list to notify if changes

With these improvements, we can reproduce as such our present BIND9 configurations, were queries, transfers and notifies are denied by default and allowed zone by zone: we set bind9_ control variables to none, and set the zone by zone.

But we could code a little bit more to simplify our configuration: we could define a parameter bind9_config_profile, that defaults to global_controls which produces legacy configuration, but can also take the value per_zone_controls, where:

• global options are set to deny,
• for each zone, if there is no value for a control, the bind9_ variables' values are taken as defaults.

Therefore we have to define values for a zone only if the differ from defaults.

Question before PR

¿Do you agree that we clean a little bit the code (ex: useless |default() because of default variables' values)? ¿Do you agree we reformat code (ex: some more spaces in long formulas)?

[ulvida]

To avoid complexifying templetes' code, I plan to implement the features proposed as a new set of templates, proposing options for the bind9_templates variable's values.

[ulvida]

working on branch feature-issue5. First running version of the new set of templates: strict_authoritative/,

[ulvida]

@andrespias is working on the features in PR #8 merging the proposed templates' set new features in legacy one. This path has the advantage to let only one set of templates to maintain, but I think working on a new set of templates can be worthy to achieve robustness of BIND's configuration and new features for the role.

Documenting work led in fact to clarify the specifications for the templates' set. I also reconsidered BIND's ARM to design or re-design the way to implement each bind configuration parameter. I'm afraid I couldn't have done such improvements in the original templates without breaking backwards compatibility for other users of the role, or having a mess in templates' code.

As BIND administrator I felt into this error when trying to put an ACL in also-notify directive, and when I solved it I also came into this annoying problem to have to configure the same data in two places. The author of this post says he solved the problem building his conf files with m4. The role and templates also implement such task, managing ACLs and masters' lists in similar YAML variables and building masters' lists and ACLs with same name and data, when you need to feed it in also-notify and allow-transfer(or other allow-*) directives. Here ansible is also a "big hammer", but at least is an appropriate hammer to configure servers.