Re: Logs full TCP incoming and outgoing packets

[Jonathan Matthews]

On 10 April 2018 at 00:04,   wrote:
> Hello everybody,
>
> For an application, I use haproxy in TCP mode but I would need to log, from
> the main load balancer machine, all the TCP transactions (incoming packets
> sent to the node then the answer that is sent back from the node to the
> client through the haproxy load balancer machine).
>
> Is it possible to do such a thing ? I started to dig in the ML and found few
> information about capturing the tcp-request, which does not work for now...
> and I need the response as well... so preferred to ask if someone have got
> an experience doing this. Sure, it will have a performance penalty but
> exhaustive logging is more important than that and it it the best solution
> to avoid a lot of changes in the existing infrastructure we just
> load-balanced.

I don't believe this is possible inside haproxy right now.

If I *had* to do this, I'd start by saying "no", and then I'd work out
how to run a tcpdump process on the machine with carefully tuned
filters and a -w parameter. Then I'd drink something strong.

J

Logs full TCP incoming and outgoing packets

[florent]

Hello everybody,


For an application, I use haproxy in TCP mode but I would need to log, 
from the main load balancer machine, all the TCP transactions (incoming 
packets sent to the node then the answer that is sent back from the node 
to the client through the haproxy load balancer machine).



Is it possible to do such a thing ? I started to dig in the ML and found 
few information about capturing the tcp-request, which does not work for 
now... and I need the response as well... so preferred to ask if someone 
have got an experience doing this. Sure, it will have a performance 
penalty but exhaustive logging is more important than that and it it the 
best solution to avoid a lot of changes in the existing infrastructure 
we just load-balanced.



Best regards,
Florent

Re: Only start on CentOS7 in debug...

[Geert Van Muylem]

Hi Aleks,


I've recompiled with

make TARGET=linux2628 USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1 USE_SYSTEMD=1


And used the system file as you proposed... (The -Ws gave a problem when 
compiling without USE_SYSTEMD)


It seems to work!


Thanks


Only when stopping the service:

Should I worry about the last 2 messages?



Apr  9 21:44:13 haproxy systemd: Stopping HAProxy Load Balancer...

Apr  9 21:44:13 haproxy haproxy: [WARNING] 098/214408 (8092) : Exiting Master 
process...

Apr  9 21:44:13 haproxy haproxy: [ALERT] 098/214408 (8092) : Current worker 
8097 exited with code 143

Apr  9 21:44:13 haproxy haproxy: [WARNING] 098/214408 (8092) : All workers 
exited. Exiting... (143)

Apr  9 21:44:13 haproxy systemd: haproxy.service: main process exited, 
code=exited, status=143/n/a

Apr  9 21:44:13 haproxy systemd: Stopped HAProxy Load Balancer.

Apr  9 21:44:13 haproxy systemd: Unit haproxy.service entered failed state.

Apr  9 21:44:13 haproxy systemd: haproxy.service failed.


Geert


From: Aleksandar Lazic 
Sent: Monday, April 9, 2018 9:17 PM
To: Geert Van Muylem; haproxy@formilux.org
Subject: Re: Only start on CentOS7 in debug...

Hi Geert.

Am 09.04.2018 um 20:54 schrieb Geert Van Muylem:
> Hi,
>
>
> I've downloaded and compiled haproxy version 1.8.7 on CentOS7
>
> (make TARGET=linux2628 USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1)
>
>
> The proxy only starts as it should be if I add the "-d"
>
> My haproxy.service
>
>
> [Unit]
> Description=HAProxy Load Balancer
> After=syslog.target network.target
>
> [Service]
> EnvironmentFile=/etc/sysconfig/haproxy
> ExecStart=/usr/sbin/haproxy -d -f /etc/haproxy/haproxy.cfg -p
> /run/haproxy.pid $OPTIONS
> ExecReload=/bin/kill -USR2 $MAINPID
> KillMode=mixed
>
> [Install]
> WantedBy=multi-user.target
> "/usr/lib/systemd/system/haproxy.service" 12L, 303C

