> on a GNU/Linux system the only correct method of resolving DNS is by using gethostbyname I don't think that's right. gethostbyname() doesn't query DNS, it q

> on a GNU/Linux system the only correct method of resolving DNS is by using gethostbyname I don't think that's right. gethostbyname() doesn't query DNS, it queries names, which includes /etc/hosts, and possibly NIS, active directory, and other possible things. Most applications would never be expecting 100 results from one of these queries and many will not tolerate it well. Specialised users of gethostbyname() can certainly do better, but what I doubt is the wisdom of such specialisation: It certainly has nothing to do with the application -- it is literally under the control of the network administrator as you are well aware. Specialisation can occur in your application, but it can just as easily specialise another way. On the other hand, if your application really wants to specially speak to Consul's DNS (as opposed to whatever the network administrator is doing) it can definitely use res_query() > so it's not exactly hard to support 100 results Maybe we mean different things by "support": What do you do with them? > I'm not really sure what you mean by "support gethostbyname robustly" When most applications connect to a host they get from gethostbyname they often connect to the first, and give up if the connection opens and resets: This is exceptionally common with load balancers and address translation. To those applications, what is the point of giving them multiple results in this situation? A few applications try to handle the result robustly: connect to a random member of the list, or connect to several in parallel and try the request in parallel. Some applications do really wild stuff here to make a good user-experience. Most do not. When someone types `ping google.com` (for example) you only ever get one result. If that name doesn't ping, it doesn't try another. Most are like that. Hopefully that makes what I mean by "robustly" clearer.