allow-update in global options (was Re: bind and certbot with dns-challenge)

[Bob Harold]

On Mon, Mar 18, 2019 at 5:26 PM Grant Taylor via bind-users <
bind-users at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20190322/8d2eb368/attachment.html>