Hi folks,
> Hey guys, > > by default, HAProxy tries to resolve server IPs using an ANY query > type, then fails over to resolve-prefer type, then to "remaining" > type. > So ANY -> A -> AAAA or ANY -> AAAA -> A. We can't really rely on ANY queries, no. Also see [1], [2]. > Today, 0yvind reported that weave DNS server actually answers with an > NX response, preventing HAProxy to failover to next query type (this > is by design). > > Jan, a fellow HAProxy user, already reported me that ANY query types > are less and less fashion (for many reasons I'm not going to develop > here). > > Amongs the many way to fix this issue, the one below has my preference: > A new resolvers section directive (flag in that case) which prevent > HAProxy from sending a ANY query type for the nameservers in this > section ie "option dont-send-any-qtype". > > An other option, would to make HAProxy to failover to next query type > in case of NX response. In my opinion we need both, because when we no longer use ANY, but AAAA with A fallback (or vice versa), NX is actually an expected and valid answer that is SUPPOSED to make us retry the next qtype, otherwise we have the same exact problem as we have are having with ANY in the first place (as we can't and won't require that all our backends are dual-stacked). In many environments the administrator of the haproxy box is not administrating the backend server as well, therefor we cannot tell users "use resolve-prefer to set the address family correctly". Reality is that we don't know if the backend server is ipv4-only, dual-stacked or ipv6-only, and if we stop querying after a address-family specific NX response, we basically introduce a new problem. Regards, Lukas [1] https://blog.cloudflare.com/deprecating-dns-any-meta-query-type/ [2] https://lists.dns-oarc.net/pipermail/dns-operations/2013-January/009501.html
