Hi all, Thanks for confirming it should work—based on the feedback, we realized the issue is actually not with `nameservers`, but on startup, so this is actually init-addr taking precedence. We missed that in the initial analysis.
Our init-addr is `init-addr libc,last,none`. Due to a complex set of factors, using libc to resolve a host can simply hang, instead of fail. When HAProxy starts up and libc hangs, the startup times out instead of failing with no IP (i.e. `none`). Is there a way to set the timeout for a libc address resolution? We may be able to drop `libc` in the init-addr list entirely due to a generally better setup now, but it's useful in some cases. Best, Luke — Luke Seelenbinder Stadia Maps | Founder & CEO stadiamaps.com > On Mar 8, 2025, at 03:32, Lukas Tribus <lu...@ltri.eu> wrote: > > On Fri, 7 Mar 2025 at 18:42, Aurelien DARRAGON <adarra...@haproxy.com> wrote: >> >> Looking at the code, and testing it for TCP servers it does seem to be >> supported. To confirm I tried to use a "bad" source address, and it >> fails as expected: >> >>> [ALERT] (104635) : Cannot bind to source address before connect() for >>> backend mybaddns. Aborting. > > In this case for me it does not actually abort and haproxy goes into a > busy loop over this bind(). > > > >> Using a correct address I see haproxy connecting using the proper >> address (at least on the initial attempt) > > Same here, it looks fine. > > > >>>> In practice, we've found it may use another IPv6 (e.g., one bound for >>>> failover), which results in resolution failures. > > Not trying to nitpick the setup here, just trying to get the full > picture, are you saying that IPv6 connectivity is broken for every > application that does specify a specific source address? > > Are you sure there is nothing else going on here and it is haproxy > that fails source address selection? I think this is going to require > strace 'ing the haproxy process during connection establishment of the > DNS TCP session and more setup details. > > > Lukas > > > > > Lukas > >