Re: global maxconn behaviour in haproxy2.0

[Igor Cicimov]

Hi,

On Wed, Jun 26, 2019 at 2:52 AM William Dauchy  wrote:

> Hello,
>
> Using haproxy2.0 we are seeing logs with connection number while reloading:
> Proxy  stopped (FE: 0 conns, BE: 549563 conns).
>
> while we have in our configuration:
> global maxconn 262144
> defaults maxconn 262134
>
> I was wondering whether this could considered as expected to have a
> backend with more connections compared to the global parameter.
>
> Best,
> --
> William
>
>
Those maxconn values are per frontend so if your backend is referenced by
two frontends you might end up with a limit of 2 x maxconn on the backend.
Hence it is recommended to set maxconn per server too to protect from
situation like this. So read about maxconn and even fullconn in the server
config and tuning guide for more details.

Re: Question about SNI

[Lukas Tribus]

Hello Rainer,


On Tue, 25 Jun 2019 at 19:08,  wrote:
> > So, are health checks working and does haproxy consider your backend
> > servers up or not?
>
>
>
> Oh, sorry.
>
> I tried a lot of things over the last days
>
> Currently, with the last config I posted (and keepalived disabled), I
> get L7TOUTs from the backend.

So it's a health check issue we are talking about now.

Haproxy is configured with a keep-alive disabled HTTP/1.1 GET request,
while your curl call is a HTTP/2 HEAD request.

I suggest your try a HEAD request for the haproxy health check instead:

option httpchk HEAD /swagger/ui/index HTTP/1.1\r\nHost:\
app-api.dom.intern\r\nUser-agent:\ LB-Check-API\r\nConnection:\ close

There is no need for the actual HTTP payload to be send to haproxy,
and I don't recall what happens when the response is bigger than
haproxy buffers.


Regards,
Lukas

Re: Question about SNI

[rainer]

Am 2019-06-25 18:26, schrieb Lukas Tribus:

Hell Rainer,

On Tue, 25 Jun 2019 at 18:01,  wrote:

Ah, OK.
Thanks.


However, I still get L7TOUT on the healthchecks.


I don't follow.

Are health checks working or not? You started this thread saying:


Healthchecks are OK.

But running a curl gives 503


So, are health checks working and does haproxy consider your backend
servers up or not?




Oh, sorry.

I tried a lot of things over the last days

Currently, with the last config I posted (and keepalived disabled), I 
get L7TOUTs from the backend.


However, the healthchecks do arrive on the actual servers and the 
servers answer with a code 200.
When the actual app is removed (and replaced by a static file), the 
healthchecks also work and the backend is OK for haproxy.

So, as I said, I wonder what else haproxy expects.




Best Regards
Rainer

global maxconn behaviour in haproxy2.0

[William Dauchy]

Hello,

Using haproxy2.0 we are seeing logs with connection number while reloading:
Proxy  stopped (FE: 0 conns, BE: 549563 conns).

while we have in our configuration:
global maxconn 262144
defaults maxconn 262134

I was wondering whether this could considered as expected to have a
backend with more connections compared to the global parameter.

Best,
-- 
William

Re: Question about SNI

[Lukas Tribus]

Hell Rainer,

On Tue, 25 Jun 2019 at 18:01,  wrote:
> Ah, OK.
> Thanks.
>
>
> However, I still get L7TOUT on the healthchecks.

I don't follow.

Are health checks working or not? You started this thread saying:

> Healthchecks are OK.
>
> But running a curl gives 503

So, are health checks working and does haproxy consider your backend
servers up or not?


lukas

Re: Question about SNI

[rainer]

Am 2019-06-25 16:54, schrieb Lukas Tribus:

Hello Rainer,


On Tue, 25 Jun 2019 at 16:18,  wrote:

The requests from the healthchecks *do* arrive at the right vhosts on
the backend, there's a code 200 in the logs.
So, I wonder what exactly is timing out for haproxy.
The server on the other end does not accept non-SNI connections, 
there's

