The problem/use-case that the feature addresses

When the nodes in a cluster are configured with ports for both TLS and plaintext simultaneously, the CLUSTER SLOTS response only includes the TLS ports of the nodes in the cluster.

Clients which are still connecting to the cluster without TLS would need to get the plaintext port of each node somehow.

Description of the feature

Let CLUSTER SLOTS return the TLS ports of all the Redis Cluster nodes to clients connected over TLS and the plaintext ports to clients connected over plaintext.

Alternatives you've considered

• Extend the response of CLUSTER SLOTS to include the plaintext port as the 4th element (after IP, TLS-port and node ID) when both ports are used. The following warning from the CLUSTER SLOTS documentation opens for this kind of extension:

  Warning: Newer versions of Redis Cluster will output, for each Redis instance, not just the IP and port, but also the node ID as third element of the array. In future versions there could be more elements describing the node better. In general a client implementation should just rely on the fact that certain parameters are at fixed positions as specified, but more parameters may follow and should be ignored. Similarly a client library should try if possible to cope with the fact that older versions may just have the IP and port parameter.

• Workarounds (not very good):

  • Tweak the Redis Cluster clients to figure out the non-TLS port given the TLS port (for example hard-coded or using the convention TLS-port = plaintext-port + 1)
  • Let some middleware intercept the Redis traffic and change the ports in the CLUSTER SLOTS responses, while forwarding other traffic as-is.
  • Terminate TLS in the middleware.
  • Avoid the problem by switching over the whole system to TLS at once. This is hard in a deployment with rolling upgrades of multiple components in different languages.

Additional information

I'm guessing the node-to-node protocol (Redis Cluster Bus?) doesn't include both ports of each node, so a node doesn't necessarily know both ports of the other nodes in the cluster. In that case, the node-to-node protocol would need to be extended.