Andrew Hayworth e6a4a329b8 MEDIUM: dns: Don't use the ANY query type ... Basically, it's ill-defined and shouldn't really be used going forward. We can't guarantee that resolvers will do the 'legwork' for us and actually resolve CNAMES when we request the ANY query-type. Case in point (obfuscated, clearly): PRODUCTION! ahayworth@secret-hostname.com:~$ dig @10.11.12.53 ANY api.somestartup.io ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @10.11.12.53 ANY api.somestartup.io ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62454 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0 ;; QUESTION SECTION: ;api.somestartup.io. IN ANY ;; ANSWER SECTION: api.somestartup.io. 20 IN CNAME api-somestartup-production.ap-southeast-2.elb.amazonaws.com. ;; AUTHORITY SECTION: somestartup.io. 166687 IN NS ns-1254.awsdns-28.org. somestartup.io. 166687 IN NS ns-1884.awsdns-43.co.uk. somestartup.io. 166687 IN NS ns-440.awsdns-55.com. somestartup.io. 166687 IN NS ns-577.awsdns-08.net. ;; Query time: 1 msec ;; SERVER: 10.11.12.53#53(10.11.12.53) ;; WHEN: Mon Oct 19 22:02:29 2015 ;; MSG SIZE rcvd: 242 HAProxy can't handle that response correctly. Rather than try to build in support for resolving CNAMEs presented without an A record in an answer section (which may be a valid improvement further on), this change just skips ANY record types altogether. A and AAAA are much more well-defined and predictable. Notably, this commit preserves the implicit "Prefer IPV6 behavior." Furthermore, ANY query type by default is a bad idea: (from Robin on HAProxy's ML): Using ANY queries for this kind of stuff is considered by most people to be a bad practice since besides all the things you named it can lead to incomplete responses. Basically a resolver is allowed to just return whatever it has in cache when it receives an ANY query instead of actually doing an ANY query at the authoritative nameserver. Thus if it only received queries for an A record before you do an ANY query you will not get an AAAA record even if it is actually available since the resolver doesn't have it in its cache. Even worse if before it only got MX queries, you won't get either A or AAAA		2015-10-20 22:31:01 +02:00
..
common	BUILD: enable build on Linux/s390x	2015-10-12 20:58:51 +02:00
import	MAJOR: tproxy: remove support for cttproxy	2015-08-20 19:35:14 +02:00
proto	MINOR: ssl: Add support for EC for the CA used to sign generated certificates	2015-10-09 12:13:12 +02:00
types	MEDIUM: dns: Don't use the ANY query type	2015-10-20 22:31:01 +02:00