Cloudron Forum

@Shai You would need to edit your local computers /etc/hosts file and add in the old IP address of the previous Cloudron install for the domain name that you’d type in the browser bar. Then you should be able to use the hostname to still access the older Cloudron server.

Right, if you lost control of the domain. Switch the Domain provider in Domains view to manual or noop.

Hello @LoudLemur If this happens again, could you please pinpoint the time and save the box.log or even better the output of cloudron-support --send-diagnostics so I can look further into it.

Never heard of them before, and only you mentioned them so far in this forum Implementation might be easy, but the question is, how many would benefit from that. Question about prioritization I would suggest for now using Hetzner.

@Njara When I run the dig NS cofident.net @127.0.0.150 on one of my Cloudron servers, I get. dig NS cofident.net @127.0.0.150 ; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> NS cofident.net @127.0.0.150 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27068 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;cofident.net. IN NS ;; ANSWER SECTION: cofident.net. 294 IN NS dns102.ovh.net. cofident.net. 294 IN NS ns102.ovh.net. ;; Query time: 0 msec ;; SERVER: 127.0.0.150#53(127.0.0.150) (UDP) ;; WHEN: Fri May 23 12:58:07 UTC 2025 ;; MSG SIZE rcvd: 86 This section is missing on your part: ;; ANSWER SECTION: cofident.net. 294 IN NS dns102.ovh.net. cofident.net. 294 IN NS ns102.ovh.net. Now I am looking into your generated details https://paste.cloudron.io/imomagiruq

That's it - it was the browser! Thanks for your help, no bug then!

@mrhakash said in Outbound Emails Queued — NXDOMAIN Error and Local DNS Resolution Issue: dig @127.0.0.1 gmail.com mx returns: connection refused You have to check host -t MX gmail.com 127.0.0.150 . Can you also run cloudron-support --troubleshoot for hints?

@joseph That's right! I thought that was the easiest way to increase the deliverability of emails sent from my Cloudron server. But apparently my understanding of DNS is lacking. I checked my VPS' ip address and it's not in any blacklists, so switching to the internal SMTP server.

@SamGreenwood I would run the troubleshooting tool for a start - https://docs.cloudron.io/troubleshooting/#troubleshooting-tool

Not sure what you mean with "redirect" here, but the code checks if the DNS A (and AAAA if you use ipv6 also) are in sync at all configured nameservers for this domain. So basically you just have to make sure that you have setup A records for my.heavendigital.com.br pointing to your server IP. Then after some time, depending on your DNS provider, this should succeed.

So it turns out DNSSEC is the problem. Unbeknownst to me, the previous registrar had enabled DNSSEC by default, when I transferred the domain some time ago, the records were not removed when the new registrar updated the nameservers. As they don't have DNSSEC management and my DNS resolver doesn't validate DNSSEC, I didn't notice anything was amiss. Thank you for your help with this!

I use uBlock Origin and have never had a problem.

@jayonrails sounds good. Otherwise, if both commands work and things are still failing, please send a mail to support@cloudron.io to debug this further. Can't see how it fails.

Thank you for taking the time to investigate. It seems like there are several tools that have successfully implemented DNS-based Let's Encrypt challenges and DNS-based automation for deSEC. If the higher TTLs really are a problem, could it be possible to just restrict the usage of deSEC to wildcard DNS + Certificate usage (wildcard A/AAAA record + DNS challenge for Let's Encrypt)? These records only need to be updated very infrequently if at all. I personally run my cloudron instance behind a VPN, which is why I am unable to use the HTTP based verification. deSEC is a very special provider that I think is worth putting the effort into supporting. AFAIK It's the only donation-run/free, European provider with DNSSEC support currently included in Cloudron. Hetzner doesn't support DNSSEC. It's also (likely) one of the most privacy respecting providers available. I have also made a post on their forum. Maybe some creative ideas will come about.

@joseph that was indeed correct. I just generated another token, and it is now working correctly. There was an issue with the Gandi dashboard yesterday. Did not take the time to properly troubleshoot it. Looks like it indeed was a problem on the Gandi side of things. Thanks for your help. Side note: I love your product, and I have been happy paying subscriber for the past few years now. Keep up with the good work

@nebulon Fully agree, it's really odd that Wix doesn't allow AAAA records in this day and age. I'll change that domain to noop for now then as recommended, but my preference is to have the logic of the location DNS propagation check change so that domains in manual status can still be successful even if only one IPv4 or one IPv6 address is set rather than both. The noop is for development after all, isn't it? As long as one of the DNS records exists, that should be seen as successful IMO, since it will work in terms of getting traffic to the site still. There shouldn't be a reason to fail that.

@David-0 said in Use Cloudron Mailserver but have different Webhosting?: Would it be possible to use Cloudron as a mail server for mail@new.com while the domain new.com (or even subdomain.new.com) is hosted somewhere else? yes, the DNS records for a mail server (MX record) and webhosting (A records) are entirely different. It's totally normal and safe to host web and mail of the same domain on totally different systems.

@joseph ah, there you go. I have indeed updated to 24.04, and presumably it was before this instruction was added. Thank you all for the help, guys, all is well now

Thanks for sharing that and glad it worked out in the end.