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

Alan Clegg alan at clegg.com
Mon Mar 18 00:31:35 UTC 2019


On 3/17/19 5:52 PM, Grant Taylor via bind-users wrote:
> On 3/17/19 2:37 PM, Alan Clegg wrote:
>> It turns out that this series of changes, taken as a whole, removed
>> allow-update as a global option.
> 
> That sounds like either an unintended consequence -or- a change in
> anticipated ~> expected behavior by some people.

The change was an unintended consequence ending up in what was thought
to have been the correct behavior all along, so.. Yes.

>> The question now becomes:  Is there a need for the ability to apply
>> allow-update across all zones in your configuration?
> 
> I use allow-update at the global options level.

How many zones are you authoritative for?  Would it be a major
difficulty to (once) change the existing zones and then modify your
provisioning to add the "allow-update" option in the zone stanza?

>> Smaller operators should be able to add the allow-update per zone very
>> easily, and large operators should (probably) be doing things at a
>> much more granular level.
> 
> Can I add allow-update per zone?  Yes.
> 
> Will I be annoyed at needing to add the allow-update to each zone?  Yes.
> 
> Even if the allow-update wasn't intended to function at the global
> options level, the point remains that it has done so and the current
> expected behavior is that it will continue to do so.

Ford Pinto Automobiles weren't meant to burst into flames when hit from
the rear either, but ... yeah, not really to the same level, but again,
I'm interested in how many people (and how big their zone lists are)
would have an issue with a one-time change.

> So, if there is an official change to the contrary of the unofficial
> behavior, I think that it needs to be VERY CLEARLY communicated.

When you say VERY CLEARLY communicated, to what level would you raise
this communication?  Would you consider having it in the release notes
good enough?

I remember when the "allow-recursion" default ACL was changed from "any"
to "localhost; localnets;" and a few people (big networks) didn't read
the release notes... yeah, even if you have things well documented,
somebody is going to get roasted because they don't read the release notes.

>> I'm sure that there will be internal discussion here at ISC regarding
>> this topic over the next week.
> 
> Good.
> 
> I look forward to hearing what the general consensus is.

And when 9.14.0 is released, you'll definitely know what it is, but I'm
hoping to have something to tell you before then.  ;-)

> If the consensus is that the new behavior is desired, I would hope ~>
> expect for a survey of the BIND user community like I've seen in the
> past about removing / significantly altering functionality.

If we (ISC) base our changes on what we've gotten in response to the
surveys, we will make changes based on the fact that nearly all of the
somewhere around 20 people that use BIND are using Solaris.

Not enough people actually respond to our surveys to base any real
changes on the results.

Please, to EVERYONE on the list, when you see a survey from us, help us
to make the experience that you are having with BIND better by filling
out the survey.

If anyone can tell me why we have such low response rates to our
surveys, please let me know that as well... WE NEED YOUR INPUT.

>> We are hoping to release 9.14.0 soon and this would be an "allowed"
>> change (at a .0 release).  If we don't make this change in 9.14.0, it
>> won't be allowed in an official production release until 9.16.0 due to
>> the "no changes to the configuration file except at .0 releases" rule.
> 
> Hum.  I'd hate to think that do to misfortune of timing, we'd be stuck
> with this unexpected / inconsistent with prior version behavior until
> 9.16.0 came out.

No, the misfortune here is that if we DON'T put it in now, we will have
to wait for 9.16.0.  I'm guessing that if it goes into 9.14.0, it won't
be coming back out - there will be the "moment of pain" when people
change to the new option structure and then "voila", it's all over.

To change the current "we don't allow allow-updates in global options"
at this point will require a code change.  We are in code-freeze, so to
revert to the other behavior will delay the release of BIND 9.14.0.

>> At this moment, I (personally) believe that the change is fixing a
>> bug, as "allow-update" was not planned and is not a good idea at the
>> global option level.  I believe that it should be allowed only in zone
>> stanzas.
> 
> Opinions aside, the fact is that it has worked as a global option
> historically and this is a non-trivial change in behavior.

I agree that it has worked that way in the past, however, I do not
consider it to be non-trivial from the operations perspective.

A simple "awk" script should be able to make the required change across
the board in a few seconds.

> I might not like such a change.  But I'm okay accepting such a change if
> they are properly communicated.  (See above comment about survey.)
Yes, see above comment about surveys.

> I know that my few small BIND instances are a pitance compared to many.
> But I would be quite annoyed to learn that my long stable config
> suddenly no longer worked after updating BIND.  Especially if I didn't
> know why my config no longer worked or what I needed to do to fix it.
> This could be even worse if the failure is not detected quickly and
> instead lingers for a few days / weeks before the lack of an update
> ended up breaking DNS resolution in a production environment.

If you read the release notes prior to installing 9.14.0, you will know
that you need to change the location of the allow-updates option.

If, after breaking things because the default behavior changed and you
hadn't read the release notes, you can then read the release notes, and
you will know why it broke.

The error generated by named-checkconf is:

/etc/namedb/named.conf:19: 'allow-update' can only be set per-zone, not
in 'options'

I think that's pretty clear even if you don't read the release notes.

BIND creates this log message when "rndc reconfig" is run:

18-Mar-2019 00:15:29.081 general: info: received control channel command
'reconfig'
18-Mar-2019 00:15:29.081 general: info: loading configuration from
'/etc/namedb/named.conf'
18-Mar-2019 00:15:29.082 config: error: /etc/namedb/named.conf:19:
'allow-update' can only be set per-zone, not in 'options'
18-Mar-2019 00:15:29.082 general: error: reloading configuration failed:
failure

again, quite clear on the cause for the failure.

If starting (as will be the case if someone just install 9.14.0 without
changing the "allow-updates" to zone based):

18-Mar-2019 00:16:54.290 loading configuration from '/etc/namedb/named.conf'
18-Mar-2019 00:16:54.290 /etc/namedb/named.conf:19: 'allow-update' can
only be set per-zone, not in 'options'
18-Mar-2019 00:16:54.291 loading configuration: failure
18-Mar-2019 00:16:54.291 exiting (due to fatal error)

Again, very clear and straight forward.

> I share this as a joke and don't mean to ruffle any feathers.
> 
> https://memegenerator.net/img/instances/84240115/bug-fixed-ops-problem-now.jpg

I like it.  I often wish that I'd stayed in OPs than take the road that
I did, however.  :-)

AlanC


More information about the bind-users mailing list