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  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 -- e...@isc.org
> 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
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

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 -- e...@isc.org
Internet Systems Consortium, Inc.
___
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

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

[Alan Clegg]

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

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
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

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

[Sam Wilson]

On 2019-03-17 20:37:56 +, 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) " 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).


 



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
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

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

[Evan Hunt]

On Fri, Mar 22, 2019 at 03:55:39PM -0400, Bob Harold wrote:
> On Mon, Mar 18, 2019 at 5:26 PM Grant Taylor via bind-users <
> > 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.
> 
> I use:
> named-checkconf -p > named.conf.out

This isn't quite the same thing, though - "named-checkconf -p" will read
a named.conf file, check it for syntactic correctness, and prints it back
out in a normalized format with include files expanded. That's useful,
but I think Grant was suggesting having named itself dump its current
configuration state, which would be useful in a whole different way.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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

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

[Bob Harold]

On Mon, Mar 18, 2019 at 5:26 PM Grant Taylor via bind-users <
bind-users@lists.isc.org> wrote:

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

I use:
named-checkconf -p > named.conf.out

which I think is close enough, except for the comments.
You just need to know that view-level settings are at the end of the view,
not where you might expect.
It makes for a very lot of text to read through, but it is a 'standardized'
format.

-- 
Bob Harold
___
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

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

[Stephan von Krawczynski]

On Mon, 18 Mar 2019 12:32:56 -0700
Victoria Risk  wrote:

> Regarding allow-update:
> [...]
> Regards,
> 
> Vicky Risk
> Product Manager for BIND

Thank you for this very professional statement and for noting my suggestion
regarding "zone templates". Generally I would have voted for Alans' way of
fixing in 9.14.0, but for now I am hoping for the best ...

-- 
Regards,
Stephan von Krawczynski
___
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

Re: bind and certbot with dns-challenge

[Matthew Pounsett]

On Sun, 17 Mar 2019 at 13:34, Grant Taylor via bind-users <
bind-users@lists.isc.org> wrote:

>
> > I mean, sure you can use it perfectly, only not good if hosting hundreds
> > or thousands domains
>
> Why can't you use BIND to host hundreds or thousands of domains?
>

You definitely can.  My personal record is 3.7 million zones in a single
BIND instance, in production.   I did ten million in testing just to prove
we had growing space.  We did updates, adds, and removes at a rate of about
1500 per minute; BIND could have done more, we think, but our provisioning
software hit its limit around there.
___
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

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

[Victoria Risk]

Regarding allow-update:

- We do try to avoid ‘breaking existing deployments’ with this sort of change. 
We do also have to balance maintaining existing deployments with making 
improvements in security and usability. 

- When we ‘clarified’ behavior of BIND in 9.13.5 preventing the use of 
allow-update as an inherited option, apparently it was not entirely clear from 
code examination what the current behavior was.  Therefore, we made a more 
invasive change than we would normally make on purpose, without a fair amount 
of public notice, and possibly even some sort of open poll.

- We had no idea how common a configuration leveraging the inherited 
allow-update might be among users that we have no direct support relationship 
with. We have heard from several of you that this is an important feature for 
you:  I think we were surprised at this. Thank you for the feedback. This is 
the purpose of having development releases, so that early adopters can try 
upcoming changes and give us feedback. 

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

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

We may still implement this or a similar change in the future, but only after 
more discussion and communication and advance warning.  We have noted the 
suggestions for some sort of zone templating, and for a log of the full zone 
configuration, reflecting inherited options as well as explicitly configured 
options. 

Regards,

Vicky Risk
Product Manager for BIND


___
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

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

[Stephan von Krawczynski]

On Mon, 18 Mar 2019 12:06:57 -0400
Bob Harold  wrote:
>>[...]
> Thanks for the explanation, and for asking for input.
> And thanks for maintaining BIND, we depend on it.
> 
> My group manages about 3000 zones.
> In my opinion, 'everything' should be inherited, to make the configuration
> as simple as possible.  And it should be possible to override any setting
> at a lower level, for the exceptions.  It would be even better if I could
> 'group' zones and set configurations on the group.  Repeating the same
> configuration thousands of times seems like a waste.  I would even set
> "masters" and 'type' at the top level if I could, since 90% of my zones
> come from the same hidden master.  And if the file name could have a
> default or a pattern, that could be set at the top also, leaving only a
> list of zones names for most zones.
> 
> If you make the change, I can live with it, but it is not my preference,
> and does not seem like an improvement.
> 
> -- 
> Bob Harold

Thank you very much. It seems I am not alone with my way of using BIND.
Exactly such a setup is the cause for my suggestion of a "zone-default"
statement in another post. This would allow the grouping that you are looking
for.

-- 
Regards,
Stephan von Krawczynski

___
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

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

[Bob Harold]

On Sun, Mar 17, 2019 at 4:38 PM Alan Clegg  wrote:

