On Sun, Mar 17, 2019 at 4:38 PM Alan Clegg <acl...@isc.org> wrote: > On 3/17/19 2:51 PM, Alan Clegg wrote: > > On 3/17/19 7:13 AM, Stephan von Krawczynski wrote: > >> Hello all, > >> > >> I am using "BIND 9.13.7 (Development Release) <id:6491691>" on arch > linux. Up > >> to few days ago everything was fine using "certbot renew". I had > >> "allow-update" in nameds' global section, everything worked well. > Updating to > >> the above version threw a config error that "allow-update" has no > global scope > >> and is to be used in every single zone definition. > > > > And you may have found a bug. I'm checking internally at this time. > > So, after a discussion with one of the BIND engineers this afternoon, > this turned out to be quite an interesting and deep-rooted issue. > > During a cleanup of other code (specifically named-checkconf), code was > changed that enforced what was believed to have been the default > previously: specifically, allow-update was only allowed in zone stanzas. > The chain of changes follows: > > 5136. [cleanup] Check in named-checkconf that allow-update and > allow-update-forwarding are not set at the > view/options level; fix documentation. [GL #512] > > This, if the change remains, will be updated to [func] and additional > documentation will be added to the release notes. > > The other changes down this long and twisting passage are: > > 4836. [bug] Zones created using "rndc addzone" could > temporarily fail to inherit an "allow-transfer" > ACL that had been configured in the options > statement. [RT #46603] > > and > > 2373. [bug] Default values of zone ACLs were re-parsed each > time a new zone was configured, causing an > overconsumption of memory. [RT #18092] > > It turns out that this series of changes, taken as a whole, removed > allow-update as a global option. > > The question now becomes: Is there a need for the ability to apply > allow-update across all zones in your configuration? > > Smaller operators should be able to add the allow-update per zone very > easily, and large operators should (probably) be doing things at a much > more granular level. > > I'm sure that there will be internal discussion here at ISC regarding > this topic over the next week. > > We are hoping to release 9.14.0 soon and this would be an "allowed" > change (at a .0 release). If we don't make this change in 9.14.0, it > won't be allowed in an official production release until 9.16.0 due to > the "no changes to the configuration file except at .0 releases" rule. > > At this moment, I (personally) believe that the change is fixing a bug, > as "allow-update" was not planned and is not a good idea at the global > option level. I believe that it should be allowed only in zone stanzas. > > If you have thoughts/opinions, please let us know! > > Alan Clegg, ISC >
Thanks for the explanation, and for asking for input. And thanks for maintaining BIND, we depend on it. My group manages about 3000 zones. In my opinion, 'everything' should be inherited, to make the configuration as simple as possible. And it should be possible to override any setting at a lower level, for the exceptions. It would be even better if I could 'group' zones and set configurations on the group. Repeating the same configuration thousands of times seems like a waste. I would even set "masters" and 'type' at the top level if I could, since 90% of my zones come from the same hidden master. And if the file name could have a default or a pattern, that could be set at the top also, leaving only a list of zones names for most zones. If you make the change, I can live with it, but it is not my preference, and does not seem like an improvement. -- Bob Harold
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
