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 pr
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
fashi
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 previou
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"
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:
> n
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:
> > howev
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
f
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
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 perso
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-u
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
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 re
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
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 th
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 you
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
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
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 l
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
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.
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 a
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"
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 ti
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 z
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
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 / opi
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 b
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 opt
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
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, everythin
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 versi
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-
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 t
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 versio
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 tr
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
36 matches
Mail list logo
