Hi Lukas,

On Fri, Apr 06, 2018 at 12:33:14PM +0200, Lukas Tribus wrote:
> On 6 April 2018 at 11:14, Willy Tarreau <w...@1wt.eu> 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,


Reply via email to