>
> So it looks all clean and works.
> That said, I would add a couple of tests on strdup you have:
> - newnameserver->conf.file = strdup("/etc/resolv.conf");
> - newnameserver->id = strdup(address);
> and of course, I would do the LIST_ADDQ after those checks.
>
Good catch, done.
> Just fix t
ion of this
> patch?
>
> Baptiste
>
>
> On Thu, May 24, 2018 at 5:02 PM, Ben Draut wrote:
>
>> Willy, I think you've reviewed this one already. :) I fixed a few
>> things after your review, then you said you just wanted to wait
>> for Baptiste to ACK back on
Willy, I think you've reviewed this one already. :) I fixed a few
things after your review, then you said you just wanted to wait
for Baptiste to ACK back on 4/27.
I pinged Baptiste independently, just to make sure he had
seen your note. He replied, but he's been busy too. (Sorry
to add to the pil
>
> > I also fixed the memory leaks that you pointed out. (I think) But I did
> > notice that
> > valgrind reports that the 'newnameserver' allocation is being leaked
> > anyway, both
> > when using parse-resolv-conf as well as the regular nameserver
> > directive...Let
> > me know if I should do s
e you don't need to run this check on a read-only file, as it
> cannot fail, and if it really did, the user couldn't do anything about
> it anyway.
>
Great, removed.
I also fixed the memory leaks that you pointed out. (I think) But I did
notice that
valgrind reports that the
r's address as its name in the
resolvers section, as I thought that would have the highest probability of
avoiding name conflicts with other configured nameservers. Again I'm open
to feedback though.
Thanks!
Ben
From 98129271f32e6b9bc00880c967f9acf1233fed9b Mon Sep 17 00:00:00 2001
From: Be
Yep, will do.
On Tue, Apr 17, 2018 at 8:04 AM, Baptiste wrote:
>
> On Sat, Apr 14, 2018 at 5:39 AM, Jonathan Matthews <
> cont...@jpluscplusm.com> wrote:
>
>> On 14 April 2018 at 05:13, Willy Tarreau wrote:
>> > On Fri, Apr 13, 2018 at 03:48:19PM -0600, Ben Dr
This implements a simple warning for 'resolvers' sections that have no
nameservers.
Previously discussed here:
https://www.mail-archive.com/haproxy@formilux.org/msg29600.html
Thanks,
Ben
From fc6a36dabec89eef0eba13146cecbf157f0675b9 Mon Sep 17 00:00:00 2001
From: Ben Draut
Date: F
ews wrote:
> > On Fri, 13 Apr 2018 at 15:09, Willy Tarreau wrote:
> >
> > > On Fri, Apr 13, 2018 at 08:01:13AM -0600, Ben Draut wrote:
> > > > How about this:
> > > >
> > > > * New directive: 'use_system_nameservers'
> > &
2018 at 3:12 PM, Ben Draut wrote:
> I agree.
>
> On Mon, Apr 9, 2018 at 1:35 AM, Baptiste wrote:
>
>>
>>
>> On Fri, Apr 6, 2018 at 4:54 PM, Willy Tarreau wrote:
>>
>>> On Fri, Apr 06, 2018 at 04:50:54PM +0200, Lukas Tribus wrote:
>>> > &g
On Thu, Apr 12, 2018 at 3:06 PM, Willy Tarreau wrote:
> Hi Ben,
>
> On Thu, Apr 12, 2018 at 02:25:58PM -0600, Ben Draut wrote:
> > This changes the parser to run section postparsers once per section
> > instance, rather than only when the section type changes.
> >
&
This changes the parser to run section postparsers once per section
instance, rather than only when the section type changes.
This is motivated by the work discussed in
https://www.mail-archive.com/haproxy@formilux.org/msg29527.html. It should
make it easy to produce the warning mentioned in the s
xy/search?q=unspecified+dns+error
>
> We're expecting/testing to see if bind9's "no-case-compress { any; }"
> directive
> addresses this, but many folks do not control their DNS services (and as
> requisite
> AWS/Route53 capabilities mature, neither will we).
>
&
I agree.
On Mon, Apr 9, 2018 at 1:35 AM, Baptiste wrote:
>
>
> On Fri, Apr 6, 2018 at 4:54 PM, Willy Tarreau wrote:
>
>> On Fri, Apr 06, 2018 at 04:50:54PM +0200, Lukas Tribus wrote:
>> > > Well, sometimes when you're debugging a configuration, it's nice to be
>> > > able to disable some elemen
It's interesting that the default behavior of HAProxy resolvers can
conflict with the default behavior of bind. (If you're unlucky with
whatever bind has cached)
By default, bind uses case-insensitive compression, which can cause it to
use a different case in the ANSWER than in the QUESTION. (See
Assuming no one else is already working on the feature, I'd like to
contribute
the change to have the resolvers section fall back to parsing
/etc/resolv.conf
when no nameserver directives are present.
This was previously discussed here: https://www.mail-
archive.com/haproxy@formilux.org/msg28626.h
16 matches
Mail list logo
