Hi Lukas! On Wed, May 07, 2025 at 05:26:49PM +0200, Lukas Tribus wrote: > > I'm still a bit torn between two use cases: > > - the very basic ones the DNS code was initially made for, where VMs > > are announced over DNS, are relatively stable, do not rely on complex > > stuff, and change IP when rebooted. Having the initial resolution done > > by libc at boot is desirable to avoid a blackout, and having DNS at > > runtime is desirable as well to recover the VM after a reboot ; > > Right, I did not think about that. I wonder how much time passes in > real use cases between binding to the socket and having all backend > servers resolved.
With libc these are resolved before binding so it's not a problem (though it sometimes takes time in some environments). With resolvers it could very well be faster, but it only starts after binding so during hot reloads, we're guaranteed to deliver 503s (unless using the state file of course). Also crashes can happen. These days it's not uncommon to see the process immediately restart. If it can take multiple seconds to resolve everything again, or if it restarts from an outdated state file it is not necessarily great. > If not already the case, I recon that resolvers could trigger > automatically when haproxy is done initializing. That's exactly what's done for the reason you mention. We initially hoped we could evolve towards an intermediary boot step when resolvers would start during parsing (init-addr dns) but it requires to have an almost second implementation of the same code which would work without an event loop, and as you know this has never been done (and I don't think it would be *that* useful). > Although self-ddosing > may be a problem in complicated setups when cascading failures occur. Sure! We've already seen some recently, related to other issues though. > My quest to make this as simple as possible turns out to be more > difficult than anticipated ... again. I know. It's always the problem when trying to mix concepts that are supposed to be simple for the user (e.g. DNS), with low-level stuff that can be used in many forms. It always ends up with a wide variety of possibilities :-/ > > The DNS client implemented in HAProxy is very basic and will not > > understand the vast number of options and advanced setups that an > > operating system's resolver can deal with. As such, except for really > > trivial setups where a server known by its FQDN only has exactly one > > IP address at a time and might occasionally renew it (e.g. a reboot), > > it is highly recommended to avoid mixing libc-based init-time > > resolution with DNS-based runtime resolution, as such setups are known > > to cause failures upon address renewal. As a conclusion, unless you > > know exactly what you are doing, you should always exclude "libc" from > > "init-addr" when using "resolvers" on a server line. > > I agree with this. You should commit it as is. OK that's what I've done now, along with some of the changes you suggested, so as to make users aware of the dangers of mixing the two. I've added a link to this discussion in the commit message. > > I was trying to think what warning could be added, that's not easy. But > > maybe one would be to say that init-addr should be explicit when using > > resolvers, so that users have at least read the related section of the > > doc. > > Yes I agree, a configuration warning would probably be a good thing. I'm fine with adding one in 3.3. I just don't want to ruin setups of 3.1 users that we'll want to seamlessly migrate to 3.2, because this will definitely be a breaking change. Cheers, Willy
