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

Bob Harold rharolde at umich.edu
Thu Apr 4 13:57:05 UTC 2019


On Wed, Apr 3, 2019 at 7:08 PM Evan Hunt <each at isc.org> wrote:

> On Tue, Apr 02, 2019 at 06:28:02PM +0200, Alan Clegg wrote:
> > The answer to your question is:  "someone at ISC".
>
> Oh, I'm willing to take the public blame here, Alan. It's not like the
> commits don't have my name on them.
>
> The code the processes allow-update was written in an oddly circuitious
> fashion, and this combined with a badly misleading C comment led me to
> believe that allow-update and update-policy had the same rules about
> where they could be set - and, update-policy can only be set in zone
> statements. (This is personally embarrassing, but if you read the relevant
> code and comments in configure_view() you might see how easy it is to be
> misled.)
>
> I actually do still think that *ought* to be the rule for allow-update,
> but it wasn't, so when I cleaned things up I cleaned them up wrong, mea
> culpa.
>
> --
> Evan Hunt -- each at isc.org
> Internet Systems Consortium, Inc.
>
>
I think we should simplify the rules (and probably the code) to simply say:

"Options can be set at any level and apply to everything included in that
scope, unless overridden."


Why have exceptions to this?  This seems like expected behavior, and will
allow for simpler configurations in some cases.
No one is forced to use this, it is optional, but often convenient.

-- 
Bob Harold
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20190404/7f7c9643/attachment.html>


More information about the bind-users mailing list