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 _______________________________________________ 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
