Cloudron Forum

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.

Porkbun issue is fixed in 8.1

never mind, I fixed the issue with the IP. I went into GoDaddy and noticed the IP was different, so I changed it back, restarted unbound service and now my dashboard is loading with my domain. Now to restoring all of the apps with my backups.

And I would appreciate if this fix get published soon. I need to update it, because I accidently did not renew but delete the API key and there is no way back. (Really not "no bullshit" like years ago @gandi) @girish

Thanks for the explanation, I've likely overlooked that when upgrading to V8 and likely also overestimated the quality of my "default" DNS , thanks !

RESOLVED: It's likely that cloudflare was having some internal issue, but upon checking https://www.cloudflarestatus.com/ I was left more confused is there was any incident on their end in my region. It's buried under scheduled maintanaces and other stuff. I still not sure if this was the correct resolution, but it started working after executing these steps. sudo apt-get install -y systemd sudo nano /etc/systemd/resolved.conf Added the DNS of Cloudflare and google # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it under the # terms of the GNU Lesser General Public License as published by the Free # Software Foundation; either version 2.1 of the License, or (at your option) # any later version. # # Entries in this file show the compile time defaults. Local configuration # should be created by either modifying this file, or by creating "drop-ins" in # the resolved.conf.d/ subdirectory. The latter is generally recommended. # Defaults can be restored by simply deleting this file and all drop-ins. # # Use 'systemd-analyze cat-config systemd/resolved.conf' to display the full config. # # See resolved.conf(5) for details. [Resolve] # Some examples of DNS servers which may be used for DNS= and FallbackDNS=: # Cloudflare: 1.1.1.1 #cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4700::1111 #cloudflare-d># Google: 8.8.8.8 #dns.google 8.8.4.4 #dns.google 2001:4860:4860::8888 #dns.google 2001:4860:4860::8> # Quad9: 9.9.9.9#dns.quad9.net 149.112.112.112 #dns.quad9.net 2620:fe::fe #dns.quad9.net 2620:fe::> DNS=1.1.1.1 8.8.8.8 sudo systemd-resolve --flush-caches # didn't work systemd-resolve --status # wasn't even running. So maybe the config change was irrelevant Reboot and started working... and I am not sure how this is possible... Anyway that for the help. This issue was plaguing me for a few days.

If Hairpin NAT is not working, please refer to https://docs.cloudron.io/troubleshooting/#hairpin-nat

I think @nebulon means host -t NS vysvr.org . This should resolve to your nameservers.

Switching to hetzner feels good enough for now . Full backup takes 30min for 21 apps. I've cancelled contabo storage service. Hope this stays so snappy for the long run

@b2breporter you can contact us on support@cloudron.io and we can fix it up

Ok weird, this worked, I backed up apps and updated to Cloudron 8 but it's not working again. that file didn't change. I set it to google's public DNS and it was fine - I reinstalled tailscale and set override DNS to true which I think should fix it and let me keep using TS