Expand Default Server Domain functionality
Currently, the only way to change the Default Server Domain of "servername.vps.webdock.cloud" is to connect a CloudFlare account so A and AAAA records can be deployed automatically.
But sometimes, this is not necessary, for example if we use CloudFlare Tunnel or other Zero Trust products which circumvent port forwardings by running through an edge network and make the A and AAAA record for the servers origin IP unneeded.
So I propose to rebuild or expand the current functionality in the following way:
- Allow to "connect" a domain to a Webdock account by verifying it (ownership) through industry-standard TXT records.
- Allow to change the Default Server Domain with a verified domain.
- If the user wants to automatically deploy A and AAAA records, there can be a button that triggers this workflow, CloudFlare has a usable workflow for this already, Microsoft uses this for example for MS365 and connecting a new domain (verifying ownership and also deploying the DNS records).
-- It works by calling a specific endpoint of CloudFlare to prompt the creation of various DNS records, in this case the A and AAAA records for the server.
-- And this workflow will use the login cookie of the current browser session to land in the correct CloudFlare tenant.
- If no A and AAAA records are necessary, the button can just not be pressed, the server now has the new Default Server Domain and everyone is happy :)
And this functionality could be on either account level and/or server level, to e.g. just change the domains of some servers, not change the default of the account.
Log in to comment and vote
Comments5
Arni Johannesson
Apr 25, 2023
Some clarifications here:
You should never be able to change servername.vps.webdock.cloud to anything other than a domain you control already.
In which case, just do that (i.e. point your own domain or whatever you like) and set it as "main domain" in Server Identity.
If you just want to get rid of the webdock.cloud alias, this is a feature on our roadmap we want to do. We "enforce" this alias, for now at least, in order to guarantee that less proficient users always have a url which resolves to their server so they can access phpmyadmin etc.
What are you trying to solve here with your proposal, exactly? It is unclear to me
Epsilon PS _ Paul Schiffer
Apr 25, 2023
Arni from Webdock: My current understanding of the Server Identity Tool is that I have to point the FQDN I want to use as the Main domain to the public IPv4+6 addresses of the respective server, via A and AAAA records.
But this isn't possible while using CloudFlare Tunnel or other Zero Trust products since they do not point to the public IPs of the server, but rather to the edge of the respective provider.
So I can't successfully exchange the Main Domain while using these products since I can't point to the public IPs.
And my proposal here circumvents the need to point to the IPs and rather verifies ownership of the domain and then optionally sets up records with the public IPs.
Arni Johannesson
Apr 26, 2023
Epsilon PS _ Paul Schiffer: OK now I understand better. I think we will need to investigate how we can integrate against Cloudflare Tunnel and understand better how we can make this easy for our customers. Thank you for clarifying!
Epsilon PS _ Paul Schiffer
Apr 28, 2023
Arni from Webdock: Just another thought I had just now: You shouldn't entirely focus these features just around CloudFlare since that impacts usability if anything should happen to CloudFlare but also limits potential customers that don't want to / can't use CF.
TailScale and ZeroTier are other services that do the same, so implementing the technical side with an open mindset is crucial for long term "stability".
Apr 25, 2023