We have encountered exactly the same issue. We use separate Microsoft Fabric workspaces for our acceptance and production environments, but the generated SQL endpoint hostnames provide no recognizable indication of which environment they belong to.
Supporting CNAME records would allow us to use clear names such as lakehouse-acc.company.com and lakehouse-prod.company.com. This is not merely cosmetic: it would reduce the risk of users, applications, and configuration files accidentally connecting to the wrong environment. It would also provide a stable abstraction if a Fabric workspace or endpoint ever needs to be replaced.
We verified that the CNAME resolves correctly and reaches the Fabric endpoint. The original Fabric hostname connects successfully, but the CNAME connection is reset with error 10054, even when HostNameInCertificate contains the original Fabric FQDN. This suggests the custom hostname is rejected by the Fabric TDS/SNI routing layer.
Support for verified custom hostnames or CNAME bindings would significantly improve environment management, operational safety, and maintainability for organizations using separate development, acceptance, and production workspaces.
