DNS: "Domain nameservers are not set to <provider>"

[d19dotca]

I'm looking to change back from my wildcard DNS endpoint to DigitalOcean for some testing, and I noticed that Cloudron won't make the change until the name servers point there.

I get the following message: Domain nameservers are not set to DigitalOcean

Just curious... why is that prerequisite necessary for Cloudron to add in DNS entries?

I'd assume when changing DNS providers, that the safest course of action is to setup the DNS entries in the target service first for continuity / uptime. In my case, I was wanting to have Cloudron switch to DigitalOcean from Wildcard in order to setup the records it needs, then I'd make the switch in name servers. But it seems Cloudron wants the name servers switched first.

I didn't get much sleep last night so I may be forgetting something fundamental here, lol, but it just seems like an odd requirement to me at the moment to require the name servers changed first as that tends to go against "best practice" for switching DNS providers in my previous experiences.

[girish]

@d19dotca for Cloudron the workflow is to make sure when the app is installed, it can be accessed via the browser immediately. For this, the DNS nameservers have to be set.

IIUC, you are trying to move from wildcard of different service to DO DNS. I would do it like this:

• Add domain to DO DNS and then setup wildcard entries here manually.
• Wait for DNS entries in DO to propagate. You have to test this manually using dig/host. I think something like host -t app.domain.com <DO-DNS-IP>.
• Now, switch the nameserver of your domain to DO. At this point, everything is still working because you added wildcard entries manually. You have to wait till NS propagates. Usually, this takes a lot longer than normal entries (like 30 mins to even 6 hours depending on your provider). For example, namecheap.com and name.com are really slow with NS records.
• Next, switch the DNS provider in Cloudron for the domain to DigitalOcean.
• You can also then click on "Sync DNS" in the domains view and it will add the entries in DO DNS.
• Finally, you can remove the wildcard DNS entries in DO DNS now that we have proper entries in place.

This only covers apps though, for email you have to setup the records manually in step 1 (so MX, DKIM, SPF and DMARC).

[girish]

BTW, one thing which I did not consider is that your old DNS provider and DO DNS might provide import/export of zone files. If they do (like I think cloudflare does), then you can just download from old one and add it to DO. Then you switch NS records and change the Cloudron provider as well.

[d19dotca]

@girish I'm not sure if that makes complete sense to me yet, but as always I appreciate the detailed explanation.

I can understand that Cloudron is checking to make sure an app hostname can be resolved, but I'd think it just needs to do a DNS lookup to make sure it can resolve the hostname of the app, then proceed forward. I don't quite understand why it care about the name server side of things. As long as the app hostnames are resolvable, shouldn't that be sufficient?

In my case, the IP isn't changing, nothing is changing other than I want to use DigitalOcean DNS whereas I currently use a Wildcard DNS backend. Everything is already working as-is and has been for quite some time. I should be able to link Cloudron up to DigitalOcean's DNS API to generate all the required DNS entries in the new service provider before needing to change name servers.

If Cloudron's main focus is to make sure the app "can be accessed via the browser immediately", then it should just need to care if the hostname is currently resolvable, right?

The best practice would be to switch name servers last when switching DNS providers for a domain, and the way Cloudron seems to currently work I cannot have Cloudron setup the new DNS service ahead of time before switching the name servers since it requires the name servers set first, which seems a bit backwards to me. Part of the beauty of that function is that Cloudron sets the DNS entries is automation, but this current behaviour is now requiring manual steps which seem unnecessary.

I guess the process just seems "off" to me, or rather backwards from how I'd think it should operate to achieve best practices and convenience to users.

[girish]

@d19dotca I guess you are asking why not allow adding a domain in the Domains view without checking NS record. I think it's mostly for UX/flow.

• For new domains, NS record check ensures domain is usable. Meaning, when a user makes a domain purchase, the DNS APIs usually become immediately available for use and one can update DNS records but the NS records itself take a while to appear and propagate. Blocking the addition in the Domains UI is better than having them install an app and it failing with some DNS error.