> 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) " 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.
>  The chain of changes follows:
>
> 5136.   [cleanup]   Check in named-checkconf that allow-update and
> allow-update-forwarding are not set at the
> view/options level; fix documentation. [GL #512]
>
> This, if the change remains, will be updated to [func] and additional
> documentation will be added to the release notes.
>
> The other changes down this long and twisting passage are:
>
> 4836.   [bug]   Zones created using "rndc addzone" could
> temporarily fail to inherit an "allow-transfer"
> ACL that had been configured in the options
> statement. [RT #46603]
>
> and
>
> 2373.  [bug]   Default values of zone ACLs were re-parsed each
>time a new zone was configured, causing an
>overconsumption of memory. [RT #18092]
>
> It turns out that this series of changes, taken as a whole, removed
> allow-update as a global option.
>
> The question now becomes:  Is there a need for the ability to apply
> allow-update across all zones in your configuration?
>
> 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.
>
> I'm sure that there will be internal discussion here at ISC regarding
> this topic over the next week.
>
> 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.
>
> 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.
>
> If you have thoughts/opinions, please let us know!
>
> Alan Clegg, ISC
>

Thanks for the explanation, and for asking for input.
And thanks for maintaining BIND, we depend on it.

My group manages about 3000 zones.
In my opinion, 'everything' should be inherited, to make the configuration
as simple as possible.  And it should be possible to override any setting
at a lower level, for the exceptions.  It would be even better if I could
'group' zones and set configurations on the group.  Repeating the same
configuration thousands of times seems like a waste.  I would even set
"masters" and 'type' at the top level if I could, since 90% of my zones
come from the same hidden master.  And if the file name could have a
default or a pattern, that could be set at the top also, leaving only a
list of zones names for most zones.

If you make the change, I can live with it, but it is not my preference,
and does not seem like an improvement.

-- 
Bob Harold
___
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

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

[G.W. Haywood via bind-users]

Hello again,

On Mon, 18 Mar 2019, Alan Clegg wrote:


Take the personal attacks elsewhere if you don't mind.


My post was not intended to be a personal attack.  I did explain that
it was sent in more haste than I'd have liked, and perhaps it might
have been better if I'd have left it until I got back - but I don't
know how much better, as I'm told I'm not always very good at email
and judging by some of the responses I get that's probably correct.

In any case please do be assured that there's nothing personal going
on here, I'm simply trying to remind anyone who might think that it
doesn't hurt to be reminded (and I believe there are some) that the
ISC should have stability right up near the very top of its list of
objectives.  Amongst the characteristics of stability one may count
the lack of any requirement to make changes to configuration files,
especially at a potentially stressful time such as for example when
installing any new version of BIND.  I'd much prefer it didn't happen
at all, but if it's required then in my view the new release should be
entirely about the configuration file change(s) and nothing else, so
there's more flexibility in scheduling the change because there won't
be all those pesky new features to consider.


On Mon, 18 Mar 2019, G.W. Haywood wrote:
> Apologies for speaking frankly, but that's a lie.
I would like an apology for this because I am not a liar.


Well the apology was right there in that sentence, but here and now
and in public I apologize again.  I could take issue with a few other
things in your reply, but this is my apology, not some attempt at a
refutation or a justification, so here it ends.  More or less this
entire message is an apology, as you requested, and to anyone reading
who has better things to do, I apologize for that also.  Please let's
get back to BIND now.

--

73,
Ged.
___
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

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

[Grant Taylor via bind-users]

On 3/18/19 7:57 AM, Alan Clegg wrote:

Let me say that I didn't mean to disparage or discount small operators.


I didn't take anything you said as disparaging or as if it was trying to 
discount small operators.


You asked what seemed to me as legitimate questions.  I tried to provide 
what I thought were legitimate responses.  I also tried to provide 
qualification.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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

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

[Karl Auer]

On Mon, 2019-03-18 at 09:57 -0400, Alan Clegg wrote:
> Having said that, my $DAYJOB revolves (just a bit) around doing
> BIND/DHCP stuff all day long, so I may have a leg up on being able to
> twiddle with my configurations a bit more.  ;-)

Put that leg down, young man, and stop twiddling with your
configurations! You'll go BIND...

-- 
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389



___
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

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

[Alan Clegg]

On 3/17/19 10:43 PM, Grant Taylor via bind-users wrote:
> 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.

Let me say that I didn't mean to disparage or discount small operators.
 I'm purely gathering data.  I personally have 10 zones that I am
authoritative for on 2 BIND instances, so I'm fighting the "small
operator" fight right along with everyone else.

Having said that, my $DAYJOB revolves (just a bit) around doing
BIND/DHCP stuff all day long, so I may have a leg up on being able to
twiddle with my configurations a bit more.  ;-)

Thanks for your input and I do agree that there will be people bitten by
this - it's now being discussed as to how to deal with this (both short-
and long-term).

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

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

[Charles Elliott]

Time and time again, it has been shown that
there is huge value in diversity.  If you
were to invest a million dollars in Africa,
it most places you would get a million
dollars' worth of grass huts.  If you invest
a million dollars in
computer-programmer-designed software, most
of what you will get is a million dollars of
incremental changes that fit easily into the
existing system.

Most people on this list denigrate Microsoft
Server with its built-in DNS, but the facts
are that if you spin up a new Microsoft
Server installation, in about an hour you
have a completely configured, ready-to-go
domain name server, and few if any problems
thereafter.

