Dynamic DNS resolution does not work for me after 1.6.4 to 1.6.5 upgrade


#1

Hello.

Dynamic DNS lookups stopped working for me after upgrading from 1.6.4 to 1.6.5 on up-to-date RHEL6 . There are no messages about server address change in syslog and when tcpdumping tcp/udp port 53, I do not see periodical DNS questions. Downgrading to 1.6.4 mages everything working again.

My servers using dynamic resolution are basically configured like this:

global log 127.0.0.1 local6 debug
chroot      /var/lib/haproxy
pidfile     /var/run/haproxy.pid
maxconn     4000
user        haproxy
group       haproxy
external-check
daemon

# turn on stats unix socket
stats socket /var/lib/haproxy/stats user zabbix

node node-02
log-send-hostname node-02.example.com

defaults
mode tcp
log global
option tcplog
option dontlognull
retries 3
option redispatch
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout check 10s
maxconn 3000

resolvers DNS_resolver_1
nameserver dns1 10.150.3.30:53
nameserver dns2 10.150.7.30:53
hold valid 60s
resolve_retries 3
timeout retry 5s

Web2.0 google push

listen web2_google-443
bind 10.50.71.65:443
source 10.50.71.65
mode tcp
server srv_65 gcm-http.googleapis.com check inter 300s resolvers DNS_resolver_1 resolve-prefer ipv4


Please should I consider this to be a bug in 1.6.5, or is some configuration change required to make things working withj 1.6.5?

Thanks in advance for your answers,

Ed


#2

Its a bug (regression in “BUG/MINOR: dns: fix DNS header definition”). Can you try the following patch: http://pastebin.com/raw/SHp05RNY


#3

Hello Lukas.

Thanks for your answer. It appears that your patch makes dynamic DNS resolution in 1.6.5 working again.

But one more question. 1.6.5 is declared as important and suggested update, but now we know that it also contains at least one bug that has significant impact when used with my configuration. So the question is: Which version should I use for production?

  • stay with 1.6.4
  • use 1.6.5 with your patch
  • use the latest 1.6 with post-1.6.5 commits from git

???

Thanks,

Ed


#4

If you are not impacted by the bugs in 1.6.4 I would suggest to stick with that for the moment.
If you need the 1.6.5 bugfixes, my suggestion would be to use 1.6.5 with my patch.

But more importantly I would say use the method you are most comfortable with.


#5

Thanks! So we will probably stay with 1.6.4, waiting for 1.6.6. And give a try to 1.6.5 with patch only if we will be hit by any bug with 1.6.4.

Thanks again,

Ed


#6

Think we’ve hit the same problem using latest Docker image. Are we expecting a 1.6.6 release soon or is downgrading to 1.6.4 advised for the next few weeks?


#7

I’m not aware of any plans to release 1.6.6 soon, @willy?

You can run a git clone of haproxy 1.6 or compile from a snapshot, you could also just apply the patch from above.


#8

This appears to be the case with 1.6.6 still:

root@dee7ed8a9b20:/# /usr/local/sbin/haproxy
HA-Proxy version 1.6.6 2016/06/26
Copyright 2000-2016 Willy Tarreau willy@haproxy.org

We have two back-end http servers. If I down one of them, then attempt to restart the haproxy instance it fails to start:

[ALERT] 182/105427 (8) : parsing [/usr/local/etc/haproxy/haproxy.cfg:72] : ‘server ngw-received-ee-01’ : invalid address: ‘rx-ee’ in ‘rx-ee:8080’
[ALERT] 182/105427 (8) : Error(s) found in configuration file : /usr/local/etc/haproxy/haproxy.cfg

Should I expect this to be working in 1.6.6?


#9

HAProxy resolvers expect a fqdn. Please retry with a fqdn.


#10

Hi, http://blog.haproxy.com/2015/10/14/whats-new-in-haproxy-1-6/ under “Server IP Resolution…” does not show a FQDN - we are in the same scenario using Docker with container-names across user-defined networks. I may be missing some precise detail not shown of course…