Cloudron Forum

Ah glad you managed to get down the issue in the end.

Hello @3246 Yes, as stated in the information text in AdGuard: Allowed clients A list of CIDRs, IP addresses, or ClientIDs. If this list has entries, AdGuard Home will accept requests only from these clients. Emphasis on only.

It worked! Thanks.

@OrezBodajoy wow, great find

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.

Fantastic! Thanks so much, @james

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