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

Grant Taylor gtaylor at tnetconsulting.net
Mon Mar 18 02:43:37 UTC 2019


On 3/17/19 6:31 PM, Alan Clegg wrote:
> The change was an unintended consequence ending up in what was thought 
> to have been the correct behavior all along, so.. Yes.
> 
> How many zones are you authoritative for?

I think most people on this list have forgotten how to count as low as 
the number of zones that I am 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?

"difficult", no.  "annoying", maybe.  So what.  I make the change and 
move on.

> 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.
> 
> 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?

Arguably, release notes SHOULD be good enough.  (Should as in RFC sense.)

Very clearly is more an easy to find official documentation location.  I 
think release notes qualify.

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

Agreed.

In some ways "(very) clearly" is in the eyes of the beholder that is 
recovering from not doing things correctly.  Will they accept release 
notes as sufficient.  I can't speak for others.  I can say that even if 
I didn't read it before hand, and I did after the fact, I'd grump, but 
know that I was the one in error, fix said error, and move on with life.

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

Well, I'm the 21st then, and I'm using Linux.  :-D

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

Agreed.

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

Sounds like the ship has already sailed then.

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

Fair.

I was saying non-trivial in the sense that the change could have a 
sizeable impact.  Especially if BIND failed to start because of a long 
standing config stanza.

It may be that a low level SA is applying OS updates, including BIND, to 
systems and all of the sudden (when people didn't do their homework) 
BIND will no longer start.  So now said SA needs to escalate to the DNS 
SME to resolve the problem.

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

Maybe.  Depending on what the configuration file(s) look like.

> Yes, see above comment about surveys.

ACK

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

Agreed.

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

Agreed.

I expect that there are going to be people bitten by this.



-- 
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/20190317/0204c912/attachment.bin>


More information about the bind-users mailing list