Cosmos DB SDK behind a TLS-inspecting proxy: strict certificate validation with private endpoint DNS

Goal

We run the Azure Cosmos DB SDK (Java and .NET clients) behind a corporate egress proxy that re-terminates TLS, and we also use a private endpoint for the account. The goal is to keep strict certificate validation enabled end to end while DNS resolution and the proxy's certificate chain both behave correctly, including during regional failover.

Constraints and uncertainty

With the private endpoint, the account name must resolve through the privatelink DNS zone rather than to public IPs, and our custom DNS forwarders are shared with other workloads. Separately, the proxy presents its own chain to clients, so the SDKs fail validation unless the proxy root CA is in the client trust store. We do not want to disable validation or trust all certificates. We are also unsure how JVM and OS DNS caching interact with Cosmos DB endpoint changes after failover, and whether our SDK version still does any certificate pinning that would conflict with the proxy chain.

Questions

• Should the proxy's root CA be imported into each client trust store, or is there a supported way to exclude the Cosmos DB endpoint from inspection while keeping validation strict?
• With a private endpoint, what DNS configuration ensures account.documents.azure.com resolves to the privatelink zone for all client subnets without breaking other resolution?
• What DNS cache TTL settings (JVM networkaddress.cache.ttl, OS resolver) are appropriate so clients recover quickly after a Cosmos DB failover without excessive query load?