<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Data points:</p>
<p>I saw another report of this issue on gitlab - #913 just after my
previous note. It indicated that a distributions initial
configuration breaks with the change. I see that it has been
updated by Alan since.<br>
</p>
<p>I checked my configuration files.</p>
<p>I use allow-update-forwarding at the options level.</p>
<p>I use update-policy at the zone level.</p>
<p>I don't currently use either at the view level.</p>
<p>So my configurations would break. (I haven't had the cycles to
run 9.13, unfortunately for you - apparently, fortunately for me
:-)<br>
</p>
<p>I don't see the serious harm in allowing these options to be
inherited - there are certainly other options that, if
incorrectly/accidentally inherited, could be dangerous.
Allow-transfer; allow-query, deny-answer-* I could go on
alphabetically, but I'm pretty sure a case could be made for the
majority of options causing mischief if inadvertently inherited.</p>
I'm curious about why these particular options were singled out --
yes, they update persistent zone data. But denial of service,
information leaks, and using the wrong directories can also be
serious.
<p>In any case, where a change is made that invalidates existing
configurations, I strongly prefer a deprecation warning at least
one (non-development) release prior. With documentation.<br>
</p>
<p>Given that these prerequisites didn't happen in this case, I
believe that regardless of the merits, the previous behavior
should be reinstated.</p>
<p>If there is a determination that the benefits of the change
outweigh the costs, then add a deprecation warning a stable
release prior (perhaps now?) and update the documentation --
including the ARM & release notes.</p>
<p>Also, the same arguments should be applied to all the other
inheritable options -- if there is justification for other
changes, it's much better to force operators to make a bundled set
of changes than to dribble them out piecemeal.</p>
<p>FWIW: In general, I choose to place configuration statements at
the level resulting in the shortest configuration. (Not for
performance, but for clarity/ease of maintenance.) So that's
sometimes "global enable, exception disable", and sometimes the
inverse. (This can be frustrated when there's no obvious inverse
to a directive, but that's for another day.)<br>
</p>
<p>Finally, I looked at the 9.13 ARM for a list of which options are
allowed in the view statement. The view Statement Grammar lists
[view_option; ...] - 'view_option' appears nowhere else in the
ARM. The definition and usage section (in chapter 5) says only: "<span
style="color: rgb(0, 0, 0); font-family: "Times New
Roman"; font-size: medium; font-style: normal;
font-variant-ligatures: normal; font-variant-caps: normal;
font-weight: 400; letter-spacing: normal; orphans: 2;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; widows: 2; word-spacing: 0px;
-webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
255); text-decoration-style: initial; text-decoration-color:
initial; display: inline !important; float: none;">Many of the
options given in the<span> </span></span><span class="command"
style="color: rgb(0, 0, 0); font-family: "Times New
Roman"; font-size: medium; font-style: normal;
font-variant-ligatures: normal; font-variant-caps: normal;
font-weight: 400; letter-spacing: normal; orphans: 2;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; widows: 2; word-spacing: 0px;
-webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
255); text-decoration-style: initial; text-decoration-color:
initial;"><strong>options</strong></span><span style="color:
rgb(0, 0, 0); font-family: "Times New Roman";
font-size: medium; font-style: normal; font-variant-ligatures:
normal; font-variant-caps: normal; font-weight: 400;
letter-spacing: normal; orphans: 2; text-align: start;
text-indent: 0px; text-transform: none; white-space: normal;
widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255); text-decoration-style:
initial; text-decoration-color: initial; display: inline
!important; float: none;"><span> </span>statement can also be
used within a<span> </span></span><span class="command"
style="color: rgb(0, 0, 0); font-family: "Times New
Roman"; font-size: medium; font-style: normal;
font-variant-ligatures: normal; font-variant-caps: normal;
font-weight: 400; letter-spacing: normal; orphans: 2;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; widows: 2; word-spacing: 0px;
-webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
255); text-decoration-style: initial; text-decoration-color:
initial;"><strong>view</strong></span><span style="color: rgb(0,
0, 0); font-family: "Times New Roman"; font-size:
medium; font-style: normal; font-variant-ligatures: normal;
font-variant-caps: normal; font-weight: 400; letter-spacing:
normal; orphans: 2; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: 2;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255); text-decoration-style:
initial; text-decoration-color: initial; display: inline
!important; float: none;"><span> </span>statement,". To find an
explicit list, one has to go to the VIEW section of chapter 8
(the man page for named.conf) - which isn't tagged with
'view_option'. This frustrates searchers and people unfamiliar
with the ARM structure. Note that allow-update and
allow-update-forwarding both appear as valid in the view syntax
there, although in chapter 5 the descriptions on p.97 says "only
zone, not options or view".</span></p>
<p>My 3.5¢ (USD, but your local currency will do :-)</p>
<pre class="moz-signature" cols="72">Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
</pre>
<div class="moz-cite-prefix">On 17-Mar-19 16:37, Alan Clegg wrote:<br>
</div>
<blockquote type="cite"
cite="mid:%3Cb1abee4d-cacb-2632-13b6-caa8855e025d@isc.org%3E">
<pre class="moz-quote-pre" wrap="">On 3/17/19 2:51 PM, Alan Clegg wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On 3/17/19 7:13 AM, Stephan von Krawczynski wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
And you may have found a bug. I'm checking internally at this time.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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
</pre>
</blockquote>
</body>
</html>