Hi all, Thanks a lot for your feedbacks. Really valuable. I'll discuss with Willy the best approach for the change.
Baptiste On Mon, Oct 19, 2015 at 11:50 PM, Andrew Hayworth <[email protected]> wrote: > 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 <[email protected]> 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