an SSL handshake error if you don't do SNI.


At this point, I feel pretty dumb.


Health checks are fine.
Actual requests with your production traffic are not.

check-sni specifies the SNI value to use for health-checks ONLY.
sni specifies the SNI value for actual traffic ONLY.
You need both though.

So you servers look like this for example, notice that both check-sni
and sni is configured:

server server1 10.10.10.11:443 check check-ssl ssl verify none
force-tlsv12 maxconn 3000 cookie s1 check-sni host3.intern sni
str(host3.intern)
server server2 10.10.10.12:443 check check-ssl ssl verify none
force-tlsv12 maxconn 3000 cookie s2 check-sni host3.intern sni
str(host3.intern)

If you only configure check-sni, only health checks work, production
traffic will not.



Ah, OK.
Thanks.


However, I still get L7TOUT on the healthchecks.

This is the haproxy that came with Ubuntu 18.04.2, haproxy 1.8.8.
At this point, I wonder if the keepalive configuration on the host has 
any influence on this.

Though, it could also be an IIS-thing.
If my co-worker removes the application from the app-server, the 
healthcheck turns ok.


time curl -kv  -I --resolve "app-api.dom.intern:443:10.200.16.36"  -H 
"Host: app-api.dom.intern" -o /dev/null  
https://app-api.dom.intern:443/swagger/ui/index

* Added app-api.dom.intern:443:10.200.16.36 to DNS cache
* Hostname app-api.dom.intern was found in DNS cache
*   Trying 10.200.16.36...
* TCP_NODELAY set
  % Total% Received % Xferd  Average Speed   TimeTime Time  
