Hi all, Just wanted to add my 2¢ that the doc changes are a huge improvement from my perspective. Issuing a simple warning at startup could also be very useful for users who don't read the docs as religiously as I tend to…
Best, Luke — Luke Seelenbinder Stadia Maps | Founder & CEO stadiamaps.com > On Mar 17, 2025, at 14:24, Lukas Tribus <lu...@ltri.eu> wrote: > > Hi Willy, > > > On Thu, 13 Mar 2025 at 18:33, Willy Tarreau <w...@1wt.eu> wrote: >> >> OK, I never thought about all of this! >> >>> For example case 1: >>> An admin configures private resolvers in TCP mode to avoid issues with >>> bigger response sizes, however unbeknownst to him TCP mode is not >>> available/reachable for unrelated issues. The same name servers are >>> configured in /etc/resolv.conf, so libc is able to resolve the private >>> server IPs without issues, because libc uses UDP before falling back >>> to TCP. >> >> I generally agree (though I don't know how frequent this is). Also >> this raises the point of the relevance of parse-resolv-conf then: >> if discrepancies are this common, should we also discourage from >> using this option ? > > I don't dislike parse-resolv-conf, I think it's useful for cloud deployments. > > It can work fine with libc resolution disabled, we just need to make > that clear imo. > > > >>> I really want to drive home the point that this is not *only* about >>> different DNS servers, but also about different resolution behavior >>> when using the same DNS servers, because our code and libc code is not >>> the same. >> >> Totally got it now, thank you. >> >> I'm fine then with generally discouraging people from using the two at >> once. >> >> Maybe we could think about changing the default init-addr over the >> long term when resolvers are used (not sure this is easy to do, think >> about defaults). Or maybe we could add another variant of libc, such as >> "opt-libc" which would be libc only if resolvers is not used, and switch >> to that by default. What do you think ? >> >> The only problem is that I'd like to be able to emit a warning before >> changing that, and we probably don't want to force everyone to specify >> init-addr everywhere if we'd want to change a default later. Or maybe >> the resolution error should detect that resolvers are there and report >> that the setting changed. It would not be super cool but it could help >> users avoid serious traps. > > Yes, ideally we would do more than just doc updates, but indeed > considering that every backend server can have a different resolver > config this could be non trivial. > > Perhaps we could start with just a configuration warning when a > backend server is haproxy resolver enabled but libc still enabled for > the server? > > We just have to keep in mind that this is really a per server config knob. > > > >> And the other thing is to improve the doc. I'm pretty sure I'm far from >> being the only one around not thinking about all these "details" between >> libc and resolvers. > > 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. > > > > Regards, > > Lukas
