Common application behaviour when connecting to a remote host is to lookup that host in DNS (getaddrinfo) and then loop through the list of addresses returned to attempt to connect to one.
In node, net.connect() calls dns.lookup() which only ever returns the first A or AAAA address for the specified host. This causes horrible problems when trying to connect to a host which returns both A and AAAA addresses when the client only has IPv4 or IPv6 (not both) connectivity; worse still, this can be inconsistent as the return order of getaddrinfo can be arbitrary.
Noted. What would you propose to change?
Ah, I see you opened a PR. I've added a back-link to this issue.
http://tools.ietf.org/html/rfc6555#section-4 and http://tools.ietf.org/html/rfc6555#section-6
I'm aware of that approach but opening an IPv4 and IPv6 connection simultaneously is rather anti-social IMO. Also, the suggestion in the RFC to cache the results will work against you if the network topology somehow changes, e.g. because an uplink comes up or goes down.
This also means that DNS round robin is ignored. It's just a giant pack of badness.
The normal solution here, and the solution implemented by, umm, everything else ever?, is to return all the A and AAAA records, and walk through them trying each until one connects.
I hit this issue with IPv6-only hosts; it was a show stopper for us. I solved it by placing the NAT64 IPv6 address for each of the node/npm hosts into /etc/hosts. Just thought I'd mention that as a workaround for others.
Seriously, the IETF created RFC 6555 as an global standard. You can judge it however you want, but it already went through the IETF standardization process and is implemented widely (Chrome, Firefox, OSX, ....). Do it and be done. The current state of ipv6 brokenness is simply embarrassing for Node and not supported by any standard RFC