From b9883b086f44f396a16d03892c3368621f54c16a Mon Sep 17 00:00:00 2001 From: Andy Stark Date: Wed, 23 Sep 2026 10:59:49 +0100 Subject: [PATCH] DOC-7103 Document SNI hostname precedence for StackExchange.Redis TLS/cluster connections MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Adds an "SNI hostname selection for cluster connections" subsection to connect.md's TLS section, covering the SslHost/DnsEndPoint/default-provider/ endpoint-address precedence StackExchange.Redis#3250 introduced. Verified this is real, shipped behavior rather than an in-flight PR: `gh api repos/StackExchange/StackExchange.Redis/compare/3.3.1...` returned "identical", meaning the merge commit for #3250 *is* the 3.3.1 tag commit, not just an ancestor of it. That's a stronger and cheap-to-run check than eyeballing "merged" + a changelog mention, and it's why the version gate here is pinned to exactly v3.3.1, not "3.3.x" or "check the changelog." Left the fallback provider unnamed ("the default SNI provider") rather than citing the internal `GetSslHostFromEndpoints` method the upstream PR description uses — couldn't confirm it's stable public API rather than an implementation detail, and AGENTS.md's prose/code-form split only calls for literal identifiers where the reader actually types them. Learned: gh compare(tag...merge_sha) == identical is a reliable released-vs-merged check, cheaper than changelog reading Rejected: naming GetSslHostFromEndpoints in prose | not confirmed as stable public API, only appears in the upstream PR description Constraint: version gate must stay exactly v3.3.1 (the tag the merge commit resolves to), not loosened to "3.3.x" Recheck: if StackExchange.Redis changes SslHost/SNI resolution again, re-verify this precedence order and version gate against the new release Ticket: DOC-7103 Co-Authored-By: Claude Sonnet 5 --- content/develop/clients/dotnet/connect.md | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/content/develop/clients/dotnet/connect.md b/content/develop/clients/dotnet/connect.md index 4edd4c78ab..2a2e842cf1 100644 --- a/content/develop/clients/dotnet/connect.md +++ b/content/develop/clients/dotnet/connect.md @@ -130,6 +130,26 @@ conn.StringSet("foo", "bar"); Console.WriteLine(conn.StringGet("foo")); ``` +### SNI hostname selection for cluster connections + +> [!NOTE] +> The SNI precedence scheme described in this section +> requires `StackExchange.Redis` v3.3.1 or later. + +When you connect with TLS to a cluster that `StackExchange.Redis` discovers through +`CLUSTER SLOTS`, each discovered node needs its own +[SNI hostname](https://en.wikipedia.org/wiki/Server_Name_Indication). This allows a shared load +balancer or proxy to route the TLS handshake to the right backend. `StackExchange.Redis` +resolves the SNI hostname for a connection in this order: + +1. An explicitly configured `ConfigurationOptions.SslHost` always wins. +2. Otherwise, a `DnsEndPoint` uses its own host. +3. Otherwise, the client falls back to the default SNI provider. +4. If none of these is available, the client uses the endpoint address. + +Because of this order, `ConfigurationOptions.SslHost` only reports a value if you set one +explicitly; it doesn't report a host that the client inferred for you. + ## Connect using Smart client handoffs (SCH) *Smart client handoffs (SCH)* is a feature of Redis Cloud and