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