Great success and huge amounts of money have
come to people who adopted a new perspective
on, and solved problems in, a particular
industry.  For example,

In the late 1800s, Rockefeller et al. made a
lot of money by creating the Standard Oil
Company, Inc. in the United States by
combining a large number of smaller oil
drillers and refiners.  Although Standard Oil
was eventually broken up because of antitrust
sentiment, at the time it was created it had
the support of the American people because
many of the displaced operators were in fact
just creating venues for horrific industrial
accidents.

For a time, General Motors made a great deal
of money manufacturing railroad locomotives
using production line techniques rather than
as a job shop.  Baldwin Locomotive went to
its grave after designing and building some
of the finest and most efficient steam
machines that ever existed, but despite
strenuous efforts it never could get over its
job shop mentality.

After the Second World War American railroads
were running worn-out equipment on  beat up
rails due to the inability to purchase new
equipment and spare parts during the war.
Despite the railroads' monumental
contribution to the war effort there was no
enthusiasm within the government for
refurbishing the industry due to the
railroads' perceived lousy safety record,
Eisenhower's and others' desires to re-create
the German autobahn system in the United
States, and the anticipated expansion of the
airlines.  Traditionally, locomotives were
sold to railroads based on the railroads'
Chief Engineers' knowledge of what motive
power his railroad needed.  General Electric
recognized that the railroads were
essentially broke and sent out its executives
to play golf with the railroads' financial
executives and thus sold a huge number of
diesel electric locomotives on terms that the
railroads could afford.

In its original conception, Sam Walton
created Wal-Mart stores as an integration of
modern IT with retailing.  "As of January 31,
2019, Walmart has 11,348 stores and clubs in
27 countries "  (Wikipedia)

What would happen if a marketing survey were
sent to executives who saw and paid the bills
for domain name service on the Internet?
What would happen if an expert, academic or
otherwise, were engaged to design a user
interface for an ideal domain name system?
Day in and day out the vast majority of
messages that appear on this bind list server
are about configuration issues.  Isn't it
time to get a new perspective on solving
these problems?

Charles Elliott


-Original Message-
From: bind-users
[mailto:bind-users-boun...@lists.isc.org] On
Behalf Of @lbutlr
Sent: Sunday, March 17, 2019 7:48 PM
To: bind-users@lists.isc.org
Subject: Re: allow-update in global options
(was Re: bind and certbot with dns-challenge)

On 17 Mar 2019, at 15:52, Grant Taylor via
bind-users  wrote:
> 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.

I disagree. I'd prefer the best decision be
made by consensus of the contributors rather
than the community at large. The community
includes a lot of people with a barely
functioning understanding of DNS and no basis
in knowledge for making a qualified decision
as to if this is a good thing or not.

I know this, because this describes me (and
everyone I've met in person who has to deal
with DNS) pretty accurately.



-- 
"I program Windows - of course it isn't
safe." - Meski


_
__
Please visit
https://lists.isc.org/mailman/listinfo/bind-u
sers to unsubscribe from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-u
sers

___
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

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

[Stephan von Krawczynski]

On Mon, 18 Mar 2019 11:37:50 +
Tony Finch  wrote:

> Stephan von Krawczynski  wrote:
> >
> > But to us it was clearly time to at least present the idea to configure
> > zones based on a user-defined default zone entry.  
> 
> Catalog zones have that kind of structure: there are options at the level
> of the whole catalog which individual zones can override.
> 
> Tony.

Yes, they have. But honestly while talking about issues I really don't want
any dynamic changes in the basic DNS handling (besides the cert challenge). If
your master dies, the setup is probably in trouble. Call me old-fashioned, but
a config file is a config file. It's a lot harder to inject something in a
setup not using rndc on such a fundamental scale ...

-- 
Regards,
Stephan von Krawczynski

___
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

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

[Alan Clegg]

On 3/18/19 6:53 AM, G.W. Haywood via bind-users wrote:

> I've been reading this exchange with growing frustration, and I hope a
> forthright response will be excused - especially since I now have to
> dash out to the hospital so I don't have more time to work on this.
> 
> On Mon, 18 Mar 2019, or possibly earlier, Alan Clegg wrote:
> 
>> The change was an unintended consequence ...
> 
> Please try not to let things like that escape into the wild, and
> please, please, NEVER turn them into deliberate actions purely for
> your own convenience.  If this means that you have to pull a release,
> then so what?  You've put me first.  That's fine by me.

You misunderstand what I was saying.

It was believed that "allow-update" was already disallowed - the code
being changed was just to add a message to better explain what was
happening.  The fact that this (seemingly non-related) change caused it
to come to the top was the "unintended consequence".

>> 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?
> 
> Please don't even *think* questions like that.  Maybe you could code
> it yourself, and send the script out with the next release, and take
> the flack when it breaks, and next time, well, not do it.

Thanks for telling me what not to think or ask.

If I don't ask questions, I don't get answers.  I am attempting to help.
I am attempting to figure out the lay of the land so that we can have
good internal conversations at ISC.

There are so many different ways that people can write their
configuration files (because ISC over the years has tried to accommodate
as many user requirements as possible) that the thought of writing a
"one-code-fits-all" to cover all of the possible ways this may need to
be changed is rather daunting.

