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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Sam Wilson
On 2019-03-17 20:37:56 +0000, Alan Clegg said:

> On 3/17/19 2:51 PM, Alan Clegg wrote:
>> On 3/17/19 7:13 AM, Stephan von Krawczynski wrote:
>>> Hello all,
>>>
>>> I am using "BIND 9.13.7 (Development Release) <id:6491691>" on arch linux. Up
>>> to few days ago everything was fine using "certbot renew". I had
>>> "allow-update" in nameds' global section, everything worked well. Updating to
>>> the above version threw a config error that "allow-update" has no global scope
>>> and is to be used in every single zone definition.
>>
>> And you may have found a bug.  I'm checking internally at this time.
>
> So, after a discussion with one of the BIND engineers this afternoon,
> this turned out to be quite an interesting and deep-rooted issue.
>
> During a cleanup of other code (specifically named-checkconf), code was
> changed that enforced what was believed to have been the default
> previously: specifically, allow-update was only allowed in zone stanzas.

Can I ask who believed it was previously the default?  I hope I'm not
misreading the first dozen or so lines of this page (which seems to be
reflected in previous editions of the ARM).

<https://ftp.isc.org/isc/bind9/cur/9.13/doc/arm/Bv9ARM.ch05.html#options_grammar>


Sam

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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

Alan Clegg-2
On 4/2/19 6:00 PM, Sam Wilson wrote:

>> During a cleanup of other code (specifically named-checkconf), code was
>> changed that enforced what was believed to have been the default
>> previously: specifically, allow-update was only allowed in zone stanzas.
>
> Can I ask who believed it was previously the default?  I hope I'm not
> misreading the first dozen or so lines of this page (which seems to be
> reflected in previous editions of the ARM).
>
> <https://ftp.isc.org/isc/bind9/cur/9.13/doc/arm/Bv9ARM.ch05.html#options_grammar>

The answer to your question is:  "someone at ISC".

However, can you post exactly what you mean by "this page" and what
default we are talking about?  Based on the history of this e-mail
thread, I think that we are talking about "allow-update" being available
at the global view (up until 9.13.3) and it not being allowed there (the
rest of the 9.13 branch up until 9.14.0)

In the options section of the ARM I see:

allow-update
Specifies which hosts are allowed to submit Dynamic DNS updates for
master zones. The default is to deny updates from all hosts. Note that
allowing updates based on the requestor's IP address is insecure; see
the section called “Dynamic Update Security” for details.

in 9.12
(https://ftp.isc.org/isc/bind9/cur/9.12/doc/arm/Bv9ARM.ch05.html#options_grammar)
and:

allow-update
When set in the zone statement for a master zone, specifies which hosts
are allowed to submit Dynamic DNS updates to that zone. The default is
to deny updates from all hosts. This can only be set at the zone level,
not in options or view.

in 9.13 and 9.14.  The text here (as referred to in your link) is the
updated text that was changed at the same time that the code change was
made, thus matching what was released in 9.14.

AlanC
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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

Evan Hunt
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 -- [hidden email]
Internet Systems Consortium, Inc.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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

Bob Harold

On Wed, Apr 3, 2019 at 7:08 PM Evan Hunt <[hidden email]> 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 -- [hidden email]
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


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users