4 years open and nothing to do

+1

+1

Using a private domain name is important for us to align with our internal naming conventions. It's also the mecanism we use in case of DR. To be able to easily switch to a new cluster (just by upgrading the CNAME) without redeploying all our microservices

+1

Using our own domain names is really important for us. We use AWS Private Endpoint URLs in our docker Java application and Python lambdas. If the connection string could be a CNAME / Alias DNS record of our own which we could switch to point at different databases we could handle the rollback safely without any redeployment. After changing the DNS, we could allow the TTL to expire + pause the original cluster, causing all the connections to be re-established with the database of our choice without any configuration changes or app/lambda redeployments. e.g. Major Version Upgrade (rollback on failure) When upgrading major versions, there is no automatic rollback to the prior version supported. So our solution is to have a backup cluster spun up alongside the production cluster with a recent snapshot, running the old major version. As we upgrade the production cluster to the new major one; should anything go wrong we can roll back to the backup cluster. This process would be significantly hampered by the need to change the connection strings and redeploy all of the lambdas and applications, and would slow down + threaten the integrity (should we miss something) of the rollback procedure. It would also be cool if we could have a major version downgrade option in Atlas. The way it could work would be by adding a new node to the cluster (non-voting, data bearing, hidden) which stays on the old major version. It could be configured to stick around for 1-48 hours after the major version upgrade still receiving replication of data during which time it could be used to roll back with no down time.

+1

+1

+1

+1

+1

Yes, please. And IMO it would be more preferable to handle this in a SAN manner with multiple domains where we can just add our custom domain in there with yours. (instead of us simply providing our own cert)

+1

Another usecase for this is we can use the custom hostname/s in the mongodb connection string in the application instead of renaming the cluster name which is not possible as of now.

We prefer to be able to set hostnames that our within our private domain to meet our services' naming convention.

Our use case for this feature is as follows: We have many small clusters, each cluster is associated with a service which has multiple environments (dev/test/prod). It's much simpler for us to spin-up clusters and then add custom DNS records for those clusters that fit a set pattern, e.g: mongodb.... and have this connection address used across all our clients than it is to reconfigure every single client with custom DNS information across all environments after a new mongodb cluster is created or changed. Because we are currently have to use the real atlas DNS, it creates a hard dependency between infrastructure and application configuration layers which would ideally be avoided.