>> ... roasted because they don't read the release notes.
> 
> Seems to me that you don't care anything like enough about this.

You tell me what to think, then you tell me that I don't care.

That's crap.  As anyone that ever took my classes in the past will tell
you, I really DO care about the user experience and about our customers
and users.  Quite a few changes in BIND were brought forward from the
classes that I taught due to my interest in making things better.

If I didn't care, why I am putting myself out to the slings and arrows?
 If I didn't care, I would not have, on a Sunday, asked internal
engineers exactly what the thought process was that had lead us to where
we were.

It surprised me that this was occurring and I decided to take it to the
list in a very open and honest way.

Take the personal attacks elsewhere if you don't mind.

>> 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.
> 
> Apologies for speaking frankly, but that's a lie.
I would like an apology for this because I am not a liar.

But I won't hold my breath.

While I said that we have thick skins due to having done this for a
while, I never expected to be called a liar.  I do not believe that we
have met, and for that I am sorry because you might have a different
view of me, but this... wow.

I'm ignoring the rest for now.

Alan Clegg
ISC
___
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

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

[Tony Finch]

Stephan von Krawczynski  wrote:
>
> But to us it was clearly time to at least present the idea to configure
> zones based on a user-defined default zone entry.

Catalog zones have that kind of structure: there are options at the level
of the whole catalog which individual zones can override.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Rattray Head to Berwick upon Tweed: Variable 2 or 3, becoming south or
southwest 3 or 4, occasionally 5 later. Moderate, occasionally rough at first.
Showers at first, occasional drizzle later. Good, occasionally moderate later.
___
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

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

[G.W. Haywood via bind-users]

Hi there,

I've been reading this exchange with growing frustration, and I hope a
forthright response will be excused - especially since I now have to
dash out to the hospital so I don't have more time to work on this.

On Mon, 18 Mar 2019, or possibly earlier, Alan Clegg wrote:


The change was an unintended consequence ...


Please try not to let things like that escape into the wild, and
please, please, NEVER turn them into deliberate actions purely for
your own convenience.  If this means that you have to pull a release,
then so what?  You've put me first.  That's fine by me.


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?


Please don't even *think* questions like that.  Maybe you could code
it yourself, and send the script out with the next release, and take
the flack when it breaks, and next time, well, not do it.


... roasted because they don't read the release notes.


Seems to me that you don't care anything like enough about this.


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.


Apologies for speaking frankly, but that's a lie.


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.


THE ISC HAS ALREADY HAD MY INPUT.  HERE, ON THIS LIST.


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.


If you can say that, I can now confidently tell you that even if you
are asking questions, you aren't asking the right questions and you
aren't listening to the answers anyway.  The people you're asking tend
to be busy, and the people that are likely to be able to give you
useful responses tend to be VERY busy.  Try asking:

"If the next release of BIND breaks your existing configurations and
you either have to start writing sed and awk scripts to fix them or
change to a different product, can you tell us

1. what else will be going on in your office that morning,

2. exactly how pleased you will be to have your load increased without
warning, and

3. as a result of the next disruption we've planned for you, how much
more likely will it be that you will change to a different product?"

Right, you say, you already know the answers.  Try also:

"Are thousands and thousands of surveys from suppliers annoying?"

Right, you say, you already know the answer to that one too.  (I have
a couple of milter rules that reply to email surveys with a specially
crafted 550 5.7.1 ...)

And please, DON'T EVER say:

"WE NEED YOUR INPUT"

when you've already had it.  If you make a survey, and the result you
get back is a big "Yawn", that input tells you what you need to know.

In case there's still any doubt, pop along to Vicky's office and have
a chat with her (even if it means that you'll have to get on a 'plane,
it will be worth it).  On the wall in Vicky's office you should find
an email from me.  I've reproduced it below together with her response
to it.  Apologies, Vicky, if that's taking a liberty.

There are users, and there's everything else, like the infrastructure.
The users alone give us enough trouble thank you very much, and *they*
usually only give trouble one at a time.

It's REALLY annoying when the infrastructure starts to give trouble,
because then all the users kick off, all at once, and they tell us
it's all our fault.

Curiously enough, it is.

--

73,
Ged.

8<--
Date: Wed, 26 Feb 2014 12:44:37 + (GMT)
From: "G.W. Haywood" 
To: bind-users@lists.isc.org
Subject: Re: BIND 9.10.0b1 has been released.

Hi there,

On Wed, 26 Feb 2014, Michael McNally wrote:


At ISC we are quite excited about the long list of new features and ...


I don't want to rain on your parade, and I know that this is likely to
be contentious, but I would just like to ask all at ISC (and I know it
isn't necessary, but I'll ask anyway) to remember that many of us out
here in the Totally Untamed Internet do not like our infrastructure
to be exciting.  Long lists of new features give me personally the
screaming heeby-jeebies.  The last thing anyone needs is a zero-day
BIND exploit in the wild.

Solid and dependable is good.  For the most part BIND is just that,
and I can't heap enough praise on the people who gave all that to us.

