Hi all - Just to chime in, we just got bit by this in production. Our dns resolver (unbound) does not follow CNAMES -> A records when you send an ANY query type. This is by design, so I can't just configure it differently (and ripping out our DNS resolver is not immediately feasible).
I therefore vote to stop sending the ANY query type, and instead rely on A and AAAA queries. I don't have any comments on behavior regarding NX behavior. NB: There is also support amongst some bigger internet companies to fully deprecate this query type: https://blog.cloudflare.com/deprecating-dns-any-meta-query-type/ On Thu, Oct 15, 2015 at 12:49 PM, Lukas Tribus <luky...@hotmail.com> wrote: >> 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/ > -- - Andrew Hayworth
