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