Cloudron Forum

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

@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 said in queryNs ESERVFAIL example.com - on all domains?: Hi, I cannot change the DNS Server settings in my domain settings for a domain, because Cloudron says: queryNs ESERVFAIL example.com When trying on the terminal as stated here: @girish said in Domain setup shows 'queryNs ESERVFAIL': @SignalScout On the server, please try host -t NS example.com 127.0.0.1 . Does that work? Sometimes, it takes a bit for the NS of a new domain to propagate. One just has to wait it out. root@my ~ # host -t NS example.com example.com name server root-dns.netcup.net. example.com name server third-dns.netcup.net. example.com name server second-dns.netcup.net. root@my ~ # host -t NS example.com 127.0.0.1 ;; communications error to 127.0.0.1#53: connection refused ;; communications error to 127.0.0.1#53: connection refused ;; no servers could be reached I don't know how to fix that, I cannot get my domains running. The result is the same for all domains, so I think it is a general error on my server. How to get deeper on this? Troubleshooter says: root@my ~ # cloudron-support --troubleshoot Vendor: Hetzner Product: Linux: 6.8.0-52-generic Ubuntu: noble 24.04 Processor: AMD Ryzen 5 3600 6-Core Processor BIOS AMD Ryzen 5 3600 6-Core Processor Unknown CPU @ 3.6GHz x 12 RAM: 65758340KB Disk: /dev/md2 26G [OK] node version is correct [OK] IPv6 is enabled and public IPv6 address is working [OK] docker is running [OK] docker version is correct [OK] MySQL is running [OK] nginx is running [OK] dashboard cert is valid [OK] dashboard is reachable via loopback [OK] box v8.2.4 is running [OK] netplan is good [OK] DNS is resolving via systemd-resolved [OK] Dashboard is reachable via domain name [WARN] Domain example-host.de and real estate agents london expiry check skipped because whois does not have this information [OK] unbound is running I am lost and don't know what to do next, I appreciate any tips on this. Best Jay Thanks for bringing this up. An SERVFAIL on all domains usually points to either a misconfiguration in DNS settings or an upstream resolver issue. Double-checking the domain’s authoritative nameservers and ensuring there’s no DNSSEC misconfiguration often helps. Curious to know if you already tested with an external tool like dig or nslookup outside of Cloudron to see if the problem persists?

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