Current
 Dload  Upload   Total   SpentLeft  
Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 
0* Connected to app-api.dom.intern (10.200.16.36) port 443 (#0)

* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [218 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [98 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [827 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [300 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [37 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=*.dom.intern
*  start date: Jun 19 11:49:25 2019 GMT
*  expire date: Jun 19 11:59:26 2039 GMT
*  issuer: CN=*.dom.intern
*  SSL certificate verify result: unable to get local issuer certificate 
(20), continuing anyway.

* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after 
upgrade: len=0

} [5 bytes data]
* Using Stream ID: 1 (easy handle 0x55ed4bbd0900)
} [5 bytes data]

HEAD /swagger/ui/index HTTP/2
Host: app-api.dom.intern
User-Agent: curl/7.58.0
Accept: */*


{ [5 bytes data]
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
} [5 bytes data]
< HTTP/2 200
< cache-control: no-cache
< pragma: no-cache
< content-type: text/html
< expires: -1
< server: Microsoft-IIS/10.0
< x-aspnet-version: 4.0.30319
< x-content-type-options: nosniff
< x-xss-protection: 1; mode=block
< x-frame-options: SAMEORIGIN
< access-control-allow-origin: https://app-bo.dom.intern
< access-control-allow-headers: Origin, X-Requested-With, Content-Type, 
Authorization, X-Token-Jwt

< access-control-allow-credentials: true
< access-control-allow-methods: *
< date: Tue, 25 Jun 2019 15:52:40 GMT
<
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 
0

* Connection #0 to host app-api.dom.intern left intact

real0m0.034s
user0m0.011s
sys 0m0.008s



backend app_api
  mode http
  server ISOPROD036 10.200.16.36:443 check check-ssl ssl verify none 
force-tlsv12 maxconn 3000 cookie s1 check-sni app-api.dom.intern sni 
str(app-api.dom.intern)
  server ISOPROD037 10.200.16.37:443 check check-ssl ssl verify none 
force-tlsv12 maxconn 3000 cookie s2 check-sni app-api.dom.intern sni 
str(app-api.dom.intern)

  option httpclose
  option forwardfor
  option httpchk GET /swagger/ui/index HTTP/1.1\r\nHost:\ 
app-api.dom.intern\r\nUser-agent:\ LB-Check-API\r\nConnection:\ close

  http-check expect string Hello
  http-check 

Re: Question about SNI

[Lukas Tribus]

Hello Rainer,


On Tue, 25 Jun 2019 at 16:18,  wrote:
> The requests from the healthchecks *do* arrive at the right vhosts on
> the backend, there's a code 200 in the logs.
> So, I wonder what exactly is timing out for haproxy.
> The server on the other end does not accept non-SNI connections, there's
> an SSL handshake error if you don't do SNI.
>
>
> At this point, I feel pretty dumb.

Health checks are fine.
Actual requests with your production traffic are not.

check-sni specifies the SNI value to use for health-checks ONLY.
sni specifies the SNI value for actual traffic ONLY.
You need both though.

So you servers look like this for example, notice that both check-sni
and sni is configured:

server server1 10.10.10.11:443 check check-ssl ssl verify none
force-tlsv12 maxconn 3000 cookie s1 check-sni host3.intern sni
str(host3.intern)
server server2 10.10.10.12:443 check check-ssl ssl verify none
force-tlsv12 maxconn 3000 cookie s2 check-sni host3.intern sni
str(host3.intern)

If you only configure check-sni, only health checks work, production
traffic will not.


regards,
lukas

Re: Question about SNI

[rainer]

Am 2019-06-25 14:44, schrieb Lukas Tribus:

Hello Rainer,

On Tue, 25 Jun 2019 at 12:53,  wrote:

Hi,

I tried to read up on this but there are many examples and not all of
them seem "correct".


It's simple: do not content-switch based on SNI. Use the host header
instead. That's it.




OK,

I switched that out.
But it's really only a 2ndary-problem at the moment, because I still get 
L7 timeouts on the backends.


The example I provided for the backend is actually not what I wanted to 
write.


I was under the assumption that all that was needed to enable sni for 
healthchecks on a (http) backend was to say "check-sni" 
servername.bla.server


http://cbonte.github.io/haproxy-dconv/1.8/configuration.html#check-sni

backend app_api
  mode http
  server PROD036 10.200.16.36:443 check check-ssl ssl verify none 
force-tlsv12 maxconn 3000 cookie s1 check-sni api.app.intern
  server PROD037 10.200.16.37:443 check check-ssl ssl verify none 
force-tlsv12 maxconn 3000 cookie s2 check-sni api.app.intern

  option httpclose
  option forwardfor
  option httpchk GET / HTTP/1.1\r\nHost:\ api.app.intern\r\nUser-agent:\ 
LB-Check-API\r\nConnection:\ close

  http-check expect string Hello
  http-check disable-on-404
  cookie SERVERID insert indirect nocache httponly
  balance leastconn
  #stick-table type string len 52 size 100k expire 60m

The requests from the healthchecks *do* arrive at the right vhosts on 
the backend, there's a code 200 in the logs.

So, I wonder what exactly is timing out for haproxy.
The server on the other end does not accept non-SNI connections, there's 
an SSL handshake error if you don't do SNI.



At this point, I feel pretty dumb.

I really appreciate your help.



Best Regards
Rainer

Re: haproxy 2.0: SIGSEGV in ssl_subscribe

[Максим Куприянов]

Hi Olivier,

Thank you for the patches, I've built a new binary and now it works fine.

вт, 25 июн. 2019 г. в 15:23, Olivier Houchard :

> Hi Maksim,
>
> On Tue, Jun 25, 2019 at 01:29:24PM +0300, Максим Куприянов wrote:
> > Hi!
> >
> > Got SIGSEGV in ssl_subscribe function. Happens multiple times per day.
> > Haproxy was built from trunk with commits upto:
> >
> http://git.haproxy.org/?p=haproxy-2.0.git;a=commit;h=9eae8935663bc0b27c23018e8cc24ae9a3e31732
> >
>
> It is believed to be fixed in master, and should be backported to 2.0 soon.
> If you feel like it, you can apply commit
> 0ff28651c184f2b6cc7782b0960ed69cc907ca97, and let me know if you still have
> issues or not.
> You may want c31e2cbd28d53210b7184091bb64137c806d7957 too.
>
> Regards,
>
> Olivier
>

Match response status code with regular expression

[Ricardo Fraile]

Hello,


I'm trying to set an acl for multiple status codes. As example, using
only for one works:

  http-response set-header Cache-Control max-age=60 if { status 302 }

but with more than one, trying with a regex, fails because it is not
implemented in httpr-response:

  http-response set-header Cache-Control max-age=60 if { rstatus 3* }

produces the following error:

  error detected while parsing an 'http-response set-header' condition :
unknown fetch method 'rstatus' in ACL expression 'rstatus'.



The "rstatus" is available only under "http-check expect". Are there any
equivalence to the regext status matching?


Thanks,

Re: Question about SNI

[Lukas Tribus]

Hello Rainer,

On Tue, 25 Jun 2019 at 12:53,  wrote:
> Hi,
>
> I tried to read up on this but there are many examples and not all of
> them seem "correct".

It's simple: do not content-switch based on SNI. Use the host header
instead. That's it.


>use_backend app_api   if { ssl_fc_sni_reg -i
> app-api.theapp.intern }
>use_backend app_admin_servicesif { ssl_fc_sni_reg -i
> app-admin-services.theapp.intern }
>use_backend app_dms_services  if { ssl_fc_sni_reg -i
> app-dms-services.theapp.intern }
>use_backend app_external_services if { ssl_fc_sni_reg -i
> app-external-services.theapp.intern }
>use_backend app_boif { ssl_fc_sni_reg -i
> app-bo.theapp.intern }
>use_backend app_scheduler if { ssl_fc_sni_reg -i
> app-scheduler.theapp.intern }
>#use_backend app_api   if { sni hdr(host) -i
> app-api.theapp.intern }
>#use_backend app_admin_servicesif { sni hdr(host) -i
> app-admin-services.theapp.intern }
>#use_backend app_dms_services  if { sni hdr(host) -i
> app-dms-services.theapp.intern }
>#use_backend app_external_services if { sni hdr(host) -i
> app-external-services.theapp.intern }
>#use_backend app_boif { sni hdr(host) -i
> app-bo.theapp.intern }
>#use_backend app_scheduler if { snd hdr(host) -i
> app-scheduler.theapp.intern }

Use the host header and not SNI:

if { hdr(host) -i app-scheduler.theapp.intern }


> backend app_api
>mode http
>server PROD036 10.200.16.36:443 check check-ssl ssl verify none
> force-tlsv12 maxconn 3000 cookie s1 sni hdr(app-api.theapp.intern)
> check-sni app-api.theapp.intern
>server PROD037 10.200.16.37:443 check check-ssl ssl verify none
> force-tlsv12 maxconn 3000 cookie s2 sni hdr(app-api.theapp.intern)
> check-sni app-api.theapp.intern
>option httpclose
>option forwardfor
>option httpchk GET / HTTP/1.1\r\nHost:\
> app-api.theapp.intern\r\nConnection:\ close
>http-check expect string Hello
>http-check disable-on-404
>cookie SERVERID insert indirect nocache httponly
>balance leastconn
>
>
> This gets me a L7 timeout on the backend-servers.

Yes, because you are trying to fill the SNI value with the *HTTP
header* app-api.theapp.intern, which of course, does not exist.

Like I said, either use a static string with the str keyword:
str(app-api.theapp.intern)

or fill it based on what you see in the host header:
hdr(host)

Notice that the 3 letter prefix is not the same. If you want to
specify a string, use str. If you want to refer to a HTTP header, use
hdr.


> curl-ing the URLs works without problems.
> Because it's all encrypted, I have a hard time figuring out what haproxy
> is actually sending to the backend.
>
> Is there a way to enable some sort of logging on what requests are
> actually made to the backend?

If you don't trust the configuration, just look at the client hello
from a traffic capture. SNI is not encrypted.


Regards,
Lukas

Re: haproxy 2.0: SIGSEGV in ssl_subscribe

[Olivier Houchard]

Hi Maksim,

On Tue, Jun 25, 2019 at 01:29:24PM +0300, Максим Куприянов wrote:
> Hi!
> 
> Got SIGSEGV in ssl_subscribe function. Happens multiple times per day.
> Haproxy was built from trunk with commits upto:
> http://git.haproxy.org/?p=haproxy-2.0.git;a=commit;h=9eae8935663bc0b27c23018e8cc24ae9a3e31732
> 

It is believed to be fixed in master, and should be backported to 2.0 soon.
If you feel like it, you can apply commit
0ff28651c184f2b6cc7782b0960ed69cc907ca97, and let me know if you still have
issues or not.
You may want c31e2cbd28d53210b7184091bb64137c806d7957 too.

Regards,

Olivier

Re: Question about SNI

[rainer]

Am 2019-06-20 15:38, schrieb Lukas Tribus:

Hello,


On Thu, 20 Jun 2019 at 14:49,  wrote:

I now used

ssl_fc_sni_reg -i host3.intern

I hope, this is also OK.


It's not.

You are already doing the right thing in the frontend, by content
switching based on the host header and not based on the SNI, so
please, don't rely on frontend SNI in your backend.

Search the mailing list archives if you want to know why that's a bad 
idea.


Lukas




Hi,

I tried to read up on this but there are many examples and not all of 
them seem "correct".


I've got the following config now:


frontend app_frontend
  mode http
  bind *:80
  bind 10.200.16.10:443 ssl crt /etc/haproxy/ssl/star.theapp.intern.pem
  maxconn 2000
  use_backend app_api   if { ssl_fc_sni_reg -i 
app-api.theapp.intern }
  use_backend app_admin_servicesif { ssl_fc_sni_reg -i 
app-admin-services.theapp.intern }
  use_backend app_dms_services  if { ssl_fc_sni_reg -i 
app-dms-services.theapp.intern }
  use_backend app_external_services if { ssl_fc_sni_reg -i 
app-external-services.theapp.intern }
  use_backend app_boif { ssl_fc_sni_reg -i 
app-bo.theapp.intern }
  use_backend app_scheduler if { ssl_fc_sni_reg -i 
app-scheduler.theapp.intern }
  #use_backend app_api   if { sni hdr(host) -i 
app-api.theapp.intern }
  #use_backend app_admin_servicesif { sni hdr(host) -i 
app-admin-services.theapp.intern }
  #use_backend app_dms_services  if { sni hdr(host) -i 
app-dms-services.theapp.intern }
  #use_backend app_external_services if { sni hdr(host) -i 
app-external-services.theapp.intern }
  #use_backend app_boif { sni hdr(host) -i 
app-bo.theapp.intern }
  #use_backend app_scheduler if { snd hdr(host) -i 
app-scheduler.theapp.intern }

  capture request header User-Agent len 500
  redirect scheme https code 301 if !{ ssl_fc }
  http-request set-header X-Forwarded-Proto https if { ssl_fc }
  http-request set-header X-Forwarded-Ssl on if { ssl_fc }



backend app_api
  mode http
  server PROD036 10.200.16.36:443 check check-ssl ssl verify none 
force-tlsv12 maxconn 3000 cookie s1 sni hdr(app-api.theapp.intern) 
check-sni app-api.theapp.intern
  server PROD037 10.200.16.37:443 check check-ssl ssl verify none 
force-tlsv12 maxconn 3000 cookie s2 sni hdr(app-api.theapp.intern) 
check-sni app-api.theapp.intern

  option httpclose
  option forwardfor
  option httpchk GET / HTTP/1.1\r\nHost:\ 
app-api.theapp.intern\r\nConnection:\ close

  http-check expect string Hello
  http-check disable-on-404
  cookie SERVERID insert indirect nocache httponly
  balance leastconn


This gets me a L7 timeout on the backend-servers.


curl-ing the URLs works without problems.
Because it's all encrypted, I have a hard time figuring out what haproxy 
is actually sending to the backend.


Is there a way to enable some sort of logging on what requests are 
actually made to the backend?





Best Regards
Rainer

haproxy 2.0: SIGSEGV in ssl_subscribe

[Максим Куприянов]

Hi!

Got SIGSEGV in ssl_subscribe function. Happens multiple times per day.
Haproxy was built from trunk with commits upto:
http://git.haproxy.org/?p=haproxy-2.0.git;a=commit;h=9eae8935663bc0b27c23018e8cc24ae9a3e31732

Program terminated with signal SIGSEGV, Segmentation fault.
#0  ssl_subscribe (conn=0x7f51341091f0, xprt_ctx=0x0, event_type=2,
param=0x7f513406c288) at src/ssl_sock.c:5570
5570 ctx->send_wait = sw;
[Current thread is 1 (Thread 0x7f5140b4a700 (LWP 944418))]
(gdb) thread apply all bt

Thread 4 (Thread 0x7f5144567180 (LWP 944416)):
#0  0x7f5142d42a13 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x562e800eeb68 in _do_poll (p=, exp=-1911724555,
wake=0) at src/ev_epoll.c:156
#2  0x562e8018ed59 in run_poll_loop () at src/haproxy.c:2550
#3  run_thread_poll_loop (data=) at src/haproxy.c:2634
#4  0x562e800ec8b7 in main (argc=, argv=0x7ffd9122f288)
at src/haproxy.c:3308

Thread 3 (Thread 0x7f513bfff700 (LWP 944419)):
#0  0x7f5142d42a13 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x562e800eeb68 in _do_poll (p=, exp=-1911724555,
wake=0) at src/ev_epoll.c:156
#2  0x562e8018ed59 in run_poll_loop () at src/haproxy.c:2550
#3  run_thread_poll_loop (data=) at src/haproxy.c:2634
#4  0x7f5143d726ba in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#5  0x7f5142d4241d in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 2 (Thread 0x7f514134b700 (LWP 944417)):
#0  0x7f5142d42a13 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x562e800eeb68 in _do_poll (p=, exp=-1911724555,
wake=0) at src/ev_epoll.c:156
#2  0x562e8018ed59 in run_poll_loop () at src/haproxy.c:2550
#3  run_thread_poll_loop (data=) at src/haproxy.c:2634
#4  0x7f5143d726ba in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#5  0x7f5142d4241d in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 1 (Thread 0x7f5140b4a700 (LWP 944418)):
#0  ssl_subscribe (conn=0x7f51341091f0, xprt_ctx=0x0, event_type=2,
param=0x7f513406c288) at src/ssl_sock.c:5570
#1  0x562e801b58c9 in h1_send (h1c=h1c@entry=0x7f513406c210) at
src/mux_h1.c:1932
#2  0x562e801b93a6 in h1_io_cb (t=, ctx=0x7f513406c210,
status=) at src/mux_h1.c:2008
#3  0x562e80224f55 in process_runnable_tasks () at src/task.c:414
#4  0x562e8018ed88 in run_poll_loop () at src/haproxy.c:2513
#5  run_thread_poll_loop (data=) at src/haproxy.c:2634
#6  0x7f5143d726ba in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#7  0x7f5142d4241d in clone () from /lib/x86_64-linux-gnu/libc.so.6

HA-Proxy version 2.0.0-2 2019/06/24 - https://haproxy.org/
Build options :
  TARGET  = linux-glibc
  CPU = generic
  CC  = gcc
  CFLAGS  = -O2 -g -O2 -fPIE -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2
-fno-strict-aliasing -Wdeclaration-after-statement -fwrapv
-Wno-unused-label -Wno-sign-compare -Wno-unused-parameter
-Wno-old-style-declaration -Wno-ignored-qualifiers -Wno-clobbered
-Wno-missing-field-initializers -Wtype-limits
  OPTIONS = USE_PCRE2=1 USE_PCRE2_JIT=1 USE_REGPARM=1 USE_GETADDRINFO=1
USE_OPENSSL=1 USE_LUA=1 USE_ZLIB=1 USE_TFO=1 USE_SYSTEMD=1

Feature list : +EPOLL -KQUEUE -MY_EPOLL -MY_SPLICE +NETFILTER -PCRE
-PCRE_JIT +PCRE2 +PCRE2_JIT +POLL -PRIVATE_CACHE +THREAD -PTHREAD_PSHARED
+REGPARM -STATIC_PCRE -STATIC_PCRE2 +TPROXY +LINUX_TPROXY +LINUX_SPLICE
+LIBCRYPT +CRYPT_H -VSYSCALL +GETADDRINFO +OPENSSL +LUA +FUTEX +ACCEPT4
-MY_ACCEPT4 +ZLIB -SLZ +CPU_AFFINITY +TFO +NS +DL +RT -DEVICEATLAS
-51DEGREES -WURFL +SYSTEMD -OBSOLETE_LINKER +PRCTL +THREAD_DUMP -EVPORTS

Default settings :
  bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Built with multi-threading support (MAX_THREADS=64, default=32).
Built with OpenSSL version : OpenSSL 1.0.2g  1 Mar 2016
Running on OpenSSL version : OpenSSL 1.0.2g  1 Mar 2016
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2
Built with Lua version : Lua 5.3.1
Built with network namespace support.
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT
IP_FREEBIND
Built with zlib version : 1.2.8
Running on zlib version : 1.2.8
Compression algorithms supported : identity("identity"),
deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with PCRE2 version : 10.21 2016-01-12
PCRE2 library supports JIT : yes
Encrypted password support via crypt(3): yes
Built with the Prometheus exporter as a service

Available polling systems :
  epoll : pref=300,  test result OK
   poll : pref=200,  test result OK
 select : pref=150,  test result OK
Total: 3 (3 usable), will use epoll.

Available multiplexer protocols :
(protocols marked as  cannot be specified using 'proto' keyword)
  h2 : mode=HTXside=FE|BE mux=H2
  h2 : mode=HTTP   side=FEmux=H2
: mode=HTXside=FE|BE mux=H1
: mode=TCP|HTTP   

Re: http-request do-resolve for rDNS queries

[Luke Seelenbinder]

Hi Baptiste,

Thanks for the information.

Do you might pointing me towards the documentation for a slow agent? I'm having 
difficulty finding what you're referring to in the docs. Thanks!

Best,
Luke

—
Luke Seelenbinder
SermonAudio.com  | Senior Software Engineer






> On Jun 23, 2019, at 14:26, Baptiste  wrote:
> 
> Hi Luke,
> 
> It is not yet doable with do-resolve.
> That said you can easily write an slow agent to do this.
> I can help if you need to.
> 
> Baptiste
> 
> Le ven. 21 juin 2019 à 15:25, Luke Seelenbinder  > a écrit :
> Hello all,
> 
> Is it possible to use the new `http-request do-resolve` to do reverse DNS 
> lookups? It's left unspecified in the documentation, and I think it'd be 
> helpful to clarify for posterity.
> 
> I'd like to integrate this as part of a IP blocking methodology, but that 
> would depend on rDNS being supported.
> 
> Thanks!
> 
> Luke
> 
> —
> Luke Seelenbinder
> SermonAudio.com  | Senior Software Engineer
> 
> 
> 
> 
>