But I've noticed in the last few years that I've had to do more work
to keep up with bind developments when a few things have escaped that
perhaps should not have.  I've wanted to say this for at least a year
and I'm finally biting the bullet.

Please do not 

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

[Stephan von Krawczynski]

Please let me re-phrase the above suggestion to:
 
zone-default "default1" { type master; allow-update { 127.0.0.1; }; };
zone-default "default-slave" { type slave; masters { 10.0.0.1; 10.0.0.2; }; };

zone "mytest.domain" { default1; file "a_zone_file_for_mytest.domain"; };
zone "our-slave.domain" { default-slave; file "just_some_domain.bak"; };

It seems more accurate to name a new keyword "zone-default" instead of
including the new feature into the "zone" statement. This way it is absolutely
clear that it is no real zone, but a collection of options for some zone yet
to come later on.

-- 
Regards,
Stephan von Krawczynski

___
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

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

[Stephan von Krawczynski]

Ok, first let me thank Alan et al for clearing up the initial topic and making
the problem more visible than me was able to.

Just for the papers, we are hosting some hundred domains, and of course we are
able to handle sed. We can change the config regarding this issue. But to us
it was clearly time to at least present the idea to configure zones based on a
user-defined default zone entry. This would clarify (and shorten) the config
quite a bit. Something like:

zone "default1" { type master; allow-update { 127.0.0.1; }; };
zone "default-slave" { type slave; masters { 10.0.0.1; 10.0.0.2; }; };

zone "mytest.domain" { default1; file "a_zone_file_for_mytest.domain"; };
zone "our-slave.domain" { default-slave; file "just_some_domain.bak"; };

This would allow multiple default entries and still give a trivial overview
inside the config. To me, it looks easy to implement, does not interfere with
what is there and still gives the option of defining something "semi-global".
The "all-but-one" case is trivial with such a definition option.
What do you think?
--
Regards,
Stephan von Krawczynski



-- 
MfG,
Stephan von Krawczynski


--
ith Kommunikationstechnik GmbH

Lieferanschrift  : Reiterstrasse 24, D-94447 Plattling
Telefon  : +49 9931 9188 0
Fax  : +49 9931 9188 44
Geschaeftsfuehrer: Stephan von Krawczynski
Registergericht  : Deggendorf HRB 1625
--

___
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

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

[Grant Taylor via bind-users]

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 

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

[Alan Clegg]

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 

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

[Grant Taylor via bind-users]

On 3/17/19 5:48 PM, @lbutlr wrote:
I disagree. I'd prefer the best decision be made by consensus of the 
contributors rather than the community at large.


I agree that the decision should be made by the contributors / maintainers.

I'm saying that I think they should have data / information / opinions 
from the community while making their independent decision.


There is no guarantee that the decision will, or even should, match what 
the community thinks.


The community includes a lot of people with a barely functioning 
understanding of DNS and no basis in knowledge for making a qualified 
decision as to if this is a good thing or not.


Fair.

But they can still provide opinions / information / data that the 
contributors can use when they make their decision.


I know this, because this describes me (and everyone I've met in person 
who has to deal with DNS) pretty accurately.


I suspect you should give yourself more credit.  You know that you don't 
know everything.  I have dealt with too many people that don't even know 
that.  So you've got a leg up on them.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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

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

[@lbutlr]

On 17 Mar 2019, at 15:52, Grant Taylor via bind-users 
 wrote:
> 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.

I disagree. I'd prefer the best decision be made by consensus of the 
contributors rather than the community at large. The community includes a lot 
of people with a barely functioning understanding of DNS and no basis in 
knowledge for making a qualified decision as to if this is a good thing or not.

I know this, because this describes me (and everyone I've met in person who has 
to deal with DNS) pretty accurately.



-- 
"I program Windows - of course it isn't safe." - Meski


___
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

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

[Timothe Litt]

Data points:

I saw another report of this issue on gitlab - #913 just after my
previous note.  It indicated that a distributions initial configuration
breaks with the change.  I see that it has been updated by Alan since.

I checked my configuration files.

I use allow-update-forwarding at the options level.

I use update-policy at the zone level.

I don't currently use either at the view level.

So my configurations would break.  (I haven't had the cycles to run
9.13, unfortunately for you - apparently, fortunately for me :-)

I don't see the serious harm in allowing these options to be inherited -
there are certainly other options that, if incorrectly/accidentally
inherited, could be dangerous.  Allow-transfer; allow-query,
deny-answer-* I could go on alphabetically, but I'm pretty sure a case
could be made for the majority of options causing mischief if
inadvertently inherited.

I'm curious about why these particular options were singled out -- yes,
they update persistent zone data.  But denial of service, information
leaks, and using the wrong directories can also be serious.

In any case, where a change is made that invalidates existing
configurations, I strongly prefer a deprecation warning at least one
(non-development) release prior.  With documentation.

Given that these prerequisites didn't happen in this case, I believe
that regardless of the merits, the previous behavior should be reinstated.

If there is a determination that the benefits of the change outweigh the
costs, then add a deprecation warning a stable release prior (perhaps
now?) and update the documentation -- including the ARM & release notes.

Also, the same arguments should be applied to all the other inheritable
options -- if there is justification for other changes, it's much better
to force operators to make a bundled set of changes than to dribble them
out piecemeal.

