Hello Willy,
On 6 April 2018 at 14:14, Willy Tarreau <w...@1wt.eu> wrote: >> 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. Understood; however in this specific case I would argue one would remove the "resolver" directive from the server-line(s), instead of dropping the nameservers from the global nameserver declaration. Maybe a config warning would be a compromise for this case? Regards, Lukas
