Skip to content

How can we improve the platform?

← Atlas

Allow custom DNS hostnames to be added to cluster config / TLS certs

Since Atlas clusters now support different sets of hostnames, it would be good to explore the feasibility of allowing users to add their own hostnames to the cluster configuration and TLS certificates such that custom connection strings can be used.

One use case for this is being able to "wrap" Atlas connection strings, such that an application's connection string would never need to change despite underlying cluster changes (cluster being moved between projects, etc.)

This could also be useful if you wished to whitelabel your cluster.

45 votes

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close

We’ll send you updates on this idea

Matthew shared this idea  ·   ·  Report…  ·  Admin →
How important is this to you?

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
Submitting...
An error occurred while saving the comment
  • Benoît commented  ·   ·  Report

    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

  • Luke commented  ·   ·  Report

    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.

  • Bo Byrd commented  ·   ·  Report

    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)

  • Pavan commented  ·   ·  Report

    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.

  • Angelo commented  ·   ·  Report

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

  • Rob commented  ·   ·  Report

    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.<service-namespace>.<environment>.<company>.<tld> 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.

Atlas: Other

Categories

Feedback and Knowledge Base

(thinking…)