Sorry about the mixing of topics. I will repost the SSL question when I am done investigating the DNS topic which currently is the deal breaker :)
I did some DNS packet sniffing and it seems the problem is that haproxy does a type=ANY request to DNS for the domain names, and weave-DNS then replies with "No such name"... if I check with nslookup, then I get the same behaviour for type=ANY requests. The DNS will only answer with the IP for type=A requests. Is there any way to tune this kind of behaviour in the resolvers section of HAProxy now? Best regards Øyvind Johnsen System Admin +47 99242547 +852 67157472 On Thu, Oct 15, 2015 at 10:58 AM, Baptiste <bed...@gmail.com> wrote: > On Thu, Oct 15, 2015 at 10:24 AM, Øyvind Johnsen <john...@gerilja.no> > wrote: > > Hi all, > > > > We are running HAProxy on our Docker / Swarm / Weave cluster also > featuring Weave-DNS for service discovery between the containers in the > cluster. We are deploying fairly often to the cluster for both dev and > stage environments and was very happy to see the DNS Resolvers feature > introduced with HAProxy 1.6. Problem is that I cannot seem to get this > feature to work with our setup. HAProxy does never pick up a DNS change as > it is supposed to, so when a container is redeployed the backend will go > down whenever the container gets assigned a new IP from Weave. > > > > Weave-DNS is available on every node in the cluster on IP 172.17.42.1 > and I can resolve all the internal DNS names using the resolver at this > address to the correct IP from inside the container running HAProxy. The > DNS changes immediately when a container is redeployed and gets assigned a > new IP. > > > > A simplified and anonymised version of our HAProxy config: > > > > defaults > > log global > > option httplog > > option dontlognull > > option log-health-checks > > option httpchk > > mode http > > option http-server-close > > timeout connect 7s > > timeout client 10s > > timeout server 10s > > timeout check 5s > > > > resolvers weave-dns > > nameserver dns1 172.17.42.1:53 > > timeout retry 1s > > hold valid 10s > > > > frontend http-in > > bind *:80 > > acl acl_domain1 hdr(host) -i domain1.io > > use_backend backend_domain1 if acl_domain1 > > > > acl acl_domain2 hdr(host) -i domain2.io > > use_backend backend_domain2 if acl_domain2 > > > > frontend https-in > > bind *:443 ssl crt /data/ssl-certs/ > > reqadd X-Forwarded-Proto:\ https > > > > acl acl_domain1 hdr(host) -i domain1.io > > use_backend backend_domain1 if acl_domain1 > > > > acl acl_domain2 hdr(host) -i domain2.io > > use_backend backend_domain2 if acl_domain2 > > > > backend backend_domain1 > > server domain1-server domain1.weave.local:80 check inter 1000 > resolvers weave-dns resolve-prefer ipv4 > > > > backend backend_domain2 > > server domain2-server domain2.weave.local:80 check inter 1000 > resolvers weave-dns resolve-prefer ipv4 > > > > Is there any reason why the server check should not pick up the DNS > change and update HAProxy with the new IP so the backend continue to work > when we do a redeploy? > > > > > > I also encountered another issue when trying to upgrade to the final > 1.6.0 version. The server is using two wildcard certificates in the folder > specified in the config. When running the ssllabs.com SSL test on the > server at domain2 (the cert that is not the default one, but using SNI) > then HAProxy segfaults and dies completely. This behaviour is not observed > on neither of the 1.6.0-devX builds. > > > > Hi Oyvind, > > Please repost your SSL question in a new thread with an appropriate > subject. > Next time avoid mixing 2 very different topics in the same thread. > > Have you enabled stats socket in your global section? > If not, please enable it. > Then run a "show stat resolvers" and report here the output of the command. > > A packet capture of a few DNS packets would be much appreciated. > > Baptiste >