Revisiting DNS round-robin + TLS hostname verification

[ogolberg]

Background

DNS round robin (#138) was disabled because it was deemed not compatible with TLS hostname verification (#394).

My usecase requires both: DNS round robin for edge load balancing, which is pretty common, and hostname verification for obvious security reasons.

Problem

It is possible to have DNS round robin play nice with hostname verification. The problem is the Address abstraction which loses the original hostname when it's constructed from a resolved InetAddress by DnsRecordIpAddressResolver. If we pass InetAddress obtained from InetAddress.getAllByName into the Socket.connect method, the HTTPS hostname verification algorithm will work fine. For example, something like this works:

InetAddress[] addrs = InetAddress.getAllByName("..");
  
for (addr: addrs) {  
    SSLSocket socket = (SSLSocket) socketFactory.createSocket();
 
    SSLParameters params = sock.getSslParameters()	
    params.setEndpointIdentificationAlgorithm("HTTPS")
    socket.setSslParameters(params)  
  
    sock.connect(InetSocketAddress(addr, ...))
}

Proposed change

One way to make this work would be to change the AddressResolver API to return a list of InetSocketAddresses and reintegrate DnsRecordIpAddressResolver. This can also be gated by a configuration flag.

Would you be open to such a change? I can take a stab at a PR.

[michaelklishin]

I don't have any objections

[acogoluegnes]

Sure, go ahead.

Note we should remain backward compatible to be able to include the change into 5.x. This means we cannot change a public interface like AddressResolver. It's still possible to introduce a sub-interface or a sub-class. The core code can then check for these new types (instanceof) where it matters and use them accordingly. This way do not break things.

Provide the PR as-is if you don't feel comfortable with the backward compatibility technics, the point is to get the idea, and we'll see what we can do afterward.

[ogolberg]

I ended up subclassing Address which wasn't too bad - see #827