<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 17, 2019 at 4:38 PM Alan Clegg <<a href="mailto:aclegg@isc.org">aclegg@isc.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 3/17/19 2:51 PM, Alan Clegg wrote:<br>
> On 3/17/19 7:13 AM, Stephan von Krawczynski wrote:<br>
>> Hello all,<br>
>><br>
>> I am using "BIND 9.13.7 (Development Release) <id:6491691>" on arch linux. Up<br>
>> to few days ago everything was fine using "certbot renew". I had<br>
>> "allow-update" in nameds' global section, everything worked well. Updating to<br>
>> the above version threw a config error that "allow-update" has no global scope<br>
>> and is to be used in every single zone definition.<br>
> <br>
> And you may have found a bug. I'm checking internally at this time.<br>
<br>
So, after a discussion with one of the BIND engineers this afternoon,<br>
this turned out to be quite an interesting and deep-rooted issue.<br>
<br>
During a cleanup of other code (specifically named-checkconf), code was<br>
changed that enforced what was believed to have been the default<br>
previously: specifically, allow-update was only allowed in zone stanzas.<br>
The chain of changes follows:<br>
<br>
5136. [cleanup] Check in named-checkconf that allow-update and<br>
allow-update-forwarding are not set at the<br>
view/options level; fix documentation. [GL #512]<br>
<br>
This, if the change remains, will be updated to [func] and additional<br>
documentation will be added to the release notes.<br>
<br>
The other changes down this long and twisting passage are:<br>
<br>
4836. [bug] Zones created using "rndc addzone" could<br>
temporarily fail to inherit an "allow-transfer"<br>
ACL that had been configured in the options<br>
statement. [RT #46603]<br>
<br>
and<br>
<br>
2373. [bug] Default values of zone ACLs were re-parsed each<br>
time a new zone was configured, causing an<br>
overconsumption of memory. [RT #18092]<br>
<br>
It turns out that this series of changes, taken as a whole, removed<br>
allow-update as a global option.<br>
<br>
The question now becomes: Is there a need for the ability to apply<br>
allow-update across all zones in your configuration?<br>
<br>
Smaller operators should be able to add the allow-update per zone very<br>
easily, and large operators should (probably) be doing things at a much<br>
more granular level.<br>
<br>
I'm sure that there will be internal discussion here at ISC regarding<br>
this topic over the next week.<br>
<br>
We are hoping to release 9.14.0 soon and this would be an "allowed"<br>
change (at a .0 release). If we don't make this change in 9.14.0, it<br>
won't be allowed in an official production release until 9.16.0 due to<br>
the "no changes to the configuration file except at .0 releases" rule.<br>
<br>
At this moment, I (personally) believe that the change is fixing a bug,<br>
as "allow-update" was not planned and is not a good idea at the global<br>
option level. I believe that it should be allowed only in zone stanzas.<br>
<br>
If you have thoughts/opinions, please let us know!<br>
<br>
Alan Clegg, ISC<br></blockquote><div><br></div><div>Thanks for the explanation, and for asking for input.</div><div>And thanks for maintaining BIND, we depend on it.</div><div><br></div><div>My group manages about 3000 zones.</div><div>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.</div><div><br></div><div>If you make the change, I can live with it, but it is not my preference, and does not seem like an improvement.</div><div><br></div><div>-- </div><div>Bob Harold</div><div><br></div></div></div>