When a DNS server is looking up an IP address for a client, and it receives a list of multiple DNS servers to query, how does it choose one? Similarly, when a DNS client receives a list of multiple IP addresses for a FQDN, how does it choose one? Is it implementation specific, or is covered in an RFC?
A DNS server resolving a query, may prioritize the order in which it uses the listed servers based on historical response time data (RFC1035 section 7.2). It may also prioritize by closer sub-net (I have seen this in RFC but don't recall which). If no history or sub-net priority is available, it may choose by random, or simply pick the first one. I have seen DNS server implementations doing various combinations of above.
A client program picking an IP address from a list (of A/AAAA-records) will generally try the addresses in the order they where returned by the DNS server (round robin). If the client cannot connect to the first IP address returned, it should try the second and so on. For example all major browsers do this, however many other Internet client programs "forget" this step and fail if they cannot connect to the first IP address.
RFC 1794 Covers the Round Robin question you're asking.
As far as the answers go, Most DNS clients will use the first IP address in the list, some do subnet calculations to figure out which is closer, others choose randomly, but most depend on the DNS server to send the list.
It depends on the client - of particular relevance for anybody running a Windows shop is the fact that Vista\Windows Server 2008 will choose the address using a different mechanism (if the ipv6 stack is installed) to earlier Windows versions which would choose the first address. In many cases this means they will always choose the same one ie they won't "honor" DNS round robin responses in the same way as the earlier versions. There is a detailed explanation of this in this technet blog article.
The linked article indicates that Windows 7 and Server 2008 R2 change this default behavior again but I can't find anything to back that up.
Also it's worth pointing out that this is the standards compliant behaviour for ipv6 as far as I can tell, although I'd be very glad to find out that I was wrong.