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
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
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
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:
>
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:
> >
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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 ~>
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 /
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
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
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
27 matches
Mail list logo