FWIW: In general, I choose to place configuration statements at the
level resulting in the shortest configuration.  (Not for performance,
but for clarity/ease of maintenance.)  So that's sometimes "global
enable, exception disable", and sometimes the inverse.  (This can be
frustrated when there's no obvious inverse to a directive, but that's
for another day.)

Finally, I looked at the 9.13 ARM for a list of which options are
allowed in the view statement.  The view Statement Grammar lists
[view_option; ...] - 'view_option' appears nowhere else in the ARM.  The
definition and usage section (in chapter 5) says only: "Many of the
options given in the *options* statement can also be used within
a *view* statement,".  To find an explicit list, one has to go to the
VIEW section of chapter 8 (the man page for named.conf) - which isn't
tagged with 'view_option'.  This frustrates searchers and people
unfamiliar with the ARM structure.  Note that allow-update and
allow-update-forwarding both appear as valid in the view syntax there,
although in chapter 5 the descriptions on p.97 says "only zone, not
options or view".

My 3.5¢ (USD, but your local currency will do :-)

Timothe Litt
ACM Distinguished Engineer
--
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 

On 17-Mar-19 16:37, Alan Clegg wrote:
> 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) " 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.
>  The chain of changes follows:
>
> 5136.   [cleanup]   Check in named-checkconf that allow-update and
> allow-update-forwarding are not set at the
> view/options level; fix documentation. [GL #512]
>
> This, if the change remains, will be updated to [func] and additional
> documentation will be added to the release notes.
>
> The other changes down this long and twisting passage are:
>
> 4836.   [bug]   Zones created using "rndc addzone" could
> temporarily fail to inherit an "allow-transfer"
> ACL that had been configured in the options
> statement. [RT #46603]
>
> and
>
> 2373.  [bug]   Default values of zone ACLs were re-parsed each
>

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

[Grant Taylor via bind-users]

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

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.


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


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.

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.


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.


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 might not like such a change.  But I'm okay accepting such a change if 
they are properly communicated.  (See above comment about survey.)



If you have thoughts/opinions, please let us know!


See inline above.

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.


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



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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

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

[Alan Clegg]

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) " 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.
 The chain of changes follows:

5136.   [cleanup]   Check in named-checkconf that allow-update and
allow-update-forwarding are not set at the
view/options level; fix documentation. [GL #512]

This, if the change remains, will be updated to [func] and additional
documentation will be added to the release notes.

The other changes down this long and twisting passage are:

4836.   [bug]   Zones created using "rndc addzone" could
temporarily fail to inherit an "allow-transfer"
ACL that had been configured in the options
statement. [RT #46603]

and

2373.  [bug]   Default values of zone ACLs were re-parsed each
   time a new zone was configured, causing an
   overconsumption of memory. [RT #18092]

It turns out that this series of changes, taken as a whole, removed
allow-update as a global option.

The question now becomes:  Is there a need for the ability to apply
allow-update across all zones in your configuration?

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.

I'm sure that there will be internal discussion here at ISC regarding
this topic over the next week.

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.

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.

If you have thoughts/opinions, please let us know!

Alan Clegg, ISC
___
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

Re: bind and certbot with dns-challenge

[Alan Clegg]

On 3/17/19 7:13 AM, Stephan von Krawczynski wrote:
> Hello all,
> 
> I am using "BIND 9.13.7 (Development Release) " 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.

> And this brought me here with one question: why is it that bind/named does not
> evolve to a really useable nameserver for the most use-cases _today_, but
> instead gets more unusable with every new release?

Please provide input.  BIND is open source and is available for requests
etc. via gitlab.  We don't INTENTIONALLY make it "more unusable with
each release, but without your input we may be doing things that seem
good from the implementation side, but not from the operations side.

Provide input!  You'll help shape the world!

> I mean, sure you can use it perfectly, only not good if hosting hundreds or
> thousands domains - only this small change I just described lets your config
> file grow massively -, only not good if you want to implement something like
> blacklists, not good for an adblocker and so on.

I'm not sure how this relates.  Please feel free to follow up here (on
in Gitlab) with a bit more including "this configuration worked great
and is operationally what we need, but you broke it.  We do take
constructive criticism (and we also have thick skins, having been at it
as long as we have).

> But all that would be dead easy to do, iff really wanted.
> So why is it, that there is no global way of defining default zone
> definitions which are only overriden by the actual zone definition?

Some options just don't make sense at the global level.  Those are only
available at the view or zone level.

> Why is there no way to define a hosts-type-of-file with an URL-to-IP list?

Because DNS data only deals with DNS data and not URLs?   Again, give an
example of what you want, it will be considered and may actually appear
as a feature in future releases.  (this one, I doubt, however).

> Do you really want people to define 50.000 zones to perform adblocking?
> Configs have to be reloaded every now and then, is there really no idea how to
> shorten things a bit?

RPZ works at a global level.  Again, not sure what this question means.

> Don't get me wrong, bind is great (ok, collapsing during runtime since last 2
> updates, but ...).

Did you report these "collapses"?  This is the type of thing that tends
to happen when your distribution runs "Development Release" code.

> Nevertheless there are some things that can be enhanced quite a bit.

Tell us!  Help us!  Together we can be stronger!

Alan Clegg, ISC

___
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

Re: bind and certbot with dns-challenge

[Timothe Litt]

Named has options at the global, view and zone levels.  The 9.11 ARM
shows allow-update
in the options and zone statements.  If it's broken in 9.13 - note that
it is a "Developement Release".
So bugs are expected, and you should raise an issue on bind9-bugs or on
gitlab
(https://gitlab.isc.org/isc-projects/bind9/issues).

You can work around your issue by using 'include "my-common-stuff.conf";'
to simplify your configuration.  This is a useful strategy for things
that don't fit
the three-level model.

If you have large zones, you can speed up load time with
masterfile-format raw or map;
see the "tuning" section of the ARM for more information. 

Parsing configuration data is unlikely to be the dominant factor in
startup, but I'm
sure that the developers would welcome a reproducible test case that
shows otherwise.

You should consider update-policy instead of allow-update; it provides
much better control
and better security.

> It is really very obvious that this is only done by
> ideologists, not technical oriented people.
Actually, I've found that the contributors to named are very technical,
practical people.
Sometimes they introduce bugs, or ideas that work in one context but not
another.
They're responsive to criticism & contributions.  But name-calling is
generally not an
effective way to get anyone to help you.

Timothe Litt
ACM Distinguished Engineer
--
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 

On 17-Mar-19 10:35, Stephan von Krawczynski wrote:
> On Sun, 17 Mar 2019 12:40:35 +0100
> Reindl Harald  wrote:
>
>> Am 17.03.19 um 12:13 schrieb Stephan von Krawczynski:
>>> So why is it, that there is no global way of defining default zone
>>> definitions which are only overriden by the actual zone definition?  
>> maybe because it brings a ton of troubles and whoever deals with more
>> than 5 zones has automatic config management in place anyways?
> If you don't want to follow the positive way (how about a nice additional
> feature), then please accept the negative way: someone broke the config
> semantics by implementing a zone based-only "allow update". This option worked
> globally before (too), so we can assume it is in fact broken now.
> Can someone please point me to the discussion about this incompatible change?
>
>>> Why is there no way to define a hosts-type-of-file with an URL-to-IP list?
>>> Do you really want people to define 50.000 zones to perform adblocking?  
>> no, just use the right tool for the task, this don't fit into the domain
>> concept of named and hence you have dnsmasq and rbldnsd to step into
>> that niche
> In todays' internet this is no niche any more. And the right tool means mostly
> "yet-another-host" because you then need at least a cascade of two, one for
> dnsmasq and one for bind/named. A lot of overhead for quite a simple task...
>
>>> Configs have to be reloaded every now and then, is there really no idea
>>> how to shorten things a bit?  
>> ??
> Shorter config = shorter load time. The semantic change of "allow update" 
> alone
> leaves every setup with 1000 domains in a situation where 999 config statments
> more have to be read, interpreted and configured - just to end up in the same
> runtime setup. It is really very obvious that this is only done by
> ideologists, not technical oriented people.
>


signature.asc
Description: OpenPGP digital signature
___
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

Re: bind and certbot with dns-challenge

[Grant Taylor via bind-users]

On 3/17/19 8:35 AM, Stephan von Krawczynski wrote:

In todays' internet this is no niche any more.


Oh, there most certainly are niches today.  I think there are more today 
than there were before.


And the right tool means mostly "yet-another-host" because you then need 
at least a cascade of two, one for dnsmasq and one for bind/named. A 
lot of overhead for quite a simple task...


No, you don't need another host.

 · You can do things on different ports and / or IPs on the same host.
 · You can use different BIND features to do exactly what you want in a 
single daemon.  (See my previous email about RPZ / RPS / DLZ.)


Shorter config = shorter load time. The semantic change of "allow 
update" alone leaves every setup with 1000 domains in a situation where 
999 config statments more have to be read, interpreted and configured - 
just to end up in the same runtime setup.


See my previous email about load time.

TL;DR:  The config isn't the problem.  The zones are the problem.

It is really very obvious that this is only done by ideologists, not 
technical oriented people.


I disagree.

I've seen similar breaking changes in other products for (usually) well 
published / documented reasons.  Often times it's related to blocking 
new more important features and / or problems maintaining legacy code 
and / or security implications.


None of that is ideology.  That's program maintenance.

That being said, I don't know what is the case in the (broken) global 
allow-updates issue that you're talking about.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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

Re: bind and certbot with dns-challenge

[Grant Taylor via bind-users]

On 3/17/19 5:13 AM, Stephan von Krawczynski wrote:

Hello all,


Hi,

I am using "BIND 9.13.7 (Development Release) " 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.


That sounds like a bug to me.  If it's not a bug, and is to be expected, 
I would expect the change in behavior to be documented somewhere.


And this brought me here with one question: why is it that bind/named 
does not evolve to a really useable nameserver for the most use-cases 
_today_, but instead gets more unusable with every new release?


I can't say as I've experienced what you're referring to.  I still find 
BIND to be extremely flexible and feature rich for all of my DNS needs.


There are occasionally some off the typical DNS path things that I want 
to do that do require some pontification and careful implementation. 
But I've almost always been able to get BIND to do what I want.  Maybe 
once or twice I couldn't in the last ~20 years.


I mean, sure you can use it perfectly, only not good if hosting hundreds 
or thousands domains


Why can't you use BIND to host hundreds or thousands of domains?

only this small change I just described lets your config file grow 
massively


Config file size is independent of BIND's capability.

IMHO, this seems more like a dislike than an actual problem.

only not good if you want to implement something like blacklists, 
not good for an adblocker and so on.


Why is it not good?

What can you not do with BIND 9.13.7 that you could do with a previous 
version?


Also, /seriously/ take a good look into Response Policy Zones (RPZ). 
They make implementing blacklists a LOT easier.


I expect that Response Policy Service (RPS) to also make a similar, if 
not bigger, difference.  -  Granted, there is a documentation / OSS 
implementation gap that I'd like to see filled.


I also think that Dynamically Loadable Zones (DLZ) can also help here.

That's three different options that can be used with BIND.  I think all 
three can make it such that you don't need to define zones for each of 
the names that you want to filter.



But all that would be dead easy to do, iff really wanted.


I'm not sure what "all that" actually is.  As such, I'll respond to the 
multiple things that I think it could be.


"global allow-update…"  -  This sounds like a bug or an unknown design 
change.


"host hundreds or thousands of domains"  -  I see no reason why BIND 
can't do that.


"config file growth"  -  So.  Look into "include" and / or "DLZ". 
Restructure your config such that it's easier to manage and don't use a 
flat file.


"blacklists"  -  I'm doing this with multiple DLZs and am extremely 
happy with it.  IMHO it works wonderfully.


I'm even taking a web page (listing bad hosts) that someone is serving 
(for public consumption) scraping it (with their consent) and turning it 
into an RPZ on one server.  Then I'm using standard zone transfers to 
have multiple recursive resolvers filter based on the contents of the 
Response Policy Zone.  IMHO it works great.


So why is it, that there is no global way of defining default zone 
definitions which are only overriden by the actual zone definition?


I think that's a fair question.  Perhaps it's worth a feature request.

I've not looked, but I wonder if some of this can be defined via views.


Why is there no way to define a hosts-type-of-file with an URL-to-IP list?


I think that RPZ, RPS, and likely DLZ are much closer to doing that than 
you realize.


I counter with this.

Q:  Why can't Firefox on Linux read a Microsoft Word (.doc) file?
A:  Because it's not designed to do so.
A:  Nor is doing so even remotely in the scope of what it's designed to do.


Do you really want people to define 50.000 zones to perform adblocking?


You don't need to do that.

Again, /seriously/ take a good look into Response Policy Zones (RPZ). 
They make implementing blacklists a LOT easier.


Configs have to be reloaded every now and then, is there really no idea 
how to shorten things a bit?


It's my understanding that parsing the config file(s) is not the problem 
/ delay.


It's my understanding that the delay in loading many zones is converting 
the text zone files to binary in memory representations.


It's also my understanding that there are options to speed this up based 
on master zone file format.  Specifically binary vs text.


Don't get me wrong, bind is great (ok, collapsing during runtime since 
last 2 updates, but ...).


It sounds like you're trying to administer BIND the say way that you 
would have 10 ~ 20 years ago.  Take a look at some of the more modern 
options.  Especially if you are wanting to do more modern things like 
blacklisting.



Nevertheless there are some things that can be enhanced quite a bit.


I 

Re: bind and certbot with dns-challenge

[Stephan von Krawczynski]

On Sun, 17 Mar 2019 12:40:35 +0100
Reindl Harald  wrote:

> Am 17.03.19 um 12:13 schrieb Stephan von Krawczynski:
> > So why is it, that there is no global way of defining default zone
> > definitions which are only overriden by the actual zone definition?  
> 
> maybe because it brings a ton of troubles and whoever deals with more
> than 5 zones has automatic config management in place anyways?

If you don't want to follow the positive way (how about a nice additional
feature), then please accept the negative way: someone broke the config
semantics by implementing a zone based-only "allow update". This option worked
globally before (too), so we can assume it is in fact broken now.
Can someone please point me to the discussion about this incompatible change?

> > Why is there no way to define a hosts-type-of-file with an URL-to-IP list?
> > Do you really want people to define 50.000 zones to perform adblocking?  
> 
> no, just use the right tool for the task, this don't fit into the domain
> concept of named and hence you have dnsmasq and rbldnsd to step into
> that niche

In todays' internet this is no niche any more. And the right tool means mostly
"yet-another-host" because you then need at least a cascade of two, one for
dnsmasq and one for bind/named. A lot of overhead for quite a simple task...

> > Configs have to be reloaded every now and then, is there really no idea
> > how to shorten things a bit?  
> 
> ??

Shorter config = shorter load time. The semantic change of "allow update" alone
leaves every setup with 1000 domains in a situation where 999 config statments
more have to be read, interpreted and configured - just to end up in the same
runtime setup. It is really very obvious that this is only done by
ideologists, not technical oriented people.

-- 
Regards,
Stephan von Krawczynski
___
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