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

[Grant Taylor]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4008 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20190318/5714ef96/attachment.bin>