@girish no, but I noticed it took a while when you asked me to run it in CLI too. Not something we control ;-/

Can the DNS query be externalized via shell call to hosts command? Or maybe query twice to get the cached response?

@nebulon there should be branching logic after Cloudron 'senses' that it doesn't own that DNS anymore.

Prompt for delete of an unmanaged resource in that state?

@andrewj720 Looks like DNS is not working on your server. You can also try host cloudron.io etc, I guess none of it working?

Can you check if your cloud firewall allows outbound port 53 UDP ? I think there was a post on this forum some time ago that someone had it blocked in AWS security group by mistake, for example.

Hey guys, sorry for the delay

I've updated the fork and the providers function, if I get permission to create a new branch or you open one I can open an MR with the new branch and let you review

Yup. This makes no sense.

@joerodge I guess you got this sorted out by the time I approved your forum post? I can access your dashboard here:

@girish That would be ideal! In fact if that can come in the next couple of months, I'll hold off my own DNS change until that's there. Because the whole "my." doesn't really conform to the standards that people expect when they need to enter in their server names for a mail server. I'd definitely love if Cloudron could use it's own "mail" subdomain and it's own certificate for the mail server portion so that I can still have clients connect to mail.<domain>.<tld> without impact since that's what I have told a dozen or so to do already over the last 1.5 years.

And no, the decision wasn't anything to do with Cloudron or DigitalOcean really. My main reason for the move away from DigitalOcean isn't anything to do with Cloudron or DigitalOcean. If you're curious... the decision was mostly for two reasons:

A movement from both myself and my clients to keep everything (as much as possible) in Canada. And my current DNS provider (LunaNode) has their infrastructure in Canada only (well France too, I believe). It's one of those "shop local" sort of things.

The DNS provider I currently use has a great feature that I can take advantage of in the future when running a secondary Cloudron server as a mirror image of the first one (waiting for that clustering capabilities in the future, hint hint haha). The advantage is that they have monitoring tools I can use, and based on those monitoring tools they can automatically update DNS records to the other IP address if monitoring detects one of the servers as "down" for whatever reason. To me this is like the health checks in load balancing, but I don't have to pay for load balancing with this solution. I see this as a further advantage to using LunaNode for the DNS management.

So yeah, nothing to do with Cloudron or DigitalOcean really, so no worries there. Just a decision made for various reasons (the biggest two above, but also a bit of my own OCD and others haha).

I will keep my primary domain on DigitalOcean then for now if you think the SSL cert for the mail subdomain would arrive in the next couple of months. Because I think that's a fantastic idea, and I think that was something I mentioned or questioned back when I started using Cloudron because I was so surprised that it had to be "my." as that's not something that conforms to the standards of mail server hostnames, and I wanted to keep things more standard for my clients to avoid having to explain non-standard implementations. I say standard loosely here as I realize there's no official standard, but it's more a de-facto one that mail. is the subdomain to use, or imap., etc.

Hope that helps.

@girish Done - https://forum.cloudron.io/topic/3777/support-optional-cloudflare-proxied-record-creation

@nebulon For sure, yeah I figured it may need more interest before it's implemented, and realistically I'm probably the only Cloudron user who's hosting on LunaNode (though I'd love to know if others are too), as I think LunaNode is a nice hidden gem that's not overly used yet and I switched to them recently as I had heard great things and their pricing is pretty good. Brief recommendation at the bottom for anyone interested. I'll let them know too about Cloudron in case they can do anything to help out too.

On the topic of DNS at LunaNode though... it seems pretty awesome from what I can tell, as it has integrated load balancing and failover which is perfect and works with their included monitoring feature too (which is like Uptime Robot but provided by LunaNode), and so if my monitor fails and I have a second DNS entry, it'll automatically remove the failed one from the DNS records temporarily until it's back online, giving only the backup DNS entry for the "hot standby" server. Hoping to take advantage of those features in the not too distant future if it's feasible for me to run a second "hot standby" server. Waiting on Cloudron to add in some functionality to clustering which I think is coming in v6. Once that's there, I hope to be able to do that. Nudge nudge. haha.

Brief recommendation based on my initial tests so far for other Cloudron users who want a good inexpensive hosting provider: I recently moved my Cloudron server from OVH to LunaNode to test out their performance, and the exact same Cloudron server in OVH used to take 10 minutes to fully come online after a reboot in OVH, and having restored that same server in LunaNode it now takes only 2-3 minutes to fully come online. That's also with some memory-intensive applications like Mastodon and NodeBB (which are always the last two to start in my environment given their resource usage). Same 8 GB nodes between OVH and LunaNode too. This performance improvement now cuts my downtime after reboots for security updates by almost 75%! That's my brief recommendation for LunaNode. haha.

@girish This is an interesting observation. I was just looking to see if this was a real security threat or not, and I suppose it isn't but can offer a bit more privacy using the wildcard approach. Any particular reason why the Let's Encrypt wildcard support can't be done through the actual Cloudron wildcard DNS approach? Is there a way to support this? I'd really like to take advantage of a smaller DNS provider which has some great monitoring features included, but it isn't supported via any API by Cloudron yet, so if I go that route I can only use the Wildcard option, but those don't actually allow for the wildcard certificates.

Edit: Nevermind, I see why in the docs: "Let's Encrypt only allows obtaining wildcard certificates using DNS automation. Cloudron will default to obtaining wildcard certificates when using one of the programmatic DNS API providers."

@Felix Did you manage to install it?

I think you're right, it took a while to propogate fully.

@girish yes, that’s a much better idea. Essentially the ability to “swap” app instances, or in other words the ability to easily promote from staging app instance to production app instance on the same server. That’d be ideal.

@JOduMonT Currently, Cloudron does not support IPv6 and requires an IPv4. You can, of course, configure your server to have IPv6 address additionally and configure DNS AAAA records manually and that should work.

Goes without saying, we want to add IPv6 support at some point (I know it's 2020!! )

Hi @derek sorry for the delayed answer, did you manage to solve this after the TTLs have expired from your attempts?

Ah seems to be working now thanks - I had added my full domain foo.ddns.net to the zone name field initially as It autofilled ddns.net and I thought that cloundron might then try to generate subdomains with the foo part missing e.g. my.ddns.net which wouldn't work but apparently not. Thanks for the Help!

There is an entry in the issue tracker for powerdns already at https://git.cloudron.io/cloudron/box/issues/117

Regarding the Linux distribution, we currently only support Ubuntu in versions 16.04 and 18.04 and due to testing effort, we don't currently plan on adding further distributions.

@marcusquinn I like the idea of atleast just adding a doc page for the moment on how to do this manually till we implement the feature. I will add it our docs.