Using Cloudron to setup DNS records in new DNS Provider before switching Nameservers on domain. Vanity Nameservers could also be supported if changes made.

[d19dotca]

@BrutalBirdie That makes sense, I'm pretty sure I understand how DNS all works. Maybe I'm overthinking it or missing what's in front of my face though, so here's the scenario...

1. My domain is registered at OVH (they're the registrar)
2. I create GLUE records at the registrar, creating ns.<myDomain> with an IP that matches that of ns1.vultr.com, and do the same for ns2.
3. I then change the name servers at OVH to point away from their own (or currently DO's) DNS servers, and to my own vanity name servers (which simply point to Vultr's NS IPs in the end).

At that point... if you check the DNS records for my domain, it should show the nameservers as ns1.<myDomain> and ns2.<myDomain> rather than Vultr's name servers hostnames.

So in that scenario, does Cloudron still understand that Vultr is the authoritative nameserver for it? I guess I'm not sure if that part would show up in a dig command for example when vanity nameservers are used, and more specifically I don't know how exactly Cloudron checks to ensure it's set to Vultr's NS. Is it expecting to see ns1.vultr.com and ns2.vultr.com somewhere in there? If it is, then I'd assume it doesn't support vanity nameservers, right?

Sorry for the questions, I'm just trying to map this out in my head and while I have a fair bit of DNS experience, something about this check done by Cloudron just isn't computing, haha. I may try to do the test you suggested on a subdomain to see if I can better confirm that part.

[BrutalBirdie]

Ok I had to read up a little on Vanity Nameserver

https://www.digitalocean.com/community/tutorials/how-to-create-vanity-or-branded-nameservers-with-digitalocean-cloud-servers

or namecheap
https://www.namecheap.com/support/knowledgebase/article.aspx/324/10/what-is-the-personal-dns-servers-option-used-for/

https://www.namecheap.com/support/knowledgebase/article.aspx/768/10/how-do-i-register-personal-nameservers-for-my-domain/

So I think my answer might not be sufficient.

---

@d19dotca said in Vanity Nameservers... does Cloudron Support it?:

I create GLUE records at the registrar, creating ns.<myDomain> with an IP that matches that of ns1.vultr.com, and do the same for ns2.
I then change the name servers at OVH to point away from their own (or currently DO's) DNS servers, and to my own vanity name servers (which simply point to Vultr's NS IPs in the end).

Yes that's what I figured after reading into vanity nameservers again.
Thanks for clarifying that @d19dotca !

Since I've seen @girish you are online wanna take a look again.
I am not sure if I can answer it fully.

[d19dotca]

@BrutalBirdie All good, I appreciate the detailed helpful reply regardless! Always a good refresher as DNS is always confusing, haha.

@girish - I think I have just confirmed through a quick test that Cloudron won't recognize it's pointing to Vultr nameservers when a domain is using vanity nameservers. I believe this is a blocker to a project I want to do in the near future of setting up my own vanity nameservers and pointing my customer's domains to it.

Unless I'm totally incorrect, I'd love to see Cloudron do either one of the following:

1. Support the use of Vanity URLs by recognizing the end IPs and see who the IP is owned by

or

2. Allow admins to bypass the warning/error message around not using the right nameservers if they know what they're doing / agree to the possible consequences if done incorrectly, etc.

[robi]

Seemingly the only time vanity names are important is from a forward facing record someone sees which will resolve to an IP and from a reverse lookup by IP.

From this perspective, you can hand out your vanity DNS server domain mapped to any IP to all your customers configs.

Not sure why you'd need to use vanity domains in Cloudron, since customers as users won't see it. Even if they're admins.

This starts with the registrar and which DNS servers the domain is delegated to.

In Cloudflare for example you can't manage the domain via API unless your domain is set to use Cloudflare DNS servers. It's not a Cloudron limitation, but a Cloudflare one.

Next question is, can you get Cloudflare to validate a domain using vanity nameservers set at the registrar of the domain?

If they only check the IP only, then yes.
If the check the TLD name, then no.
If they check by IP, then reverseIP, then one of the above, then yes.

Try it and see which step fails with Vultr.

Fun!

[d19dotca]

@robi said in Vanity Nameservers... does Cloudron Support it?:

Not sure why you'd need to use vanity domains in Cloudron, since customers as users won't see it. Even if they're admins.
This starts with the registrar and which DNS servers the domain is delegated to.

I think you may have misunderstood the concerns above. Just to clarify, we don't use "vanity domains" - it's simply "vanity nameservers" (the NS records). All they are is for aesthetic purposes for WHOIS lookups and such. Admittedly it doesn't server too much of a purpose beyond marketing and segmentation of settings of various domains under my management. Mostly just a fun thing to do.

I've already tried doing this and Cloudron seems to be expecting vultr.com in the nameserver records when using the Vultr DNS provider in Cloudron for domain management, which means vanity nameservers cannot be used even though they're pointing to the exact same vultr.com nameservers in the end.

Personally, I don't think Cloudron should be restricting users/admins like this. There are many benefits to being able to have Cloudron point to any DNS provider regardless if the nameservers are set correctly, namely to have Cloudron quickly setup the various DNS records prior to any nameserver changes at the domain registrar level, making transitioning between DNS providers much more seamless as everything is done prior instead of after-the-fact.

Currently with this restriction, I believe it subjects admins to have to manually setup all the DNS records in their other DNS provider prior to changing the nameservers on the domain, then would also require updating Cloudron after-the-fact. It also less-importantly prevents the ability to use vanity nameservers.

@robi said in Vanity Nameservers... does Cloudron Support it?:

Try it and see which step fails with Vultr.

This basically has nothing to do with Vultr or any DNS provider on their own, it's entirely within Cloudron as it's Cloudron's logic to not allow changing DNS providers until the nameservers are updated first.

[girish]

@d19dotca said in Vanity Nameservers... does Cloudron Support it?:

That error made me wonder... how does Cloudron check? Does it require the domain namesevrers to be set to ns1.vultr.com and ns2.vultr.com, and if so, what about consideration for "vanity nameservers", where I would use my own domain name to essentially mirror Vultr's nameservers?

Yes, each backend (loosely) hardcodes the nameservers it expects.

I think to support vanity domains, all we have to do is to compare against the nameserver IP addresses instead of the nameserver domain and that's about it. i.e we just have to resolve the vultr NS and resolve the domain's NS and see if the IP matches.

[d19dotca]

@girish Exactly - I think that'd be a big improvement for the UX of admins. I realize to be fair that it's probably not a popular request, but seems like it's an unnecessary limitation too so would love to see that fixed.

Not only for vanity nameservers, but honestly I think my project for that just exposed a bigger problem in Cloudron's DNS functionality... that an admin can't use Cloudron to auto-populate DNS entries in another target system proactively / before changing nameservers, which adds a lot of extra overhead to admins wanting to change DNS services since adding DNS entries after changing nameservers is not a good idea.

[d19dotca]

@girish said in Vanity Nameservers... does Cloudron Support it?:

I think to support vanity domains, all we have to do is to compare against the nameserver IP addresses instead of the nameserver domain and that's about it. i.e we just have to resolve the vultr NS and resolve the domain's NS and see if the IP matches.

Was just curious if this is on the radar for the next Cloudron release (7.2.x) or if it's going to be a while yet. Reason I'm asking if I may be wanting to migrate more domains to use Vultr DNS servers from DigitalOcean, and would rather have Cloudron setup the DNS records ahead of time before making the NS change on the domain, which unfortunately due to this limitation Cloudron cannot do for admins yet.

(PS - Renamed the title of this Topic to better describe the current discussion points)

[nebulon]

Currently the way we store nameserver credentials and details per domain, will not allow for adding essentially multiple DNS provider for the same domain, so this would require quite a bit of refactoring for this case which may also be solvable with a custom one-time script?

(this is not possible) but I guess, if there would be an option to not resolve DNS records from the Cloudron side, one could change the DNS backend, then hit re-sync DNS in the Cloudron dashboard, then wait for the new nameservers to have all records in-sync and then switch the nameservers for the domain itself. Still, if the actual server and thus IP does not change during the whole process, I wonder how big the time-gap really is in the end as even if clients hit the old nameservers, then they would resolve the IP still correctly. Maybe I am missing something here though.

[d19dotca]

Hi Nebulon!

@nebulon said in Using Cloudron to setup DNS records in new DNS Provider before switching Nameservers on domain. Vanity Nameservers could also be supported if changes made.:

will not allow for adding essentially multiple DNS provider for the same domain

Just to be clear, I'm not looking to store multiple DNS credentials, if I switch it in Cloudron to Vultr from DigitalOcean, I'd assume or expect Cloudron to clear out the old credentials/API keys, so it definitely doesn't need to retain two or more at any given time for a single domain. Hopefully that clarifies that part. Definitely no need to go down the rabbit hole of refactoring, haha.

@nebulon said in Using Cloudron to setup DNS records in new DNS Provider before switching Nameservers on domain. Vanity Nameservers could also be supported if changes made.:

if there would be an option to not resolve DNS records from the Cloudron side, one could change the DNS backend, then hit re-sync DNS in the Cloudron dashboard, then wait for the new nameservers to have all records in-sync and then switch the nameservers for the domain itself.

That's basically what's being asked here... to remove the requirement to double-check the nameservers in the first place before being able to save the API keys on the domain. I understand why Cloudron does it, it's to help avoid DNS propagation issues, however at the end of the day, Cloudron works as a script to populate the DNS records in any provider we give it access to, so it should not be restricted to only doing so if the nameservers are configured correctly. That limitation that exists currently prevents admins from having Cloudron setup the DNS records in the new location first which of course is best practice before switching the nameservers at the domain level, you don't want to be doing it afterwards. I think a good compromise if Cloudron team feels it's necessary to still check for nameserver pointers, is to warn but allow a user to move past it to freely have Cloudron setup the DNS records where we provide access regardless of nameservers.

Does the above make sense? I can clarify if needed. Basically just hoping that limitation can be removed in the product as it's impeding what I'd think are some important tasks to be able to do before changing nameservers on a domain.