Hi Lukas, On Fri, Apr 06, 2018 at 12:33:14PM +0200, Lukas Tribus wrote: > On 6 April 2018 at 11:14, Willy Tarreau <[email protected]> wrote: > >> I don't think we need a new config know. > > > > Just thinking, is the goal *not to have to* configure "resolve" on > > server lines in this case, or to avoid having to pre-configure the > > resolvers themselves when they're the same as the system's ? > > The latter is the goal.
OK thanks for confirming. > > If the former, that would mean always enabling DNS resolving at runtime > > which doesn't sound like a good idea at all to me. If the latter, then > > why not have a special directive in the resolvers section to indicate > > that it should use resolv.conf instead ? That could avoid some surprizes > > when you simply comment your all your resolvers and that suddenly the > > behaviour changes. I'd even say that this directive could serve to > > populate the resolvers section from resolv.conf (thus possibly several > > resolvers) which will ensure the exclusivity between the two mechanisms. > > Yes, that's a good point. In fact, I don't see why the fallback has to > be implicit. > > The confusion often arises because haproxy accepts a resolver > configuration where no resolvers are configured. Maybe we should > reject the configuration when a resolver is referred to in the servers > lines, but no actual resolvers are configured (AND resolv.conf parsing > is not enabled in future). Well, sometimes when you're debugging a configuration, it's nice to be able to disable some elements. Same for those manipulating/building configs by assembling elements and iteratively pass them through "haproxy -c". That's exactly the reason why we relaxed a few checks in the past, like accepting a frontend with no bind line or accepting a backend with a "cookie" directive with no cookie on server lines. In fact we could simply emit a warning when a resolvers section has no resolver nor resolv.conf enabled, but at least accept to start. Just my two cents, Cheers, Willy
