@d19dotca Okay, that is a bit confusing, but I will only be able to figure it out once I try it.

I appreciate everyone's help and responses.

@girish said in DNS CNAME and Cloudron Redirect for WWW:

roundbear.org

Thanks - that'll teach me to test things simultaneously! Fixed.

Solution:

set cname on cloudflare to www / baredomain.com set redirection on the app to add www

@mastadamus right, the spamlists won't work if those lookups get blocked. Currently, if the lookups fail, the mail server will simply go ahead and try to detect spam via spamassassin. It's just one of the metrics for spam detection. I guess it's fine if it's working OK for you without it .

@girish Just when I thought I understood DNS I learn about negative caching. Not sure if this was the issue, but it is possible. Thanks.

Ahh there was a "URL Redirect" record in Namecheap that was causing the problem. It wasn't obvious because it didn't have the IP address in the record but once I deleted that it worked. Thanks!

@girish
So i'm pretty sure I figured it out, but only time will tell.

Both of these domains the initial domain propagation and automation through cloudron's domain controller (from the main dashboard) all the way to the deployment and installation to applications was rushed. The initial rushing of it meant that the install got either halfway finished (or a migration from one original install to the new domain) was botched in some way.

Manually removing all DNS records doesn't work and cloudron gets all confused. The way I was able to remedy this and fix it all was to delete all DNS records and add an A record for my server: host @ & www respectively, two entries. So it'd be the following

@ my.server.ip
www my.server.ip

-Remove all other dns records.
-uninstall

I still haven't tried it out yet.

@meaculpa hehe I was just about to comment here, since I wasn't able to reproduce it on my side.

Glad it worked out now for you. Always good to have such topic for others to find if they hit the same issue in the future.

a restart dit the trick! thank you.

@atrilahiji said in Installation gets stuck in "checking DNS" step:

@jakobgreenfeld Oh I missed the bit where theres only a txt record. Add an A record pointing my.domain.com to your IP. I've had nothing but trouble with Namecheap's API for configuring everything so I've started doing this:

A record for *.domain.com
A record for @

That did the trick! It's working now. Thanks!

@brutalbirdie Yeah, I tried their Ghost hosting once, until I found how far behind their version updating lagged, which led me to discover Cloudron 😄

@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.

9bafe7ee-807e-4e2a-ae5d-bbf0b94cf89e-image.png

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

4100fcee-ca9a-4e59-8e1b-79bf989fc3d1-image.png

@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.