https://cbonte.github.io/haproxy-dconv/1.8/management.html#3
HAProxy version 1.8.5 - Management Guide - 
cbonte.github.io
cbonte.github.io
HAProxy is a single-threaded, event-driven, non-blocking daemon. This means is 
uses event multiplexing to schedule all of its activities instead of relying on 
the system to schedule between multiple activities.




I suggest to use `-db` instead of `-d` , but what's the reason why you
don't try the included systemd file?

http://git.haproxy.org/?p=haproxy-1.8.git;a=blob;f=contrib/systemd/haproxy.service.in;h=7a8b6bead2df23bc4e16e8edddfd0aacde454572;hb=HEAD

There is also a nice Makefile to create a working systemd file ;-)

http://git.haproxy.org/?p=haproxy-1.8.git;a=tree;f=contrib/systemd;hb=HEAD

Regards
Aleks

> OK -> with -d
> -
>
> Apr 09 20:43:32 haproxy.doom.be haproxy[3935]: epoll : pref=300,  test
> result OK
>
> Apr 09 20:43:32 haproxy.doom.be haproxy[3935]: poll : pref=200,  test
> result OK
>
> Apr 09 20:43:32 haproxy.doom.be haproxy[3935]: select : pref=150,  test
> result FAILED
>
> Apr 09 20:43:32 haproxy.doom.be haproxy[3935]: Total: 3 (2 usable), will
> use epoll.
>
> Apr 09 20:43:32 haproxy.doom.be haproxy[3935]: Available filters :
>
> Apr 09 20:43:32 haproxy.doom.be haproxy[3935]: [SPOE] spoe
>
> Apr 09 20:43:32 haproxy.doom.be haproxy[3935]: [COMP] compression
>
> Apr 09 20:43:32 haproxy.doom.be haproxy[3935]: [TRACE] trace
>
> Apr 09 20:43:32 haproxy.doom.be haproxy[3935]: Proxy http_back started.
>
> Apr 09 20:43:32 haproxy.doom.be haproxy[3935]: Proxy http_back started.
>
> I can see the stats and the requests are forwarded to the first
> server...(second is not yet configured)
>
>
> NOK -> without -d
>
> --
>
> Apr 09 20:46:38 haproxy.doom.be systemd[1]: Stopping HAProxy Load
> Balancer...
>
> Apr 09 20:46:38 haproxy.doom.be systemd[1]: Started HAProxy Load Balancer.
>
> Apr 09 20:46:38 haproxy.doom.be systemd[1]: Starting HAProxy Load
> Balancer...
>
>
>
> global
>log /dev/log local0
>log /dev/log local1 notice
>chroot /var/lib/haproxy
>stats timeout 30s
>user haproxy
>#group haproxy
>daemon
>
> defaults
>log global
>mode http
>option httplog
>option dontlognull
>timeout connect 5000
>timeout client 5
>timeout server 5
>
> frontend http_front
>bind *:80
>stats uri /haproxy?stats
>default_backend http_back
>
> backend http_back
>balance roundrobin
>server BERT 10.10.8.30:80 check
>server ERNIE 10.10.8.31:80 check
> "/etc/haproxy/haproxy.cfg" 27L, 504C
>
>
> Thanks
> Geert

Re: Only start on CentOS7 in debug...

[Aleksandar Lazic]

Hi Geert.

Am 09.04.2018 um 20:54 schrieb Geert Van Muylem:
> Hi,
> 
> 
> I've downloaded and compiled haproxy version 1.8.7 on CentOS7
> 
> (make TARGET=linux2628 USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1)
> 
> 
> The proxy only starts as it should be if I add the "-d"
>
> My haproxy.service
> 
> 
> [Unit]
> Description=HAProxy Load Balancer
> After=syslog.target network.target
> 
> [Service]
> EnvironmentFile=/etc/sysconfig/haproxy
> ExecStart=/usr/sbin/haproxy -d -f /etc/haproxy/haproxy.cfg -p
> /run/haproxy.pid $OPTIONS
> ExecReload=/bin/kill -USR2 $MAINPID
> KillMode=mixed
> 
> [Install]
> WantedBy=multi-user.target
> "/usr/lib/systemd/system/haproxy.service" 12L, 303C

