> I second this opinion. Removing ANY altogether would be the best case. > > In reality, I think it should use the OS's resolver libraries which > in turn will honor whatever the admin has configured for preference > order at the base OS level. > > > As a sysadmin, one should reasonably expect that tweaking the > preference knob at the OS level should affect most (and ideally, all) > applications they are running rather than having to manually fiddle > knobs at the OS and various application levels. > If there is some discussion and *good* reasons to ignore the OS > defaults, I feel this should likely be an *optional* config option > in haproxy.cfg ie "use OS resolver, unless specifically told not to > for $reason)
Its exactly like you are saying. I don't think there is any doubt that HAproxy will bypass OS level resolvers, since you are statically configuring DNS server IPs in the haproxy configuration file. When you don't configure any resolvers, HAproxy does use libc's gethostbyname() or getaddrinfo(), but both are fundamentally broken. Thats why some applications have to implement there own resolvers (including nginx). First of all the OS resolver doesn't provide the TTL value. So you would have to guess or use fixed TTL values. Second, both calls are blocking, which is a big no-go for any event-loop based application (for this reason, it can only be queried at startup, not while the application is running). Just configure a hostname without resolver parameters, and haproxy will resolve your hostnames at startup via OS (and then maintain those IP's). Applications either have to implement a resolver on their own (haproxy, nginx), or use yet another external library, like getdnsapi [1]. The point is: there is a reason for this implementation, and you can fallback to OS resolvers without any problems (just with their drawbacks). Regards, Lukas [1] https://getdnsapi.net/
