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 ;
- 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 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.
Willy
