Having looked at this again, I'm firmly convinced that: - if address family is set to AF_UNSPEC, getaddrinfo() should by default attempt both IPv4 and IPv6 lookups - even if the local system is not capable of communicating on both IPv4 and IPv6. it can be useful to do A lookups even if the local system doesn't support IPv4, and it can be useful to do AAAA lookups even if the local system doesn't support IPv6. the job of an API is to do what the application tells it to do, not to guess what the application needs. when getaddrinfo() tries to be too clever (as it does on some platforms) it gets in the way and makes it difficult just to do simple DNS lookups.
this implies that a feature to avoid A or AAAA lookups on systems that cannot communicate on v4 or v6 (respectively) should be optional, as AI_ADDRCONFIG is. - It's highly desirable to avoid unnecessary DNS queries. DNS is too slow and unreliable for single queries; multiple queries only makes this worse. There are various ways that DNS could be updated to return the same information in fewer round-trips, but none of them would obviate the need for hosts to do multiple concurrent queries in the near term. - AI_ADDRCONFIG is an imperfect heuristic, not a reliable indicator of whether an address can be used. that doesn't mean that it's useless, but it does mean that people need to be aware of its limitations and not rely on it to do magic - in particular, it will not do a perfect job of either avoiding unnecessary lookups and connection attempts, or (due to race conditions) of finding all usable addresses. - getaddrinfo SHOULD ONLY DO DNS QUERIES. LLMNR/mDNS, NIS/NIS+, netinfo, WINS and local file lookups only serve to cause divergence between platforms and problems for apps that need a consistent view of DNS. (Note: I don't expect to get consensus for this view, so I'll offer a less radical view: Apps whose behavior is defined based on "what DNS says", rather than some other name lookup service, need a portable and reliable way to find out "what DNS says" without having to supply their own DNS lookup routines. e.g. maybe there needs to be a AI_DNS_ONLY flag for getaddrinfo?) - if AI_ADDRCONFIG is set, the decision of whether to do DNS lookups for a particular address family should ignore link-local addresses as well as loopback addresses. This is in keeping with the notion that AI_ADDRCONFIG is an imperfect heuristic. The configuration of only link-local addresses for a particular address family is a good (though imperfect) indicator that DNS queries for that address family will not yield usable results. OTOH, if getaddrinfo() is set up (against my better judgement) to do queries from services other than DNS, the choice of whether to query other services might not want to ignore link-local addresses. For example, on a host with only a v4 link-local address configured it might make sense to query LLMNR for A records. - IMHO, getaddrinfo()'s job should be to report what is in DNS, not to try to coerce apps into behaving well. So even though apps shouldn't be using link-local addresses, and even though people shouldn't list link-local addresses in DNS, getaddrinfo() should not try to hide such addresses from apps if they happen to appear in DNS. Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