https://cbonte.github.io/haproxy-dconv/1.8/management.html#3

I suggest to use `-db` instead of `-d` , but what's the reason why you
don't try the included systemd file?

http://git.haproxy.org/?p=haproxy-1.8.git;a=blob;f=contrib/systemd/haproxy.service.in;h=7a8b6bead2df23bc4e16e8edddfd0aacde454572;hb=HEAD

There is also a nice Makefile to create a working systemd file ;-)

http://git.haproxy.org/?p=haproxy-1.8.git;a=tree;f=contrib/systemd;hb=HEAD

Regards
Aleks

> OK -> with -d
> -
> 
> Apr 09 20:43:32 haproxy.doom.be haproxy[3935]: epoll : pref=300,  test
> result OK
> 
> Apr 09 20:43:32 haproxy.doom.be haproxy[3935]: poll : pref=200,  test
> result OK
> 
> Apr 09 20:43:32 haproxy.doom.be haproxy[3935]: select : pref=150,  test
> result FAILED
> 
> Apr 09 20:43:32 haproxy.doom.be haproxy[3935]: Total: 3 (2 usable), will
> use epoll.
> 
> Apr 09 20:43:32 haproxy.doom.be haproxy[3935]: Available filters :
> 
> Apr 09 20:43:32 haproxy.doom.be haproxy[3935]: [SPOE] spoe
> 
> Apr 09 20:43:32 haproxy.doom.be haproxy[3935]: [COMP] compression
> 
> Apr 09 20:43:32 haproxy.doom.be haproxy[3935]: [TRACE] trace
> 
> Apr 09 20:43:32 haproxy.doom.be haproxy[3935]: Proxy http_back started.
> 
> Apr 09 20:43:32 haproxy.doom.be haproxy[3935]: Proxy http_back started.
> 
> I can see the stats and the requests are forwarded to the first
> server...(second is not yet configured)
> 
> 
> NOK -> without -d
> 
> --
> 
> Apr 09 20:46:38 haproxy.doom.be systemd[1]: Stopping HAProxy Load
> Balancer...
> 
> Apr 09 20:46:38 haproxy.doom.be systemd[1]: Started HAProxy Load Balancer.
> 
> Apr 09 20:46:38 haproxy.doom.be systemd[1]: Starting HAProxy Load
> Balancer...
> 
> 
> 
> global
>    log /dev/log local0
>    log /dev/log local1 notice
>    chroot /var/lib/haproxy
>    stats timeout 30s
>    user haproxy
>    #group haproxy
>    daemon
> 
> defaults
>    log global
>    mode http
>    option httplog
>    option dontlognull
>    timeout connect 5000
>    timeout client 5
>    timeout server 5
> 
> frontend http_front
>    bind *:80
>    stats uri /haproxy?stats
>    default_backend http_back
> 
> backend http_back
>    balance roundrobin
>    server BERT 10.10.8.30:80 check
>    server ERNIE 10.10.8.31:80 check
> "/etc/haproxy/haproxy.cfg" 27L, 504C
> 
> 
> Thanks
> Geert

Only start on CentOS7 in debug...

[Geert Van Muylem]

Hi,


I've downloaded and compiled haproxy version 1.8.7 on CentOS7

(make TARGET=linux2628 USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1)


The proxy only starts as it should be if I add the "-d"


My haproxy.service


[Unit]

Description=HAProxy Load Balancer

After=syslog.target network.target


[Service]

EnvironmentFile=/etc/sysconfig/haproxy

ExecStart=/usr/sbin/haproxy -d -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid 
$OPTIONS

ExecReload=/bin/kill -USR2 $MAINPID

KillMode=mixed


[Install]

WantedBy=multi-user.target


"/usr/lib/systemd/system/haproxy.service" 12L, 303C

OK -> with -d
-

Apr 09 20:43:32 haproxy.doom.be haproxy[3935]: epoll : pref=300,  test result OK

