@Luke Liu please provide an explanation on why users need to choose and use a 4LD. @Scion has a good point in that it should be as base as a 2LD i.e. `foo.bar`. Most users will want a 3LD i.e. `foo.bar.suf` but in any case it should be entirely arbitrary. If security is the reason, do the right thing and explain the rationale, I'll be more than happy to provide a response to that.
We run a service desk for customers of multiple brands, so we already have a generic domain name we use for email that isn't being used.
If it had to be something like support.example.com that would be okay, although not ideal, but I feel that forcing it to be longer makes it unnecessarily complicated for customers.
If after all these years Atlassian makes it so we must use subdomain.subdomain.domain.tld then they'll lose customers.
Who thought that ignoring the scope of the ticket was a clever idea after almost 12 years?
Scope from ticket page:
"Today, you can sign up for certain Atlassian cloud products (Jira Software, Jira Service Management, and Confluence) under the subdomain of your choice. For example, if your company is Acme, you can host these products under acme.atlassian.net
The scope of "custom domains" on this ticket is to allow customers to use Atlassian cloud products on their own second-level domain, i.e. jira.acme.comor acme.com/confluence"
I‘m wondering how you came up with the idea of forcing multiple subdomains. Also in CLOUD-6999 this was never a topic. Please let the user decide. Also, please do not force jira.support.atlassian.net.acme.com or something similar 😉
For more than two years now we want to switch from server to cloud but this a breaking issue. We are always told it’s coming soon but it doesn’t.
We have a public Confluence site using only the 2nd level domain in its URL. I have no use of 2nd level subdomains or even more subdomain levels using keywords. Simply, just let me choose my own domain name structure.
The sub-domain keyword requirement is a really bad idea, and I'm not clear as to why you even need a sub-domain. If I wanted Jira to be the website for my domain, ideally you would be allowed to set your Jira URL as "mysupportsite.com". There would be no issue with DNS supporting this.
I would be fine if the double subdomain is OPTIONAL, in case of needed but please don't make it a requirement! I also don't see a benefit of it - while I just want to have my customers go to support.smart-power.net to find JIRA.
* we can choose whatever token for our website, that makes business sense (including in languages that you might not anticipate)
* we can move to the cloud without asking all our existing users that their bookmarks are now obsolete, without changing the links in our products that redirect to the related documentation hosted on our existing confluence custom URL
Atlassian Team members are employees working across the company in a wide variety of roles.
March 15, 2023 edited
To the community and long-time watchers of CLOUD-6999, we are super grateful for your engagement and feedback. We know how important it is for you to have a clear and detailed understanding of the technical reasons behind these constraints and how they ensure the safety of your custom domains. We will come back with a separate update addressing this question as soon as possible.
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
We have an existing domain name for our Confluence service that we would like to retain so that many incoming links don't break. Forcing the subdomain keyword is a problem.
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
In all honesty, it's completely ridiculous to force a 2nd subdomain. Give the OPTION, yes. But do not force people to use 2 levels down like "internal.support.acme.com".
@Luke Liu This issue does not have anything to do with Cloud security. It can only be because of some Cloud Architecture that was badly designed and then the effort to correct became too much for Atlassian.
What all of us want Atlassian to understand is that doing a workaround to enable 2 levels of domain is not what we asked for and won't work for us and will only lead the clients away from Atlassian and onto other Providers.
I'll echo what everyone else is saying, just to make it clear that I do not support requiring picking a sub-domain from a pre-defined list and then requiring adding yet another in front of that.
We want/need wiki.mydomain.com to point to confluence, service.mydomain.com to point to JSM, etc. or mydomain.com/jira to point to Jira, etc.
Requiring an additional layer of subdomain isn't required by any other provider, and the lack of support for such a basic feature in the B2B world is making us second guess our decision to use Atlassian products.
The requirement for a subdomain and a keyword is a little unusual. What security purposes are satisfied by this requirement? In my case, as it would be with most of the rest of the world, we don't have a .com domain, we are a school in Australia, so our domain could end up being somehting like something.support.school.nsw.edu.au, which is obviusly ridiculous. This is a little disappointing.
The scope of "custom domains" on this ticket is to allow customers to use Atlassian cloud products on their own second-level domain, i.e. jira.acme.com or acme.com/confluence
91 comments