Cloudron Forum

solved by adjusting existing DNS A Record entry. Changing from aaaa:bbbb:cccc:dddd:: to aaaa:bbbb:cccc:dddd::1

WebFinger is not a simple static file (though of course it can be). The URL has to respond based on the acct provided in the query parameter. So, each user needs to have their own links . For the moment, it's best to use something like https://wordpress.org/plugins/webfinger/ . Or if you can code, just write some simple PHP page or static Surfer page to respond . Cloudron's nginx server will query the app.

@james I could not get it working at all, so I switched to use Sendgrid instead since we have an account and that is working fine. The issue is that I am using Cloudron as a VM inside of Truenas Community 25.04.1 and it is Truenas causing the issue and I would have to make some major changes and I don't want to affect the File Server side by doing this.

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

@ImatBagjaGumilar can you check host -t NS <domain.com> 127.0.0.150 on your server? You can also try to run cloudron-support --troubleshoot to check if DNS is working on the server.

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.