Hi Willy, On Wed, 30 Apr 2025 at 11:59, Willy Tarreau <w...@1wt.eu> wrote: > > Hi Lukas, > > getting back to this thread after quite some time, sorry for the delay. > > On Mon, Mar 17, 2025 at 01:24:37PM +0100, Lukas Tribus wrote: > > My attempt in this patch was sparse: > > > > + - disabling libc based initial name resolution with the "init-addr" > > server > > + setting is recommended to avoid using two different name resolution > > + strategies, as their behavior will diverge. > > > > > > I'm not sure if making it dense is beneficial or if it just becomes > > more confusing. If I make the FQDN / search domain example, people > > will just think that it doesn't impact them if they run a full FQDN > > config, yet it is just one of many examples and it will never be > > possible to predict / list them all. > > > > > > Perhaps just elaborating a little bit like: > > > > + - disabling libc based initial name resolution with the "init-addr" > > server > > + setting is recommended to avoid using two different name resolution > > + strategies, as their behavior will diverge. Due to the possible > > + behavior difference, initial libc resolution may hide problems related > > + to haproxy resolver. > > > > > > It would be useful to get some user feedback regarding this topic. > > 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. If not already the case, I recon that resolvers could trigger automatically when haproxy is done initializing. Although self-ddosing may be a problem in complicated setups when cascading failures occur. My quest to make this as simple as possible turns out to be more difficult than anticipated ... again. > - the case where users start to rely on advanced stuff, including > multiple address families, multiple records, extensions and whatnot, > where I totally agree with you, our DNS client was never designed to > try to mimmick libc. These ones should be discouraged. > > For the first ones if the wording discourages it, we then just offer no > alternate solution. I tend to think that explaining the problem can help > users figure if that concerns them or not. For example something around > the following: > > 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. > 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. Lukas