Apr 09 20:43:32 haproxy.doom.be haproxy[3935]: poll : pref=200,  test result OK

Apr 09 20:43:32 haproxy.doom.be haproxy[3935]: select : pref=150,  test result 
FAILED

Apr 09 20:43:32 haproxy.doom.be haproxy[3935]: Total: 3 (2 usable), will use 
epoll.

Apr 09 20:43:32 haproxy.doom.be haproxy[3935]: Available filters :

Apr 09 20:43:32 haproxy.doom.be haproxy[3935]: [SPOE] spoe

Apr 09 20:43:32 haproxy.doom.be haproxy[3935]: [COMP] compression

Apr 09 20:43:32 haproxy.doom.be haproxy[3935]: [TRACE] trace

Apr 09 20:43:32 haproxy.doom.be haproxy[3935]: Proxy http_back started.

Apr 09 20:43:32 haproxy.doom.be haproxy[3935]: Proxy http_back started.

I can see the stats and the requests are forwarded to the first 
server...(second is not yet configured)


NOK -> without -d

--

Apr 09 20:46:38 haproxy.doom.be systemd[1]: Stopping HAProxy Load Balancer...

Apr 09 20:46:38 haproxy.doom.be systemd[1]: Started HAProxy Load Balancer.

Apr 09 20:46:38 haproxy.doom.be systemd[1]: Starting HAProxy Load Balancer...


global
   log /dev/log local0
   log /dev/log local1 notice
   chroot /var/lib/haproxy
   stats timeout 30s
   user haproxy
   #group haproxy
   daemon

defaults
   log global
   mode http
   option httplog
   option dontlognull
   timeout connect 5000
   timeout client 5
   timeout server 5

frontend http_front
   bind *:80
   stats uri /haproxy?stats
   default_backend http_back

backend http_back
   balance roundrobin
   server BERT 10.10.8.30:80 check
   server ERNIE 10.10.8.31:80 check
"/etc/haproxy/haproxy.cfg" 27L, 504C


Thanks
Geert

[PATCH] BUG/MEDIUM: threads: Fix the max/min calculation because of name clashes

[Christopher Faulet]

Hi,

This patch fixes a bug affecting HAProxy compiled with gcc < 4.7 (with 
threads). It must be merged in 1.8.


Thanks,
--
Christopher Faulet
>From 12456b597dbfe231ba5ea33457676ea59b505ed5 Mon Sep 17 00:00:00 2001
From: Christopher Faulet 
Date: Fri, 6 Apr 2018 15:33:30 +0200
Subject: [PATCH] BUG/MEDIUM: threads: Fix the max/min calculation because of
 name clashes
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

With gcc < 4.7, when HAProxy is built with threads, the macros
HA_ATOMOC_CAS/XCHG/STORE relies on the legacy ‘__sync’ builtins. These macros
are slightly complicated than the versions relying on the '_atomic'
builtins. Internally, some local variables are defined, prefixed with '__' to
avoid name clashes with the caller.

On the other hand, the macros HA_ATOMIC_UPDATE_MIN/MAX call HA_ATOMIC_CAS. Some
local variables are also definied in these macros, following the same naming
rule as below. The problem is that '__new' variable is used in
HA_ATOMIC_MIN/_MAX and in HA_ATOMIC_CAS. Obviously, the behaviour is undefined
because '__new' in HA_ATOMIC_CAS is left uninitialized. Unfortunatly gcc fails
to detect this error.

To fix the problem, all internal variables to macros are now suffixed with name
of the macros to avoid clashes (for instance, '__new_cas' in HA_ATOMIC_CAS).

This patch must be backported in 1.8.
---
 include/common/hathreads.h | 92 +++---
 1 file changed, 47 insertions(+), 45 deletions(-)