• Another use case is that people usually start with some wildcard because Cloudron does not support their provider and then later they switch to one of the programmatic DNS. Most times, they forget to switch the NS, so this check is a "reminder" for them to first switch instead of failing at the app installation time.

I think the second use case is similar to yours. Most likely there are many records to migrate and not just Cloudron related ones. In this case, a user has to switch DNS providers and the NS records outside cloudron first to keep things functional. I imagine they do this by exporting and importing zone records across providers. Once this is done, they can always switch the DNS provider in Cloudron and the NS checks will work. Maybe I miss something in the flow here.

[d19dotca]

@girish Most DNS providers (at least in my experience) do not offer DNZ zone export/import. You cannot import a DNS zone to DigitalOcean for example, at least not that I've seen any interface for in the DO control panel. I worked around it by manually creating wildcard entries and also all the DKIM, DMARC, SPF, and MX records as needed. But I manage around 18 domains right now, so this was unfortunately a very time consuming process since I couldn't use Cloudron to make the records for me, as I was switching almost all the domains over to DO.

May I suggest that there be an option to ignore that error around name servers in order to proceed still? Because in that second scenario, Cloudron's abilities to automatically setup DNS records becomes nullified since it requires the name servers switched first which is not the best practice when changing DNS providers, as changing the name servers is always the very last thing that's supposed to be done.

I really believe Cloudron should have the ability to set DNS records without requiring name servers pointing to it. I also completely understand your point though that people may forget to switch their name servers and then run into issues later, so I think it's fair to check as it does now, but also offer an option to acknowledge it and proceed despite the name servers not pointing to the new DNS provider yet.

Hopefully that makes sense and is feasible to add to Cloudron. The current workflow is quite an inconvenience when trying to setup a new DNS provider for use by the automation that Cloudron provides. If I have to setup everything manually in the new DNS provider prior to Cloudron being able to do it itself, then it kind of at least temporarily defeats the purpose of the whole automation thing which is there to save time.

[girish]

@d19dotca In your case, this only work because all or most of the records are managed by Cloudron? Like if you had 10 records which are not Cloudron related, you have to add all this manually, right (if the DNS providers don't provider a way to import/export) ? In this case, Cloudron will only provide some half automation and this also means you have to be well aware of what Cloudron added and what Cloudron did not to rely on this half automation. But I got your point that maybe it will help move say 20-30 records and it all depends on what percent of records are managed by Cloudron.

[d19dotca]

@girish Correct. In my case they're almost all managed by Cloudron with some exceptions like extra records needed by Mailjet for example, but yeah the vast majority of the DNS records between all the domains I manage are Cloudron-related.

[d19dotca]

I didn't get much sleep last night so I may be forgetting something fundamental here, lol, but it just seems like an odd requirement to me at the moment to require the name servers changed first as that tends to go against "best practice" for switching DNS providers in my previous experiences.

@girish is it possible to look at this again please so we can either remove the requirement for the domain name servers to be pointing to Cloudron before Cloudron will set the DNS records, or at least add an option to move past it when Cloudron detects the domain name servers aren't set to the particular DNS vendor yet?

[girish]

@d19dotca adding a flag to ignore the name server check should be ok. I think we still want to keep the default to checking the name server since this is general/common flow on Cloudron. Did you create Feature request for this already ? Should be easy to implement.

[d19dotca]

@girish said in DNS: "Domain nameservers are not set to <provider>":

adding a flag to ignore the name server check should be ok. I think we still want to keep the default to checking the name server since this is general/common flow on Cloudron.

Yes please, this would be great. Definitely fair to keep it as a default to check the name servers, but a checkbox to ignore it would be fantastic! This would help us in changing DNS providers in a fault-tolerant way by being proactive setting up the DNS records at the new provider.

@girish said in DNS: "Domain nameservers are not set to <provider>":

Did you create Feature request for this already ?

Unfortunately not, I guess I made a bad assumption this would be included from the original discussion I created, haha, I think I probably should have set this as a Feature Request instead. Sorry for not filing that earlier. I went ahead and created one though here for that: https://forum.cloudron.io/post/54948