On Sat, 4 Aug 2018 at 14:21, Igor Cicimov <[email protected]> wrote: > > Hi, > > On Sat, Aug 4, 2018 at 1:50 AM, K3 <[email protected]> wrote: >> >> Hi, >> We are running into a problem and would like to hear any advice. >> >> Our Setup: >> We use haproxy 1.7.7 with two backends. >> One of the backends is AWS ELB >> The haproxy is running on a linux machine in our data center (on premises) >> >> Problem: >> The ELB is available on 3 AZ so the endpoint can resolve to 3 IPs at a given >> time. >> After startup, when one of the ELB's IP changes, our haproxy shows the ELB >> as down with L4TMOUT and never recovers the backend. >> >> From 1.7.7 doc, under section 5.3.1 we see the below >> "A few other events can trigger a name resolution at run time: >> >> - when a server's health check ends up in a connection timeout: this may be >> because the server has a new IP address. So we need to trigger a name >> resolution to know this new IP." >> >> Its not clear if the resolvers section is required for the above statement >> to be true. >> >> Unfortunately, we cannot define name server's IPs in our configuration since >> these IPs can change. >> >> On the system (/etc/resolv.conf), these are automatically updated by >> dhclient. >> >> Question: >> >> 1. Is there any way by which haproxy can use the latest DNS entries from the >> system config and use it during the runtime? > > I just saw this announced in 1.9-dev1 > > > - the "resolvers" section can now be fed directly from resolv.conf > using the "parse-resolv-conf" directive. The DNS code also supports > new options to enable/disable address deduplication within a farm.
This is on startup only though. Haproxy cannot continuously re-read resolv.conf, not even with this feature. If the DNS servers on your system keep changing unpredictably, there is no solution other than restarting haproxy, with the parse-resolv-conf configuration and the haproxy internal resolver. Lukas