diff --git a/include/common/hathreads.h b/include/common/hathreads.h
index e8b754cf..b0e4b23e 100644
--- a/include/common/hathreads.h
+++ b/include/common/hathreads.h
@@ -41,26 +41,26 @@ extern THREAD_LOCAL unsigned long tid_bit; /* The bit corresponding to the threa
 #define HA_ATOMIC_OR(val, flags) ({*(val) |= (flags);})
 #define HA_ATOMIC_XCHG(val, new)	\
 	({\
-		typeof(*(val)) __old = *(val);\
+		typeof(*(val)) __old_xchg = *(val);			\
 		*(val) = new;		\
-		__old;			\
+		__old_xchg;		\
 	})
 #define HA_ATOMIC_STORE(val, new)({*(val) = new;})
 #define HA_ATOMIC_UPDATE_MAX(val, new)	\
 	({\
-		typeof(*(val)) __new = (new);\
+		typeof(*(val)) __new_max = (new);			\
 	\
-		if (*(val) < __new)	\
-			*(val) = __new;	\
+		if (*(val) < __new_max)	\
+			*(val) = __new_max;\
 		*(val);			\
 	})
 
 #define HA_ATOMIC_UPDATE_MIN(val, new)	\
 	({\
-		typeof(*(val)) __new = (new);\
+		typeof(*(val)) __new_min = (new);			\
 	\
-		if (*(val) > __new)	\
-			*(val) = __new;	\
+		if (*(val) > __new_min)	\
+			*(val) = __new_min;\
 		*(val);			\
 	})
 
@@ -124,38 +124,38 @@ extern THREAD_LOCAL unsigned long tid_bit; /* The bit corresponding to the threa
  * but only if it differs from the expected one. If it's the same it's a race
  * thus we try again to avoid confusing a possibly sensitive caller.
  */
