<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 18, 2019 at 5:26 PM Grant Taylor via bind-users <<a href="mailto:bind-users@lists.isc.org">bind-users@lists.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/18/19 1:32 PM, Victoria Risk wrote:<br>
> - We have decided to treat this change as a regression bug, and to fix <br>
> it in 9.14.1.  Alan argued that we should hold 9.14.0 and fix it there: <br>
> however we have decided to go ahead with 9.14.0 with the change we <br>
> already made in allow-update, which we will highlight in the release <br>
> notes as a ‘known issue'.  People who rely on a global-allow-update will <br>
> simply have to wait for 9.14.1 where we will attempt to restore the <br>
> prior behavior.   This is not a ’neat’ resolution, as it violates our <br>
> normal policy of not changing configuration defaults in the middle of a <br>
> stable branch, but it should be an adequate solution.<br>
<br>
 From my naive point of view, this seems perfectly reasonable.  I hoist <br>
my drink to the global community and the ISC community for the  the <br>
efforts and discussions that have ensued over this.<br>
<br>
> - Reasonable people (some of my colleagues at ISC) feel that users may <br>
> ’self-foot-shoot’ with an inherited allow-update, and that the inherited <br>
> behavior may not be obvious (similar options such as update-policy are <br>
> not inherited). At ISC we hear not infrequently from people who have <br>
> inherited a BIND implementation after the original administrator left, <br>
> and they are maintaining a configuration they don’t understand. This <br>
> experience, coupled with a generally increasing concern about DNS <br>
> security makes a reasonable argument for limiting opportunities to <br>
> ‘accidentally’ allow updates when adding new zones.<br>
<br>
As I was reading this, I found myself wondering if there is (I'll go <br>
look in a few minutes) an ability to have BIND dump the config it has <br>
read in.  Or conversely dump what it thinks the effective config is. <br>
The difference being an (inadvertent) global option { allow-update {…}; <br>
}; could be omitted from the global options {…}; section but included in <br>
each zone {…}; section.<br>
<br>
Perhaps something like this would help people identify what the <br>
effective config is.  I think it would help people produce config files <br>
that match (or approach) the output of such a utility.<br>
<br>
I would be tempted to have said utility omit comments, at least by <br>
default.  After all, that's not the config in memory.  Perhaps an option <br>
to pass comments from config file(s) through unmodified and possibly out <br>
of context would be of value.<br>
<br>
<br>
<br>
-- <br>
Grant. . . .<br>
unix || die<br></blockquote><div><br></div><div>I use:</div><div>named-checkconf -p > named.conf.out</div><div><br></div><div>which I think is close enough, except for the comments.</div><div>You just need to know that view-level settings are at the end of the view, not where you might expect.</div><div>It makes for a very lot of text to read through, but it is a 'standardized' format.</div><div><br></div><div>-- </div><div>Bob Harold</div><div> </div></div></div>