...

• If a hostname resolves to multiple IP addresses and connecting to the first IP failed, the client will attempt to connect to the other IP's instead of failing. Based on the common expectation, this is what is expected.
• If a hostname resolves to a single IP address and connecting to it failed, then the connection will fail.

Please note that the concern raised in KIP-235 does not apply to this KIP. The concern was raised because KIP-235 proposed to modify ClientUtils#parseAndValidateAddresses to resolve an address alias (i.e. bootstrap server) into multiple addresses. This would break SSL hostname verification when the bootstrap server is an IP address, i.e. it will resolve the IP address to an FQDN and use that FQDN in the SSL handshake.

This KIP is proposing to only modify ClientUtils#resolve, which is only used in ClusterConnectionStates#currentAddress, to get the resolved InetAddress of an address. And ClusterConnectionStates#currentAddress is only used by NetworkClient#initiateConnect to create InetSocketAddress to establish the socket connection to the broker. In other words, this KIP only change the behaviour of resolving address to the IP address used by the socket to connect to the broker.

Rejected Alternatives

• Keep the default behaviour of client.dns.lookup to connect to the first resolved IP. The reason this is rejected is because it does not match with the common expectation when a hostname resolves to multiple IP addresses.
• Remove "default" value from client.dns.lookup. There is a lot of places in the server code that uses "default" value, so removing "default" value would require changing many server code, which is high risk.