Hi List,
Hereby a little bump. Can someone take a look?
(maybe the pcap attachment didn't fly well through spam filters. (or the
email formatting..)?)
(or because i (wrongly?) chose to include Baptiste specifically in my
addressing (he committed the original patch that caused the change in
behaviour)..)
Anyhow the current '2.2-dev2-a71667c, released 2020/02/17' is still
affected.
If someone was already planning to, please don't feel 'pushed' by this
mail. i'm just trying to make sure this doesn't fall through the cracks :).
Regards,
PiBa-NL (Pieter)
Op 9-2-2020 om 15:35 schreef PiBa-NL:
Hi List, Baptiste,
After updating haproxy i found that the DNS resolver is no longer
working for me. Also i wonder about the exact effect that 'hold valid'
should have.
I pointed haproxy to a 'Unbound 1.9.4' dns server that does the
recursive resolving of the dns request made by haproxy.
Before commit '2.2-dev0-13a9232, released 2020/01/22 (use additional
records from SRV responses)' i get seemingly proper working resolving
of server a name.
After this commit all responses are counted as 'invalid' in the socket
stats.
Attached also a pcap of the dns traffic. Which shows a short capture
of a single attempt where 3 retries for both A and AAAA records show
up. There is a additional record of type 'OPT' is present in the
response.. But the exact same keeps repeating every 5 seconds.
As for 'hold valid' (tested with the commit before this one) it seems
that the stats page of haproxy shows the server in 'resolution' status
way before the 3 minute 'hold valid' has passed when i simply
disconnect the network of the server running the Unbound-DNS server.
Though i guess that is less important that dns working at all in the
first place..
If any additional information is needed please let me know :).
Can you/someone take a look? Thanks in advance.
p.s. i think i read something about a 'vtest' that can test the
haproxy DNS functionality, if you have a example that does this i
would be happy to provide a vtest with a reproduction of the issue
though i guess it will be kinda 'slow' if it needs to test for hold
valid timings..
Regards,
PiBa-NL (Pieter)
#### haproxy config:
resolvers globalresolvers
nameserver pfs_routerbox 192.168.0.18:53
resolve_retries 3
timeout retry 200
hold valid 3m
hold nx 10s
hold other 15s
hold refused 20s
hold timeout 25s
hold obsolete 30s
timeout resolve 5s
frontend nu_nl
bind 192.168.0.19:433 name 192.168.0.19:433 ssl
crt-list /var/etc/haproxy/nu_nl.crt_list
mode http
log global
option http-keep-alive
timeout client 30000
use_backend nu.nl_ipvANY
backend nu.nl_ipvANY
mode http
id 2113
log global
timeout connect 30000
timeout server 30000
retries 3
option httpchk GET / HTTP/1.0\r\nHost:\
nu.nl\r\nAccept:\ */*
server nu_nl nu.nl:443 id 2114 ssl check inter 10000
verify none resolvers globalresolvers check-sni nu.nl resolve-prefer ipv4
#### haproxy_socket.sh show resolvers
Resolvers section globalresolvers
nameserver pfs_routerbox:
sent: 216
snd_error: 0
valid: 0
update: 0
cname: 0
cname_error: 0
any_err: 108
nx: 0
timeout: 0
refused: 0
other: 0
invalid: 108
too_big: 0
truncated: 0
outdated: 0
#### haproxy -vv
HA-Proxy version 2.2-dev0-13a9232 2020/01/22 - https://haproxy.org/
Status: development branch - not safe for use in production.
Known bugs: https://github.com/haproxy/haproxy/issues?q=is:issue+is:open
Build options :
TARGET = freebsd
CPU = generic
CC = cc
CFLAGS = -pipe -g -fstack-protector -fno-strict-aliasing
-fno-strict-aliasing -Wdeclaration-after-statement -fwrapv
-fno-strict-overflow -Wno-null-dereference -Wno-unused-label
-Wno-unused-parameter -Wno-sign-compare -Wno-ignored-qualifiers
-Wno-unused-command-line-argument -Wno-missing-field-initializers
-Wno-address-of-packed-member -DFREEBSD_PORTS -DFREEBSD_PORTS
OPTIONS = USE_PCRE=1 USE_PCRE_JIT=1 USE_REGPARM=1 USE_STATIC_PCRE=1
USE_GETADDRINFO=1 USE_OPENSSL=1 USE_LUA=1 USE_ACCEPT4=1 USE_ZLIB=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=2).
Built with OpenSSL version : OpenSSL 1.1.1a-freebsd 20 Nov 2018
Running on OpenSSL version : OpenSSL 1.1.1a-freebsd 20 Nov 2018
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : SSLv3 TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3
Built with Lua version : Lua 5.3.5
Built with transparent proxy support using: IP_BINDANY IPV6_BINDANY
Built with PCRE version : 8.43 2019-02-23
Running on PCRE version : 8.43 2019-02-23
PCRE library supports JIT : yes
Encrypted password support via crypt(3): yes
Built with zlib version : 1.2.11
Running on zlib version : 1.2.11
Compression algorithms supported : identity("identity"),
deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Available polling systems :
kqueue : pref=300, test result OK
poll : pref=200, test result OK
select : pref=150, test result OK
Total: 3 (3 usable), will use kqueue.
Available multiplexer protocols :
(protocols marked as <default> cannot be specified using 'proto' keyword)
h2 : mode=HTTP side=FE|BE mux=H2
fcgi : mode=HTTP side=BE mux=FCGI
<default> : mode=HTTP side=FE|BE mux=H1
<default> : mode=TCP side=FE|BE mux=PASS
Available services : none
Available filters :
[SPOE] spoe
[CACHE] cache
[FCGI] fcgi-app
[TRACE] trace
[COMP] compression