-#define HA_ATOMIC_CAS(val, old, new)	   \
-	({   \
-		typeof((val)) __val = (val);   \
-		typeof((old)) __oldp = (old);   \
-		typeof(*(old)) __oldv;	   \
-		typeof((new)) __new = (new);   \
-		int __ret;		   \
-		do {			   \
-			__oldv = *__val;   \
-			__ret = __sync_bool_compare_and_swap(__val, *__oldp, __new); \
-		} while (!__ret && *__oldp == __oldv);			   \
-		if (!__ret)		   \
-			*__oldp = __oldv;   \
-		__ret;			   \
+#define HA_ATOMIC_CAS(val, old, new)	\
+	({\
+		typeof((val)) __val_cas = (val);			\
+		typeof((old)) __oldp_cas = (old);			\
+		typeof(*(old)) __oldv_cas;\
+		typeof((new)) __new_cas = (new);			\
+		int __ret_cas;		\
+		do {			\
+			__oldv_cas = *__val_cas;			\
+			__ret_cas = __sync_bool_compare_and_swap(__val_cas, *__oldp_cas, __new_cas); \
+		} while (!__ret_cas && *__oldp_cas == __oldv_cas);	\
+		if (!__ret_cas)		\
+			*__oldp_cas = __oldv_cas;			\
+		__ret_cas;		\
 	})
 
-#define HA_ATOMIC_XCHG(val, new)	   \
-	({   \
-		typeof((val)) __val = (val);   \
-		typeof(*(val)) __old;	   \
-		typeof((new)) __new = (new);   \
-		do { __old = *__val;	   \
-		} while (!__sync_bool_compare_and_swap(__val, __old, __new));  \
-		__old;			   \
+#define HA_ATOMIC_XCHG(val, new)	\
+	({\
+		typeof((val)) __val_xchg = (val);			\
+		typeof(*(val)) __old_xchg;\
+		typeof((new)) __new_xchg = (new);			\
+		do { __old_xchg = *__val_xchg;\
+		} while (!__sync_bool_compare_and_swap(__val_xchg, __old_xchg, __new_xchg)); \
+		__old_xchg;		\
 	})
-#define HA_ATOMIC_STORE(val, new)	 \
-	({   \
-		typeof((val)) __val = (val);   \
-		typeof(*(val)) __old;	   \
-		typeof((new)) __new = (new);   \
-		do { __old = *__val;	   \
-		} while (!__sync_bool_compare_and_swap(__val, __old, __new));  \
+#define HA_ATOMIC_STORE(val, new)	\
+	({			

Re: Haproxy 1.8.4 crashing workers and increased memory usage

[Robin Geuze]

Hey,

Won't that be a bit pointless since we don't use threads?

Regards,

Robin Geuze


On 4/9/2018 10:31, Илья Шипицин wrote:

can you try thread sanitizer (in real time)?

https://github.com/google/sanitizers/wiki#threadsanitizer


I'd like to try myself, however, we do not observe bad things in our 
environment


2018-04-09 13:24 GMT+05:00 Robin Geuze >:


Hey Willy,

So I made a build this morning with libslz and re-enabled
compression and within an hour we had the exit code 134 errors, so
zlib does not seem to be the problem here.

Regards,

Robin Geuze



On 4/7/2018 00:30, Willy Tarreau wrote:

Hi Robin,

On Fri, Apr 06, 2018 at 03:52:33PM +0200, Robin Geuze wrote:

Hey Willy,

I was actually the one that had the hunch to disable
compression. I
suspected that this was the issue because there was a
bunch of "abort" calls
in include/common/hathreads.h" which is used by the
compression stuff.
However I just noticed those aborts are actually only
there if DEBUG_THREAD
is defined which it doesn't seem to be for our build. So
basically, I have
no clue whatsoever why disabling compression fixes the bug.

At least I don't feel alone :-)

I can see next week if we can make a build with slz
instead of zlib (we seem
to be linked against zlib/libz atm).

Thank you, I appreciate it!

Cheers,
Willy

Re: Haproxy 1.8.4 crashing workers and increased memory usage

[Илья Шипицин]

can you try thread sanitizer (in real time)?

https://github.com/google/sanitizers/wiki#threadsanitizer


I'd like to try myself, however, we do not observe bad things in our
environment

2018-04-09 13:24 GMT+05:00 Robin Geuze :

> Hey Willy,
>
> So I made a build this morning with libslz and re-enabled compression and
> within an hour we had the exit code 134 errors, so zlib does not seem to be
> the problem here.
>
> Regards,
>
> Robin Geuze
>
>
>
> On 4/7/2018 00:30, Willy Tarreau wrote:
>
>> Hi Robin,
>>
>> On Fri, Apr 06, 2018 at 03:52:33PM +0200, Robin Geuze wrote:
>>
>>> Hey Willy,
>>>
>>> I was actually the one that had the hunch to disable compression. I
>>> suspected that this was the issue because there was a bunch of "abort"
>>> calls
>>> in include/common/hathreads.h" which is used by the compression stuff.
>>> However I just noticed those aborts are actually only there if
>>> DEBUG_THREAD
>>> is defined which it doesn't seem to be for our build. So basically, I
>>> have
>>> no clue whatsoever why disabling compression fixes the bug.
>>>
>> At least I don't feel alone :-)
>>
>> I can see next week if we can make a build with slz instead of zlib (we
>>> seem
>>> to be linked against zlib/libz atm).
>>>
>> Thank you, I appreciate it!
>>
>> Cheers,
>> Willy
>>
>
>
>

Re: Haproxy 1.8.4 crashing workers and increased memory usage

[Robin Geuze]

Hey Willy,

So I made a build this morning with libslz and re-enabled compression 
and within an hour we had the exit code 134 errors, so zlib does not 
seem to be the problem here.


Regards,

Robin Geuze


On 4/7/2018 00:30, Willy Tarreau wrote:

Hi Robin,

On Fri, Apr 06, 2018 at 03:52:33PM +0200, Robin Geuze wrote:

Hey Willy,

I was actually the one that had the hunch to disable compression. I
suspected that this was the issue because there was a bunch of "abort" calls
in include/common/hathreads.h" which is used by the compression stuff.
However I just noticed those aborts are actually only there if DEBUG_THREAD
is defined which it doesn't seem to be for our build. So basically, I have
no clue whatsoever why disabling compression fixes the bug.

At least I don't feel alone :-)


I can see next week if we can make a build with slz instead of zlib (we seem
to be linked against zlib/libz atm).

Thank you, I appreciate it!

Cheers,
Willy

Re: DNS resolver and mixed case responses

[Baptiste]

So, it seems that responses that does not match the case should be dropped:
https://twitter.com/PowerDNS_Bert/status/983254222694240257

Baptiste

Re: DNS resolver and mixed case responses

[Baptiste]

On Fri, Apr 6, 2018 at 11:10 AM, Dennis Jacobfeuerborn <
denni...@conversis.de> wrote:

> On 04.04.2018 16:30, Tim Düsterhus wrote:
> > Dale,
> >
> > Am 03.04.2018 um 16:17 schrieb Dale Smith:
> >> I'm trying to understand what system is at fault here; the DNS server
> for
> >> not responding with the same case as the query, or HAProxy which
> >> should be
> >> performing a case insensitive match.
> >
> > This is left unspecified in the standards, but on the other hand there
> > is this Internet Draft:
> > https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00 which wants to
> > mandate case preserval to make DNS spoofing harder by introducing more
> > entropy in the DNS request.
> >
> > I recommend to fix your internal DNS server, because case preserving
> > behaviour seems to be somewhat expected according to a quick Google
> search.
>
> There is this:
>
> Domain Name System (DNS) Case Insensitivity Clarification:
> https://tools.ietf.org/html/rfc4343#section-3.1
>
> In section 3 it says this:
>
> 3.  Name Lookup, Label Types, and CLASS
>
>According to the original DNS design decision, comparisons on name
>lookup for DNS queries should be case insensitive [STD13].  That is
>to say, a lookup string octet with a value in the inclusive range
>from 0x41 to 0x5A, the uppercase ASCII letters, MUST match the
>identical value and also match the corresponding value in the
>inclusive range from 0x61 to 0x7A, the lowercase ASCII letters.  A
>lookup string octet with a lowercase ASCII letter value MUST
>similarly match the identical value and also match the corresponding
>value in the uppercase ASCII letter range.
>
>(Historical note: The terms "uppercase" and "lowercase" were invented
>after movable type.  The terms originally referred to the two font
>trays for storing, in partitioned areas, the different physical type
>elements.  Before movable type, the nearest equivalent terms were
>"majuscule" and "minuscule".)
>
> This reads to me like HAProxy should match characters in the ranges 0x41
> to 0x5A and 0x61 to 0x7A insensitively as long as the label type is ASCII.
>
> Section 4.1 "DNS Output Case Preservation" mentions this: "No "case
> conversion" or "case folding" is done during such output operations,
> thus "preserving" case."
>
> Regrads,
>   Dennis
>
>
Hi All,

Let me ask some advices to our friends of PowerDNS :)

Baptiste

Re: resolvers - resolv.conf fallback

[Baptiste]

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 elements. Same for those manipulating/building
> > > configs by assembling elements and iteratively pass them through
> > > "haproxy -c". That's exactly the reason why we relaxed a few checks in
> > > the past, like accepting a frontend with no bind line or accepting a
> > > backend with a "cookie" directive with no cookie on server lines. In
> > > fact we could simply emit a warning when a resolvers section has no
> > > resolver nor resolv.conf enabled, but at least accept to start.
> >
> > Understood; however in this specific case I would argue one would
> > remove the "resolver" directive from the server-line(s), instead of
> > dropping the nameservers from the global nameserver declaration.
>
> No, because in order to do this, you also have to remove all references
> on all "server" lines, which is quite a pain, and error-prone when you
> want to reactivate them.
>
> > Maybe a config warning would be a compromise for this case?
>
> Yes, that's what I mentionned above, I'm all in favor of this given that
> we can't objectively find a valid use case for an empty resolvers section
> in production.
>
> Cheers,
> Willy
>


Ok, so just to summarize:
- we should enable parsing of resolv.conf with a configuration statement in
the resolvers section
- only nameserver directives from resolv.conf will be parsed for now
- parsing of resolv.conf can be used in conjunction with nameserver
directives in the resolvers section
- HAProxy should emit a warning message when parsing a configuration which
has no resolv.conf neither nameserver directives enabled

Is that correct?

Baptiste